Browsed by
Tag: Credential Management

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:

Confirm
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, http://sharepointlonghorn.com/how-to-get-your-managed-account-passwords-when-they-are-changed-automatically-by-sharepoint-2010/, to view the passwords before and after you run the command.

SharePoint 2010’s Visio Graphics Services: EventIDs 8061 & 8046 unmasked

SharePoint 2010’s Visio Graphics Services: EventIDs 8061 & 8046 unmasked

Getting EventIDs 8061 & 8046 in your ULS Logs and Event Logs on your application server?  Having trouble figuring out exactly what they are trying to tell you?  Finding inconsistent results between site collections?  Let’s dive in…

Here are the offending errors:
2

screenshot.142

1

screenshot.143

TechNet tells us: quoting directly from the article linked here

Symptoms:   One or more of the following symptoms might appear:

  • A file or files might not load.
  • This event appears in the event log: Event ID: 8061 Description: File not found at this location: <file location>.
  • This event appears in the event log: Event ID: 8051 Description: Unable to parse file at location: <file location>.

Cause:   One or more of the following might be the cause:

  • A user might try to load a page that contains a Web Part that references a file that no longer exists or is invalid.
  • A user might try to view a Visio diagram that is corrupted.
  • A user might try to view an invalid Visio diagram.

Unfortunately this really doesn’t help you identify what the problem is or how to resolve it.

Here is what I discovered:

The common thread is the app pool.  Validate that the app pool that is being reported in the error is the same app pool that is hosting the Visio Graphics Services service. 

screenshot.136

Next using the visit using the PowerShell script provided in my previous blog article, How to: Get your Managed Account passwords when they are changed automatically by SharePoint 2010, get the password for the account running your Visio Graphic Services and head over to your Manage Service Applications and manage the Secure Store Service.  Find your Visio SSS entry and reset the credentials.

screenshot.139

screenshot.140

Once you have set the credentials you need to recycle the Application Pool on the application server.  In a standard OOB install look in SharePoint Web Services for the site that contains VisioGraphicsService.svc and view the basic settings to determine which app pool is being used by the site and recycle it.

After this is complete you should see all of your Visio Graphics Services rendering correctly.

Why the inconsistent behavior mentioned at the beginning of this article?  If you create a site after the SSS credential is invalid and you have a site that is still holding a valid SSS token then you will see one site (the new) be broken and one site (the old) working perfectly.  Just one of the fun anomalies we get to experience in the field.  

Once again, another issue finds it’s root cause in credentials management.  While SharePoint 2010 has brought us leaps and bounds further than any product previously released, we still must remain vigilant in our credentials management as Admins and Architects.  IMHO, Planning for proper credentials management is almost as critical as DR planning, and often time more far more complex.

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

Scenario:

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?

Resolution:

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
[System.Reflection.BindingFlags]::NonPublic
}
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)
[System.Runtime.InteropServices.Marshal]::ZeroFreeGlobalAllocUnicode($unmanagedString)
return $unsecureString
}

Get-SPManagedAccount | select UserName, @{Name="Password"; Expression={ConvertTo-UnsecureString (GetFieldValue $_ "m_Password").SecureStringValue}}
The output will look similar to:
screenshot1
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?!?!?!?

Scenario:

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?

Resolution:

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 http://www.yourserver.com/_admin/ManagedAccounts.aspx and edit your farm service account and tell it to change the password now.

Go to http://www.yourserver.com/_admin/FarmCredentialManagement.aspx 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 http://www.yourserver.com/_admin/FarmCredentialManagement.aspx 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).