Recently, I began working extensively with SharePoint 2010 and of course after receiving a new Dell 64bit M4500 Mobile Workstation I wanted to install a SharePoint instance on my Win 7 OS. The instructions for installing a single server SharePoint Farm on Win 7 can be found on MSDN.
One thing I learned through this process is that even though you are installing a single SP instance on Win 7 the installer enforces rules as though you are installing on a corporate domain. One of these rules I found is that the installer won’t let you use local security accounts. So the service account I created (myMachine\sp_AppPool) was not acceptable to the installer because it complained about it not being a domain account. To work around this at the time I simply used my own corporate domain account and let the installer merrily continue installing with the expectation I would fix this later.
It turns out that Central Administration also enforces the same domain account rule. Going to Central Admin | Security | Configure Managed Accounts | Register Managed Account will still prevent you from adding sp_myMachine\AppPool as a Managed Account because it is not a domain account.
So Now what? Well it turns out that PowerShell has functionality that can create Managed Accounts in a Cmdlet named New-SPManagedAccount. So after I created the service account myMachine\sp_AppPool in Windows I executed the following PowerShell command to add it to the list of SharePoint Managed Accounts.
$cred = Get-Credential
New-SPManagedAccount -Credential $cred
The first line opens a dialog box where you enter the user myMachine\sp_AppPool and associated password. The second line’s Cmdlet will complain that you are attempting to add local account as a managed account so just acknowledge that you are aware of this at the prompt and the Cmdlet will add the account anyway.
The next thing you need to do is assign the Managed Account to an Application Pool which can be done using Central Admin as well as PowerShell. Since I was in the PowerShell mood I looked up the following snippet to assign the account to my Central Administration Web Application’s Application Pool.
$WebApplication = Get-SPWebApplication http://<myMachine>:<myPort#>;
$ManagedAccount = Get-SPManagedAccount -Identity "<myMachine>\sp_AppPool";
$WebApplication.ApplicationPool.ManagedAccount = $ManagedAccount;
The nice thing about using PowerShell over Central Admin is that your actions are always documented (assuming your using the ISE or PowerGui or some other script writing tool). So if my actions ever break something and I don’t understand why I can just reverse them easily by using the same scripts to reassign back to the previous accounts.
So now the service account is properly assigned to the Web Application from SharePoint’s perspective but looking at the IIS Management Console the Application Pool’s Identity for the Central Administration Web Site is still using the old account. So again, I decided to go the PowerShell route and looked up the following script to change the Identity for the App Pool.
$CAAppPool = get-item 'iis:\AppPools\SharePoint Central Administration v4'
$CAAppPool.processModel.userName = "<myMachine>\sp_AppPool"
$CAAppPool.processModel.password = "<myPasswsord>"
$CAAppPool.processModel.identityType = 3
$CAAppPool | Set-Item
After executing all of the above scripts I opened up Central Admin and found the site returned a 500 error. A quick trip the my event log found an error that indicated an Execute permission was denied on the SharePoint Administration Content Database which was solved by adding the sp_AppPool account to the dbo role on that database and all is well again.
If you have any suggestions on or thoughts on this post please feel free to comment.