Free Server Name WebPart Which WFE Is Servicing a SharePoint Request

This is probably the most nominal WebPart I have ever seen / written but I really needed it this morning. As you can guess it just uses a ServerVariables object (off the current context request) to expose the relevant environment variables, in this case just the server name.

The reason this came about was in large SharePoint farms it is notably important when doing certain types of architecture troubleshooting to know which WFE you are hitting. And….well…that’s really it. At least you don’t have to put the WSP together I guess.

So this is what that WebPart does. Just install the WSP and deploy it in Central Admin (as noted in previous posts, I never automate the deployment step).

10-13-2009 10-07-51 AMThe WebPart is Feature activated. In the site collection features, locate the Server Name WebPart feature and activate it.

10-13-2009 10-10-07 AM

Once activated, you will find the WebPart under the ARB Security Solutions header in the WebPart gallery.

10-13-2009 10-13-01 AM

Add it to the page, and it will display the server name in the SharePoint farm responding.

10-13-2009 10-13-51 AM

EDIT:

Well I guess I should actually give a download link :)

DOWNLOAD THE SERVER NAME WEBPART INSTALL PACKAGE

Share

How to Programmatically Disable Code Access Security

Programmatically controlling Code Access Security in a SharePoint environment is an extremely powerful approach allowing one to toggle behavior for code access demands for managed code. Outside of that, it’s actually a performance increase even though I am not saying that the side effects are worth the negligible operation amplification. Mostly, the tactic is employed only on completely isolated, disconnected environments.

Pretty importantly the approach here, if there are multiple runtimes on the SharePoint environment, will disable CAS across the board, easily grafted from the included code.

There are a few important pieces of the provided code to point out.

Firstly, the helper method, IsWin95OrLater is simply a static helper method for basic platform testing, even though this really isn’t a concern for SharePoint servers. However, for completeness is included in the example.

After the platform test occurs, a WindowsPrincipal object is created base on the current user, testing if they are an administrator by using the WindowsBuiltInRole.Administrator enumeration. After some checking etc. a new Mutex object is used to control a shared resource between threads. Using the Mutex.GetAccessControl() method a new MutexSecurity object can be created. This allows the SetOwner and AddAccessRule method to be exposed, the latter importantly instantiating a new MutexAccessRule specifying allowance through the AccessControlType.Allow enumeration. Lastly the Mutex.SetAccessControl method consumes the newly hydrated MutexSecurity.
[csharp]
private static bool IsWin95OrLater()
{
return (Equals(Environment.OSVersion.Platform, PlatformID.Win32Windows));
}

private static void DisableCAS()
{
if (!IsWin95OrLater())
{
var principal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
if (!principal.IsInRole(WindowsBuiltInRole.Administrator))
{
throw new Exception(“Hey, You Aren’t An Admin!”);
}
}
try
{
bool grantedOwnership;
using (var mutex = new Mutex(true, !IsWin95OrLater() ? @”Global\CLR_CASOFF_MUTEX” : “CLR_CASOFF_MUTEX”, out grantedOwnership))
{
if (!IsWin95OrLater())
{
MutexSecurity accessControl = mutex.GetAccessControl();
accessControl.SetOwner(new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null));
accessControl.AddAccessRule(new MutexAccessRule(new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null), MutexRights.Synchronize, AccessControlType.Allow));
mutex.SetAccessControl(accessControl);
}
}
}
catch (ApplicationException)
{
throw new Exception(“Something Went Very, Very Wrong!”);
}
}
}

[/csharp]

Share