Take the example of My Sites. When planning your My Site deployment, you'll probably spend good bit of time planning out the storage neccessary to support your end user adoption rate of My Sites, and also spend a fair bit of time discussing how much space (maximum) you want to allow your users to consume. You'll enforce this with a template. But what happens in 6 months, when you decide that your estimates were too high, or too low, and you need to either increase the storage that end users can use, or decrease the storage? Manually adjusting 1000's of site collections would take days!

Enter a wee bit of PowerShell script and the SharePoint 2010 Management Shell. We have to use a few bits of the SharePoint object model to make this work, but this task is simple enough to be approachable by even the most code-averse IT pro's out there:

# Replace all site collection quotas in a web application with a new template
$TemplateName = "My Template Name"
$WebApplicationUrl = "https://my/"

$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$quotaTemplate = $contentService.QuotaTemplates[$TemplateName]
$webApplication = Get-SPWebApplication $WebApplicationUrl
$webApplication.Sites | ForEach-Object { try { $_.Quota = $quotaTemplate; } finally { $_.Dispose(); } }


 In the above, just replace "My Template Name" with the name of the new or updated quota template you'd like to assign, and https://my/ with the URL of the web application you'd like updated. This script will replace the quota template on every site collection within that web application.

Too heavy handed for you? What if you only wanted to replace the template assigned to a site collection if it was already assigned a specific template? So, for instance, you've got some sites using a quota template called "Bad Template", but you don't want to use that template anymore, and you want to replace the quota templates assigned to those folks with a new template, "Good Template". What to do?

Enter a nother wee bit of script:

# Replace all site collections having a specific quota template with a new quota template
$OldTemplateName = "Bad Template"
$NewTemplateName = "Good Template"
$WebApplicationUrl = "https://my/"

$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$quotaTemplate = $contentService.QuotaTemplates[$OldTemplateName]
$replaceQuotaTemplate = $contentService.QuotaTemplates[$NewTemplateName]

$webApplication = Get-SPWebApplication $WebApplicationUrl

$webApplication.Sites | ForEach-Object { try { if ($_.Quota.QuotaID -eq $quotaTemplate.QuotaID) { $_.Quota = $replaceQuotaTemplate } } finally { $_.Dispose(); } }


Again, simply replace "Bad Template" with the template you want to replace, "Good Template" with the name of the new template to replace "Bad Template" with, and https://my/ with the URL of the web application you want to process.

But wait! What if you don't want *any* quota templates! How do I remove the quota templates from all sites with a specific quota template already applied? Easy enough:

# Replace all site collections having a specific quota template with a new quota template
$OldTemplateName = "Bad Template"
$WebApplicationUrl = "https://my/"

$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$quotaTemplate = $contentService.QuotaTemplates[$OldTemplateName]

$webApplication = Get-SPWebApplication $WebApplicationUrl

$webApplication.Sites | ForEach-Object { try { if ($_.Quota.QuotaID -eq $quotaTemplate.QuotaID) { $_.Quota = $null } } finally { $_.Dispose(); } }


Hope that helps those of you struggling with ex-post-facto updates to site collection quotas!

Recently, the question of automating custom claim assignments to SharePoint groups has come up. For example, if you’ve got a custom claim provider that provides a custom claim of type https://schemas.bryanporter.com/favoriteColor, how could you add all users that present that claim to your farm into the Visitors group of a SharePoint site?

Managing users is pretty straightforward. So, if you had a user CONTOSO\brporter that already existed in a SharePoint site, you could simple run the following PowerShell to add them to the site and assign them to the Team Site Visitors group:

1 # If the user already exists in the site...
2 $user = Get-SPUser -Identity (New-SPClaimsPrincipal -Identity CONTOSO\brporter -IdentityType WindowsSamAccountName).ToEncodedString() -Web http://<web site URL>
3 Set-SPUser -Identity $user -Web http://<web site URL> -Group "Team Site Visitors"

If your user was new to the site, replace Get-SPUser with New-SPUser and you are all set:

1 # If the user is new to the site
2 $user = New-SPUser -UserAlias (New-SPClaimsPrincipal -Identity CONTOSO\tuser -IdentityType WindowsSamAccountName).ToEncodedString() -Web http://<web site URL>
3 Set-SPUser -Identity $user -Web http://<web site URL> -Group "Team Site Visitors"

But what about a claim? What if you only want to allow users that present, say, a favoriteColor claim with a value of Blue to be able to visit a particular site? To make sure that ardent adorers of the color Blue can visit your site:

1 # If you are securing based on a claim
2 $claimProvider = Get-SPClaimProvider | where { $_.DisplayName -eq "The Name Of My Claim Provider"}
3 $claim = New-SPClaimsPrincipal -ClaimValue Blue -ClaimType http://schemas.bryanporter.com/favoriteColor -ClaimProvider $claimProvider.ClaimProvider
4 
5 $user = New-SPUser -UserAlias $claim.ToEncodedString() -Web http://<web site URL>
6 Set-SPUser -Identity $user -Web http://<web site URL> -Group "Team Site Visitors"

The non-obvious bit here is that we continue to deal with New-SPUser, even when we’re actually talking about a custom claim.

I should also point out that unless your custom claim provider successfully resolves the claim value and type you won’t get a claim reference that can return a proper encoded string – effectively preventing you from securing on the claim. For more infromation on implementing claim resolution, see Steve Peschka’s most excellent walkthrough on MSDN.

There are plenty of extensibility points within SharePoint that certainly offer up opportunities for scratch programs, though, and one place I find myself sharing – over and over again – my personal scratch implementation is with Custom Claims Providers. And so I submit for your approval, the SimpleClaimsProvider in all its favoriteColor issuing claim glory. This will serve as a starting point for future posts involving custom claims providers, and in the meantime might give a few of you the bits you need in order to make the details of Custom Claims Providers real. For a complete walkthrough, see Steve Peschka’s most excellent write up over on MSDN.

  1 using System;
  2 using System.Collections.Generic;
  3 using System.Linq;
  4 using System.Text;
  5 
  6 using Microsoft.SharePoint;
  7 using Microsoft.SharePoint.WebControls;
  8 using Microsoft.SharePoint.Administration;
  9 using Microsoft.SharePoint.Administration.Claims;
 10 
 11 namespace BryanPorter.SP.CCP
 12 {
 13     public class SimpleClaimsProvider
 14         : SPClaimProvider
 15     {
 16         private static string m_claimValueType = Microsoft.IdentityModel.Claims.ClaimValueTypes.String;
 17         private static string m_claimType = "https://schemas.bryanporter.com/favoriteColor";
 18 
 19         private string m_sharedState = null;
 20 
 21         public SimpleClaimsProvider(string displayName)
 22             : base(displayName)
 23         { }        
 24 
 25         protected override void FillClaimTypes(List<string> claimTypes)
 26         {
 27             if (claimTypes == null)
 28                 throw new ArgumentNullException("claimTypes");
 29 
 30             claimTypes.Add(m_claimType);
 31         }
 32 
 33         protected override void FillClaimValueTypes(List<string> claimValueTypes)
 34         {
 35             if (claimValueTypes == null)
 36                 throw new ArgumentNullException("claimValueTypes");
 37 
 38             claimValueTypes.Add(m_claimValueType);
 39         }
 40 
 41         protected override void FillClaimsForEntity(Uri context, SPClaim entity, List<SPClaim> claims)
 42         {
 43             if (entity == null)
 44                 throw new ArgumentNullException("entity");
 45 
 46             if (claims == null)
 47                 throw new ArgumentNullException("claims");
 48 
 49             claims.Add(CreateClaim(m_claimType, "Blue", m_claimValueType));
 50         }
 51 
 52         protected override void FillEntityTypes(List<string> entityTypes)
 53         {
 54             entityTypes.Add(SPClaimEntityTypes.FormsRole);
 55         }
 56 
 57         protected override void FillHierarchy(Uri context, string[] entityTypes, string hierarchyNodeID, int numberOfLevels, Microsoft.SharePoint.WebControls.SPProviderHierarchyTree hierarchy)
 58         {
 59             throw new NotImplementedException();
 60         }
 61 
 62         protected override void FillResolve(Uri context, string[] entityTypes, SPClaim resolveInput, List<Microsoft.SharePoint.WebControls.PickerEntity> resolved)
 63         {
 64             if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
 65                 return;
 66 
 67             PickerEntity pe = CreatePickerEntity();
 68             pe.Claim = CreateClaim(m_claimType, "Blue", m_claimValueType);
 69             pe.Description = Name + ":" + "Blue";
 70             pe.DisplayText = "Blue";
 71             pe.EntityData[PeopleEditorEntityDataKeys.DisplayName] = "Blue";
 72             pe.EntityType = SPClaimEntityTypes.FormsRole;
 73             pe.IsResolved = true;
 74             pe.EntityGroupName = "Favorite Color";
 75 
 76             resolved.Add(pe);
 77         }
 78 
 79         protected override void FillResolve(Uri context, string[] entityTypes, string resolveInput, List<Microsoft.SharePoint.WebControls.PickerEntity> resolved)
 80         {
 81             if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
 82                 return;
 83 
 84             if (resolveInput.ToUpper().Contains("BLUE"))
 85             {
 86                 PickerEntity pe = CreatePickerEntity();
 87                 pe.Claim = CreateClaim(m_claimType, "Blue", m_claimValueType);
 88                 pe.Description = Name + ":" + "Blue";
 89                 pe.DisplayText = "Blue";
 90                 pe.EntityData[PeopleEditorEntityDataKeys.DisplayName] = "Blue";
 91                 pe.EntityType = SPClaimEntityTypes.FormsRole;
 92                 pe.IsResolved = true;
 93                 pe.EntityGroupName = "Favorite Color";
 94 
 95                 resolved.Add(pe);
 96             }
 97 
 98         }
 99 
100         protected override void FillSchema(Microsoft.SharePoint.WebControls.SPProviderSchema schema)
101         {
102             schema.AddSchemaElement(new SPSchemaElement(PeopleEditorEntityDataKeys.DisplayName, "Display Name", SPSchemaElementType.Both));
103         }
104 
105         protected override void FillSearch(Uri context, string[] entityTypes, string searchPattern, string hierarchyNodeID, int maxCount, Microsoft.SharePoint.WebControls.SPProviderHierarchyTree searchTree)
106         {
107             if (!EntityTypesContain(entityTypes, SPClaimEntityTypes.FormsRole))
108                 return;
109 
110             if (searchPattern.ToUpper().Contains("BLUE"))
111             {
112                 PickerEntity pe = CreatePickerEntity();
113                 pe.Claim = CreateClaim(m_claimType, "Blue", m_claimValueType);
114                 pe.Description = Name + ":" + "Blue";
115                 pe.DisplayText = "Blue";
116                 pe.EntityData[PeopleEditorEntityDataKeys.DisplayName] = "Blue";
117                 pe.EntityType = SPClaimEntityTypes.FormsRole;
118                 pe.IsResolved = true;
119                 pe.EntityGroupName = "Favorite Color";
120 
121 
122                 searchTree.AddEntity(pe);
123             }
124         }
125 
126         public override string Name
127         {
128             get { return "SimpleCCP"; }
129         }
130 
131         public override bool SupportsEntityInformation
132         {
133             get { return true; }
134         }
135 
136         public override bool SupportsHierarchy
137         {
138             get { return false; }
139         }
140 
141         public override bool SupportsResolve
142         {
143             get { return true; }
144         }
145 
146         public override bool SupportsSearch
147         {
148             get { return true; }
149         }
150     }
151 }

Before we move on, let’s just call this foreshadowing.

Problem is, this statement was at odds with the behavior that I, and many of you, were seeing/have seen. It just didn’t seem to be true. Clearly, I was seeing that very nearly every single time a page load occurred, my custom claims provider was invoked. Looking at a Fiddler trace, it was also obvious that I wasn’t receiving a 401 on every page request, either. This was certainly different than a web application configured for Windows Classic authentication – where you can sometimes see a 401 on every page load.

First, a refresher on the oddities of a claims based web application.

When a web application is configured for claims based authentication, the IIS binding has Anonymous access enabled on it. This is because, unlike with Windows Classic, authentication is a SharePoint problem with claims (SAML or Windows). SharePoint 2010 manages this via a module (or two) within the IIS pipeline. The enablement of anonymous access generally goes unnoticed by most administrators, since its one of a myriad of settings that the product sets on the IIS binding for a web application. My personal experience is that when administrators do notice this, they generally freak out. It’s okay. The product did this on purpose; if it didn’t you wouldn’t have all that fancy claims-based authentication federating with your partner ADFS instances and delegating the pain of user management. This is a feature.

Refresher over.

So, why do I see a ton of 401’s when running under Windows Classic, but only one, at session start, under Windows Claims? And how does this influence the frequency with which my custom claims provider is going to get called?

401’s with Windows Classic

Under Windows Classic, IIS is in charge of authentication. And IIS says that if a request doesn’t include an Authorization header, it is challenging for credentials based on the configuration of the site. Therefore, you’ll see a lot more 401’s under Windows Classic. Now, a 401 is expensive. With NTLM authentication, every 401 means that an Active Directory Domain Controller was interrogated to validate the passed credentials.

When you’ve got a web application that is configured for Windows Claims only, and Windows Claims is the only authentication type specified for that web application, you execute a very unique code path within the authentication system. If you run a Fiddler trace you’ll notice that after the initial 401, a cookie, WSS_KeepSessionAuthenticated, is set on the browser. This cookie is an index into a token cache maintained by SharePoint, and is actually a chunk of code left over from SharePoint 2007 that is only invoked when a site is:

1. Configured for Claims Based Authentication
2. Only configured for Windows Claims (i.e. NTLM or Kerberos authentication)

Remember that integrated mode module that we talked about before? The one that handles authentication for claims based web applications? When this module sees the WSS_KeepSessionAuthenticated cookie, it checks the state of the cached token that the cookie value points to on the server, and in so doing executes a code path that iterates over all registered claim providers and, as a result, winds up calling FillClaimsForEntity on each one that returns true from SupportsEntityInformation (For more information, see the SPClaimProvider documentation on MSDN).

We’ll cache the token according to settings specified on the security token services configuration (accessible via PowerShell by calling Get-SPSecurityTokenServiceConfig). As a side benefit, we don’t wind up issuing a 401 on ever page request in this model, significantly reducing authentication overhead and domain controller impact, but we do wind up calling any registered claim providers a lot. Lesson: Optimize your claim providers – slow downs in authentication will equal a slow site.

Now, add a second authentication mechanism, and things suddenly change. Under Windows Claims, if a second authentication method is defined for the URL – say, Forms, or a Trusted Identity Provider – we stop issuing the WSS_KeepSessionAuthenticated cookie, and start issuing a FedAuth cookie instead. The FedAuth cookie is the the cookie we issue when you are using SAML Claims, FBA, or Windows Claims with multiple authentication providers. The details of authentication when a FedAuth cookie is used are significantly different; for instance, we’ll only call registered claim providers when an actual FedAuth cookie is issued, as that’s the time authentication really occurs; we’ll only re-execute registered claim providers when the cookie expires and an authentication is forced again.

All this talk of Windows Authentication and cookies might have some folks wondering – cookies can be a real pain, I went with Windows Authentication to avoid cookies and the pain they bring. Remember the death by a thousand cuts that was the integration  of Office 2007 and SharePoint FBA applications under SharePoint 2007 before Service Pack 2 (and a litany of other conditions)?

Using cookies to streamline the authentication process is actually okay with Windows Authentication, because the browser first authenticated with Windows Auth, and will respond seamlessly if it receives a 401 down the road. The fact that it’s not getting 401’s mean faster browsing for you, less chatter between the server and the domain controller infrastructure (in the case of NTLM authentication), etc. Should a 401 be issued, the client will know just what to do.

Remember earlier, when my colleague tried telling me that my custom claims provider will have its FillClaimsForEntity called on every authentication? Turns out, he was right – every time I authenticate, even if the authentication process is short circuited (ala WSS_KeepSessionAuthenticated and Windows Claims), my custom claims provider will be invoked. Sometimes, though, I authenticate a lot less than I thought I would!

I hope this helps those folks that are trying to understand the complexities behind custom claims providers and the logic behind their invocation.

Once you've created a database, though, going back and adding a failover partner can only be done via PowerShell - the Central Administration UI is disabled for this purpose. This is easy enough to do:

1 # Set failover database server
2 $database = Get-SPDatabase | where { $_.Name -eq "SomeSharePointDB" }
3 $database.AddFailoverServiceInstance("FailoverSQLServerName\OptionalInstanceIfUsed")
4 $database.Update();

What's less obvious is what you need to do when you want to turn things off. For instance, when you are adjusting your mirroring configuration and need to replace (or even remove altogether) the failover partner for a time. If you are just changing the name/instance of the failover partner, you can just re-run the script above to adjust the failover partner server name. If, on the other hand, you are removing the failover partner entirely, you'll need to execute the above script but specify either the PowerShell special variable $null as the failover partner server name, or an empty string - either will work. In so doing, you'll remove the failover server configuration for that database, and SharePoint will adjust the connection string it uses when connecting to that database, removing the Failover Partner attribute.

It's not obvious, but there are some hints in the user interface regarding how to make this kind of configuration work. Namely, when configuring a directory synchronization connection, you can specify the type of authentication provider that'll be used to access the imported profiles, and in the case of a trusted claims provider, you can even select the specific trusted provider configured in the farm.

Unfortunately, if you stopped here - and most people do - you'll be dissapointed to fine that while your profile imports succeeds just fine, when you log in as a user via the trusted claims provider you specified your login won't be associated to its corresponding profile in the user profile store. What gives?

Well, it turns out that in order to give the user profile system enough information to map your imported profiles to incoming authetnicated users, you have to tell it what imported attribute is going to correspond to the authenticated users identity claim. Remember, when you configured your trusted identity provider, you specified a claim as the identity claim - this claim is immutable, you can't change it once you've configured the trusted identity provider. In order to map users properly, you have to tell the user profile system which of the innumerable attributes it may be importing is going to be used as the identity claim. Once you give the profile system that information, it'll have enough information to calculate what the identity claim of the profile will be when someone logs in for it.

So, what property do we need to map? Well, obviously enough, it's the Claim User Identifier property.

In the screenshot above, you'll notice that I've got my property mapped to the mail incoming attribute. This is just the claim I chose to use in my setup - you can use whatever you'd like, but remember it'll need to be the attribute that's being presented as the identity claim from the trusted identity provider.

Once this is in place, firing off a user profile import will result in your users suddenly getting associated to the correct profile. Yay!

Hope this helps anyone out there who's been struggling with getting this working!

Great job, guys!

In SharePoint 2010, service applications sometimes have dependencies on other service applications. Take User Profiles for instance. While in 2007, the SSP managing user profiles also handled multi-value profile properties, in 2010, things are different; User Profiles store multi-valued properties as tags within an instance of the Managed Metadata service. While playing around on one of my test farms, I stumbled upon a weird error condition that took me a minute to diagnose and fix.

If you do even a cursory search for the error "There was a problem retrieving data for this field. Updating values in this field is disabled temporarily. You can still update values in other fields.", you'll find a variety of postings that'll tell you that you forgot to provision a Managed Metadata service application. Imagine my surprise, then, when I pulled up my list of service applications for this farm:

As you can see in the image above, there is my User Profiles application, and there is my Managed Metadata application. I'm not partitioned, or consuming from a services farm, so this is all pretty straighforward.

All applications - service applications, Web applicatoins, etc. - are associated with other service applications that they may consume by way of proxy group. While you get to configure explicit proxy associations when you are provisioning a web application, service applications don't give you that option - they are always associated by default to the default proxy group.

Navigating to Application Management -> Configure Service Application Associations and choosing the Service Application view revealed my problem.

 The default proxy group didn't contain my Managed Metadata proxy - which meant that even though it was provisioned, my User Profile service application couldn't make use of it! I can fix this two ways - I can customize the service application associations for the User Profile service application, or I can just click on the default proxy group link from the Configure Service Application Associations page and add my Managed Metadata proxy to that proxy group...

Press OK on that dialog and a quick check of my My Sites profile edit page shows that all is well.

We frequently give people the advice that they should run Central Administration on more than a single machine in the SharePoint farm. The thought goes that, if something really bad were to happen and you lost the machine in your farm that runs Central Administration, if you've got a second machine, you can use that instance of Central Administration while you work out the problems on the first machine. I believe there are even rules in the best practices analyzer we ship that will warn you if it detects that you aren't running multiple copies of Central Administration.

The problem with this guidance is that it neglects two fundamental truths about humans:

1. We're lazy, by nature. If you tell us to do X and Y, don't just assume that we'll also do Z. You may have expected us to realize that we needed to, but we are lazy. If you'd like us to do Z, you should tell us so.
2. We're forgetful in stressful situations. If you tell me a phone number I can remember it. If you tell me a phone number while I'm in the middle of taking a test, I'm going to have a hard time remembering it; my brain is doing other things (like bathing in adrenaline, amongst other chemicals).

The first instance of Central Administration that is installed can be thought of as the default instance. The URL of this instance becomes the public URL for all subsequent installations of Central Administration. When you add Central Administration to a second server, you are not only configuring that server to serve the Central Administration web site, you are also configuring an additional internal URL in the Alternate Access Mappings (AAM) for the Central Administration site - but the public URL remains the same, no matter how many instance of the Central Administration web site you configure. Take the following scenario:

• I install Central Administation on APP1 on port 1234; this is the first server in my farm.
• I install Central Administration on APP2; this is the second server in my farm.

In this scenario, you'll notice three things:

1. If, on APP2, you click the link in the Start Menu for Central Administration, that you are taken directly to https://APP1:1234, not the local instance of Central Administration (https://APP2:1234)
2. If you try and navigate to https://APP2:1234 you are immediately redirected to https://APP1:1234/default.aspx.
3. If you try and navigate to https://APP2:1234/default.aspx, you stay put - for a little while. Eventually, you click something and find yourself whisked away to https://APP1:1234/ again.

To understand what's going on, you have to first understand a little bit about something called Alternate Access Mappings, or AAM. AAM was a feature introduced in SharePoint 2003 SP1, and further refined in SharePoint 2007, that allows SharePoint to accept requests on one URL, but reply with another. This was intended to support scenarios like SSL offloading, where you terminate the (computationally expensive) SSL connection between the clients browser and the server at a proxy or load balancer, freeing the web front ends CPU to focus on serving requests and not decrypting HTTP traffic. When this happens, SharePoint receives the request with an https:// URL, but when it responds, needs to make sure it responds with an https:// URL anywhere that SharePoint would send a full URL (and not a relative one, like an <img> tag). This happens in lots of places, in view state data, in a few places where we dynamically generate JavaScript, etc. And it also happens when you request the root page of a SharePoint web application and we send you a 302 redirect to the correct page.

Which would explain why, in item #2 above, when you type in https://APP2:1234, you are immediately sent elsewhere. SharePoint received a request, looked at the AAM table to determine what URL to send back, and sent back a 302 redirect with a Location header of https://APP1:1234/default.aspx. https://APP1:1234 is the Public URL of the only zone configured for the Central Administration site.

What about item #1 and item #3? Well, for Item #1, the link to Central Administration in the Start Menu is actually a link to run the local instance of PSConfigUI, with a flag that says, "Open Internet Explorer and navigate to the Central Administration site". PSConfigUI determines the URL of the Central Administration by looking at a registry key - a value that is not updated once set on a server. It's the value of the Public URL of the default zone of the AAM settings for Central Administration, as it was set at the time that that server joined the farm. You can find this registry key (for SharePoint 2010) at HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\WSS\CentralAdministrationURL. You can change the Public URL in the AAM table for Central Administration all day long, and this key will never get updated. You have to update it by hand.

As for Item #3, you postponed the inevitable - namely, SharePoint didn't have to send you a 302 redirect, and therefore didn't have to calculate the full URL using the Public URL of the zone your request was mapped to, in order to satisfy the request.  Now, eventually you'll take some action in which SharePoint will either instruct your browser to request the configured Public URL or you'll get an outright 302 for any of a myriad of reasons, at which point you'll be whisked off to the original URL.

There. That's the behavior. Whew. What were we talking about again? Oh, yeah - the guidance that you should run multiple instances of Central Administration in your farm.

So, based on all the above material (hereinafter referred to as background), you may be wondering just what good a second instance of Central Administration is really going to do you. Well, the bad news is that unless you document a few things, not a whole lot. This takes me back to my second fundamental truth of humans - that we don't operate as effectively in stressful situations as in non-stressful situations. Think of it - it's 2:00AM, and you've just been paged because one of the servers in your corporate SharePoint farm just decided to go visit it's mother in Toledo. It's shot, gone, sind gebrochen. Whatever. You jump on a different box, go to pull up Central Administration, and *bam* get an error because that box is directing you to a URL on a server that is busted - which is the whole reason you're up at 2:00AM anyway. So you think, "I've got CA loaded on APP2, I'll just jump on that", and you crack open Internet Explorer and type in (frantically) https://app2:1234/.

And you get another error message - the same error message you got by following the Central Administration link. You look at the URL - it shows https://app2:1234 - and you start panicking. Both boxes are down? How can that be?

You then devolve into a puddle of troubleshooting mush as you start flailing around, your sleep and caffeine deprived brain struggling to come to grips with the imagined enormity of the outage you begin to believe you are looking at.

Now, this behavior is perfectly reasonable given what we now know about Central Administration and AAM. Specifically, the first link broke because we have a dead server; that one should be obvious. But why the second failure? The second failed because SharePoint sent us a 302 redirect, and it used the public URL of the Default AAM zone (the only zone configured for Central Administration) to do it - and unfortunately, that means we got a 302 redirect that sent Internet Explorer off looking for the dead server again. Since the 302 redirect failed, though, Internet Explorer didn't change the address in the  browser bar. While at first blush it would seem that it should have, an argument could be made - one that I'd come down in support of - that Internet Explorer shouldn't reflect a redirected URL when it hasn't actually redirected you anywhere. The fact that this is a case in which the predictability of browser behavior tends to cause more confusion that it reduces is another matter entirely.

So, when you find yourself in this pickle, what to do? Well, it's simple really. The command line always works. For SharePoint 2007, you can manipulate the Public URL for the default AAM zone to reflect the address of the second server; for SharePoint 2010, you can use PowerShell. To do this in 2010, you'd type something similar to:

New-SPAlternateURL -WebApplication <old CA URL> -Url <new CA URL> -Zone Default

Taking our example above, this would result in a command that looks like:

New-SPAlternateURL -WebApplication https://app1:1234 -Url https://app2:1234 -Zone Default

We do actually have this procedure documented in the article Rename a stand-alone server. While the cause in the articles scenarios and the one with which we've concerned ourselves today are entirely dissimilar, the symptom and remedy are not.

It's also an entirely unsupported fact that, even when the Public URL is configured for a URL that would be different for your second Central Administration hosting server, it just so happens that Central Administration does work well enough and long enough to manipulate AAM entries into something proper, all through the UI. Just note that you'll need to explicitly specify default.aspx - as in https://app2:1234/default.aspx - in your request, otherwise you'll be redirected by the calculated 302 redirect.

And lastly, I'll leave you with this thought: Central Administration is just another web application, albeit a slightly special one due to the manner with which it is provisioned. But ultimately, it operates in a fashion not entirely dissimilar to other SharePoint web applications. Given that you have control over the AAM url configured for the Central Administration web site, there really is nothing stopping someone from load balancing Central Administration. As crazy as it sounds, you could edit the default public and internal URL to be https://centraladministration.contoso.com, and configure a load balancer to balance requests at that URL across a few different boxes. It would (and does) work fine. But that'd be just crazy?

Wouldn't it?

[Update: For the sake of completeness, no it's not crazy, and in fact my friend Spence has written up a quite lengthy and most splendid article describing how to do just that. Read all about it at https://www.harbar.net/articles/spca.aspx!]