Earlier this week, I had the misfortune of generating an error I’d never seen before when building a new SharePoint Server 2010 farm. The error first emerged when the SharePoint installation process landed me at the Farm Configuration Wizard page. I wouldn’t have been running it (not advisable ever, really), but it’s the first page that loads after the Product Configuration Wizard completes, so my first Central Administration page was this error:
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”.
On TwitterMy Tweets
- Fixing the Usage and Health Data Collection Service Application Proxy on
- Activating a Windows Server 2012 R2 evaluation installation with an MSDN license on
- Adding Drivers to Windows Deployment Services Boot Images on
- RMS Publishing Permissions for SharePoint 2010 Application Pool Identities on
- Office 365 Single Sign Out with ISA or TMG as the ADFS Proxy on
- Administrivia (1)
- Authentication (16)
- Business Continuity (3)
- Client applications (18)
- Consultancy and Design (20)
- Hardware (9)
- IT Management (13)
- Miscellaneous (5)
- Mobile (4)
- Networking (18)
- Office 365 Grid (5)
- Performance (26)
- Power (2)
- Security (29)
- SharePoint (81)
- Unified Communications (3)
- Virtualisation (30)
- Windows (60)
TagsActive Directory administration Amazon Web Services ASUS binding certificates Claims Cloud DCOM Dell development DNS EC2 FIM Graphics Hyper-V IaaS ICS IIS Information Rights Management Intel IRM LDAP Lync Office 365 PowerShell RMS SAML Search Service Application SharePoint SharePoint 2007 SharePoint 2010 SLAT SSL STSADM User Information User Profile Virtual Machine VMWare w3wp Windows 7 Windows Deployment Services Windows Server 2008 R2 Workgroup
Subscribe to Blog via Email
Archives by Month