Browsed by
Tag: Managed Accounts

SharePoint Connections Las Vegas 2011 Wrap up

SharePoint Connections Las Vegas 2011 Wrap up

I just completed my 5 sessions, 3 of which I presented with my great friend Cornelius J. van Dyk, here at SharePoint Connections Las Vegas.  While here we received several pieces of great news:

1.) O’Reilly has green lit our book “SharePoint for Business Intelligence” which will be coming out in 2012 and will revolve around how you can solve business problems using SharePoint 2010, SQL Server 2012, & Visual Studio LightSwitch technologies for Business Intelligence.

2.) We will be doing our “SharePoint Disaster Avoidance for Large Scale Enterprises” post conference  and several other sessions for the SharePoint Connections Las Vegas show in March 2012

3.) Power was finally restored to my house in Nashua after more than 6 days!

I had almost 450 attendees across my 5 sessions and I sincerely hope that you all enjoyed the conference as my as I did.  As promised, here are links to my final decks:

SharePoint Logging & Debugging: The Troubleshooter’s Best Friend

SharePoint Performance: Best Practices from the Field

Battle Scarred But Still Standing: A SharePoint Administrator’s Tell All

Heavy Metal PowerPivot Redux

Human Workflow with Visio 2010 and SharePoint Designer 2010

Heading home tonight and then back to the SharePoint Road Trip on Thursday to hit SharePoint Saturday Denver!

PowerShell Account Creation Script

PowerShell Account Creation Script

When building repeatable SharePoint farms I need to quickly create new service accounts. Since there is no need for a SharePoint Farm to be built using a Domain Admin account, there is really no need for a SharePoint Consultant to ask for or be granted Domain Admin rights.

I spent a good portion of my career prior to SharePoint as a Domain Admin/AD Architect, and a good portion of that role is knowing that most people who ask for Domain Admin rights don’t actually need them.

If you want to start off on the right foot with the AD team in any company, tell them you do not want or need Domain Admin rights. Immediately you have more credibility with them than most other people.

As a result of this, I have put together an account creation script that I use and turn that over to the Domain Admins so that they can handle the creation for me. I simply list out the accounts that I want and then populate them into the following PowerShell:

$domainName = $env:USERDOMAIN
= “LDAP://CN=Managed Service Accounts,DC=$domainName, DC=%local%
$objCN = [ADSI]$LDAP
= $objCN.Create(“user”,“CN=%Friendly Name%)
$objUser.psbase.invokeset(“AccountDisabled”, “False”)

Using the $env:USERDOMAIN I am able to grab the current logged in domain context rather than having to specify it. Make sure that you change the last DC to the correct domain suffix (.com, .net, .org, etc). You will need to specify the %Friendly Name% & %SAMAccountName% that you are trying to create.

The code above will allow you to create accounts that are active immediately without additional intervention.

There are additional steps that need to be taken to grant rights for the User Profile Sync account and local Administrator rights that need to be granted to the Farm Admin account, but those will get covered in later posts.

Sample scripts: powershell notepad

Set-SPManagedAccount syntax for password resets

Set-SPManagedAccount syntax for password resets

Working with the PowerShell command for Set-SPManagedAccount this morning I found that the TechNet bulletin for this command has an inaccuracy with regard to password changes. 

When trying to reset a password from PowerShell I followed the syntax and used:

Set-SPManagedAccount –Identity domainaccount AutoGeneratePassword true

I got the following error:

Set-SPManagedAccount : A positional parameter cannot be found that accepts argument ‘true’.
At line:1 char:21
+ Set-SPManagedAccount <<<<  -Identity domainaccount -AutoGeneratePassword true
    + CategoryInfo          : InvalidArgument: (:) [Set-SPManagedAccount], ParameterBindingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.SharePoint.PowerShell.SPCmdletSetManagedAccount

Turns out that the command has been changed and there is now no need for the “true” flag as the default is now “true” but you get the opportunity to choose (unless you pass the -confirm:$false flag)

The result of passing the command without the “true” looks like this:

Are you sure you want to perform this action?
Performing operation “Set-SPManagedAccount” on Target “USsvc-ssaspfarm”.

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is “Y”):

If you select “Y” the system will change the password for you with an automatically generated password.  If you want to validate the change an easy way to do it is to follow my previous blog post,, to view the passwords before and after you run the command.

How to: Get your Managed Account passwords when they are changed automatically by SharePoint 2010

How to: Get your Managed Account passwords when they are changed automatically by SharePoint 2010


Using Managed Accounts the way that SharePoint 2010 is designed you allow SharePoint 2010 to manage your password changes automatically for you. Your farm gets into an inconsistent state, or you allow SharePoint 2010 to change your farm admin account and you realize that you cannot start the UPS without knowing the farm account password. What do you do?


Run the following PowerShell command from the SharePoint 2010 Management Shell as a Farm Administrator:

function Bindings()
return [System.Reflection.BindingFlags]::CreateInstance -bor
[System.Reflection.BindingFlags]::GetField -bor
[System.Reflection.BindingFlags]::Instance -bor
function GetFieldValue([object]$o, [string]$fieldName)
$bindings = Bindings
return $o.GetType().GetField($fieldName, $bindings).GetValue($o);
function ConvertTo-UnsecureString([System.Security.SecureString]$string)
$intptr = [System.IntPtr]::Zero
$unmanagedString = [System.Runtime.InteropServices.Marshal]::SecureStringToGlobalAllocUnicode($string)
$unsecureString = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($unmanagedString)
return $unsecureString

Get-SPManagedAccount | select UserName, @{Name="Password"; Expression={ConvertTo-UnsecureString (GetFieldValue $_ "m_Password").SecureStringValue}}
The output will look similar to:
Special Thanks:
Huge thanks to Microsoft for unveiling this nugget to us during a recent call to SharePoint CritSit support. Derek Martin, of Slalom Consulting, and my jaws collectively hit the floor when they showed us this one and we knew we couldn’t keep it to ourselves.
Update: Thanks to Todd Klindt for pointing out that the Live Writer Add-in that I have been using makes the code easily readable, but horrible to copy. Download the .ps1 file from here or the text file version from here rather than trying to copy from above and save yourself some time.
powershell notepad
SharePoint 2010 Farm Service Account passwords expired?!?!?!?

SharePoint 2010 Farm Service Account passwords expired?!?!?!?


Managed service accounts passwords expired.  Access to part of Central Administration are no longer accessible.  Sites are starting to go down because app pool passwords are managed accounts and have expired.

Soapbox moment:

Firstly, there is NO real excuse for this in SharePoint 2010 because the ability to have this done automagically for you is BUILT-IN, so either your farm admin is so over taxed (usually the case) or incompetent (the two aren’t mutually exclusive). 
I take the liberty to say all of this as someone who has had this happen to them, otherwise I wouldn’t be able to write about it, right?


To start, you aren’t going to be able to do anything with SharePoint until you can get the Timer Job Service running again because everything is driven by timer jobs. 
Using a credential that has full admin rights to the box and is a Farm admin, change the account the Timer Job Service runs as and start the service.  This must be done on all servers in the farm. 
Don’t fret, the next things you are going to do is fix this back to the way it should be but you can’t do the next steps without the timer job service running, so just play along.

Go to and edit your farm service account and tell it to change the password now.

Go to and select Farm Account.  You will see your registered service account (the one that you just changed the password for) and click ok.  This will go reset your Timer Job Service account to the registered account which now is active and working.
Next, create a text file called on your server which will be a list, one account per line, of service accounts that you are going to have auto-updated.

Then using the SharePoint 2010 Management Shell interface change the passwords and set to auto change run using this variable script:

foreach ($account in Get-Content driveletter:filename.txt)
Set-SPManagedAccount -Identity $account -AutoGeneratePassword -PreExpireDays n#days -Schedule “monthly between n#dayofthemonthvalue hh:mm:ss and n#dayofthemonthvalue hh:mm:ss” -confirm:$false

The script that I actually used, without the variables looks like this:

foreach ($account in Get-Content c:managedaccounts.txt)
Set-SPManagedAccount -Identity $account -AutoGeneratePassword -PreExpireDays 30 -Schedule “monthly between 7 02:00:00 and 7 03:00:00” -confirm:$false

Once this command has completed successfully you will see that your last password change just happened and that your next password change is scheduled.  Make sure that if your next scheduled password change isn’t in conflict with a password change minimum group policy that won’t allow passwords to be changed before a minimum number of days or you will end up with some errors in your ULS Logs and some misfired password change attempts.

Lastly, go to and walk through all of the farm credentials and let the accounts get synced up.  This should re-spin up the app pools and get your users back into the site, but if not, do an IISRESET and things should be back online.

Shout outs

Huge thanks to my partners in crime on this one, Derek Martin and Trent Foley of Slalom Consulting, for helping with the out of the gate perfect PowerShell scripts that are referenced above.

While I was busy figuring out how to break back in to Central Admin, they figured out the proper script to reset the passwords and set the auto change programmatically.  This script can be used in advance of this type of shenaniganal activity to ensure that while you are building your farm you get this set right the first time and not have to do it manually (which is often the excuse when you are using 30+ managed accounts in a farm).