The page cannot be displayed because your server’s current configuration does not support it. To perform this task, use the command line operations in Stsadm.exe.

How odd, given the emphasis on PowerShell in SharePoint 2010! After a bit of head scratching and examining application and ULS logs, I navigated to the Central Admin home page and everything appeared to be fine, but then when I got around to creating a new Site Collection a bit later, I got the same error, even though I was able to create web/service applications. I had the same error when logged on as farm admin, farm admin + local admin rights, farm admin + SQL SysAdmin and farm admin + domain admin rights, so I was pretty sure it wasn’t a permission issue (and I should note my temporary fiddlery here is only really suitable for non-production environments). This error also occurred on some other Site Collection-specific pages.

After searching for a solution I found a number of suggestions that this was related to insufficient rights for Active Directory Account Creation Mode. So I played around with SQL permissions/accounts a bit more and was eventually able to loosen things to the point where I could create a new site using PowerShell (still no luck using Central Administration). I also (strangely), had to specify an outbound e-mail server first!?!?! ULS Viewer unveiled that mystery, as well as an error attempting to create an account for my logged on user (which obviously already exists) in Active Directory. This error didn’t prevent me from creating the site, but this behaviour confirmed that the site was definitely running in Active Directory Account Creation Mode.

What is Active Directory Account Creation Mode?

Unfortunately, current Microsoft documentation is non-existent as far as I can tell, so I’ll start with the TechNet description from WSS2:

A new feature of Microsoft Windows SharePoint Services is account creation mode for Active Directory directory service. This feature replaces the local account creation feature in SharePoint Team Services 1.0 from Microsoft. Use Active Directory account creation mode when it is necessary to create new user accounts rather than using existing domain accounts. For example, an Internet service provider (ISP) might need the ability to allow SharePoint site owners the capability to create user accounts or invite users to collaborate on a Web site where existing domain accounts for those users do not already exist.

Basically it’s a hosting mode in which SharePoint creates new users in Active Directory and these are the only accounts that can be used in this mode. I can attribute my lack of experience with this mode to my lack of experience with the free versions of SharePoint. Nearly all of my work has been focused on SPS2003, MOSS 2007 and SPS2010. I can’t pin down for certain whether this mode ever existed in the full versions of the product, but according to this article it is now SharePoint Foundation-only and greyed out for SharePoint Server 2010. This TechNet forum post from published SharePoint author and MCC John Ferringer seems to back up that assertion. This post describes the mode well and also appears to answer my next question (my italics, John’s bold):

SharePoint Foundation 2010 (the “free” version of SharePoint that is the successor to Windows SharePoint Services, or WSS) does have something called “Active Directory Account Creation” mode available, which functions much like what you saw in WSS v2. Accounts are first created in SharePoint, and then added to an Organizational Unit in Active Directory. The problem is that this mode is only available at the time you install SharePoint, (its an option off the Advanced Settings button) and you can’t change that configuration setting after the fact. Additionally, you can’t use existing AD accounts in that SharePoint farm, you’ll only be able to use accounts that you create through the tool and you can’t give an account an email address that’s already used by another account in AD. So you need to be mindful of those limitations if you chose to use that mode.

I wish I’d seen this post sooner. It would have saved me some time. For what it’s worth, my investigation backs up this description as follows:

• There is no facility to disable this mode through Central Administration.
• The STSADM commands only support identifying whether WSS is in Active Directory Account Creation Mode using stsadm.exe -o getproperty -pn createadaccounts. There is no corresponding setproperty command.
• The PSCONFIG commands only support creating the farm in this mode – there does not appear to be a means of reverting from it. I believe the configdb’s addomain and adorgunit parameters are responsible for enabling this mode (I could be wrong – the documentation is a bit scant), but I can’t find a facility for reverting it.
• PowerShell is now the preferred means of creating the farm and would be the preferred means of enabling this mode using the New-SPConfigurationDatabase command. As far as I can tell the DirectoryDomain and DirectoryOrganizationUnit parameters are responsible for enabling this mode now, although again, the documentation is unclear to me.
• I even tried to make the change through the API with the help of a friendly neighbourhood developer. Things have changed a bit from WSS2 to WSS3/SharePoint Foundation. At any rate, we found the attribute and set it to “false”, but unfortunately this did not rescue my nascent farm.

In short, it looks like there’s no way back.

How Could This Have Happened?

Given that this mode is only supposed to be present in SharePoint Foundation, I’m really at a loss to explain how I activated it on SharePoint Server 2010. I may have fat-fingered one of the New-SPConfigurationDatabase DirectoryDomain or DirectoryOrganizationUnit parameters I suppose, but I would be really surprised if I did that in a way that allowed me to successfully run the command. In the end, I reverted to my pre-installation snapshots and rebuilt my farm. I don’t feel that was such a waste now that I’ve found John Ferringer’s description and realise there never would have been a way back, but if you find this post through similar folly, hopefully you won’t waste any time trying to revert the farm like I did.

Interestingly, while researching this topic, I stumbled across a TechNet forum post from Andrew Milsark of FPWeb stating that they’ve, “moved away from using AD Account creation mode all together”.

To fix this just requires a couple of lines of PowerShell, courtesy of this article (to which I’ve added some clarification here).

If you go to the Manage Service Applications link you’ll see the problem:

Open the SharePoint 2010 Management Shell and Run as Administrator.

Update, 10 January 2011
Tom suggested an improvement in the comments here, which I agree is better!

$sap = Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq “Usage and Health Data Collection Proxy”}
$sap.Provision()

Original approach

Run Get-SPServiceApplicationProxy to enumerate the IDs of all the Service Application Proxies in your farm.

(note: you will probably have more Service Application Proxies than these)

Copy the ID for the WSS_UsageApplication.

Run the following two lines of PowerShell.

$UP = Get-SPServiceApplicationProxy | where {$_.ID -eq "<PASTE COPIED ID HERE>"}
$UP.Provision()

If you refresh the Manage Service Application page the proxy should be started now.

Once that has been configured, the usage data will not appear immediately in all of the usage reports because the timer jobs to collect the data will not have run yet. The granularity of the data collection and processing is pretty fine if you want to reconfigure them for your needs, but keep in mind that none of the Web Analytics reports will appear for at least 24 hours after this fix is in place. They do not allow reporting on the current day. If you try to configure a Custom Date Range to include today’s date you will get the following message:

I’ll try to track this issue as updates come out.