It’s ending summer here in the US and the heat is raging in the Pacific Northwest and with that comes the great event – service account password change.  Alright, I might exaggerate a bit as they are completely not related events but it seems that about the time mid-90’s hit in Seattle was the time to change our TFS service account password.  Alert!  If you are being a little “conservative” in your service account usage and utilizing your TFS service account to run your SharePoint services then you will see all kinds of things break.  There is a reason that the correct guidance is to not run SharePoint services under the same account as TFS.  As typical, we ignored this and skipped to the part of running TFS & SharePoint all under a single account.

Broke #1:  SharePoint Services – Application Pools Failed

The first thing we took as a shortcut was to not create service accounts for the various application pools created within IIS.  We consolidated and decided to just use the TFS service account knowing that we are using MOSS “only” for TFS – this wouldn’t probably happen to teams/workgroups/organizations who have dedicated SharePoint administrators.  Of course, It happens to us as we cut corners.

The application pools that we currently run under a service account in IIS 7.0 are the following:

image To change these, the easy method if not scripting is the following:

  1. Open IIS Manager (local or remote) & connect to MOSS
  2. Click Application Pools
  3. Highlight each application pool listed above, right-click, select Advanced Settingsimage
  4. Under Process Model, click … next to Identity
  5. Click Set under Custom
  6. Enter Username & new Password
  7. Click Ok
  8. Repeat this for all the application pools listed above

After you’ve completed this, you will want to restart each of the application pools.  To do this, you right-click the application pool and click Start or Recycle.

Broke #2:  Excel Web Services (EWS) starts showing Errors

The first thing we noticed was our Excel reports error “Access was denied by external data…” was back.  Sigh.  But, if you remember during that post I mentioned that you have a Secure Storage Service (SSS) configuration in SharePoint that is created by the TFS install.  Unlike before, when you didn’t have the appropriate mappings for user accounts, this error is caused by the fact that as part of the SSS a set of credentials are stored and utilized by the SSS when connecting to the workbook.  Guess what?  We used our TFS service account.  Arghh…

To fix this, you have to do the following:

  1. Hit the SharePoint Central Administration site (http://{servername}:{port)
  2. Click Application Management
  3. Click Manage Service Applications under Service Applications
  4. Click Secure Store Service
  5. In the check box, check and then click Set from the Ribbon
  6. In the Windows User Name, enter the user account that is your TFS service account
  7. Under Password, and confirm, enter the password
  8. Click Ok

The EWS reports shown on your dashboard should now show up-to-date data and working. (Refresh all Connections)

Summary

Much like the heat exploding in the Pacific Northwest, I didn’t much anticipate that changing a single service account password would cause such an explosion of failures.  I guess if you cut corners (with TFS & MOSS) like we do and try and manage as few service accounts as possible, well, you pay for it in the end. 

At least next month, when the time comes to change passwords we will know about these additional services and add that to our change script :)

If you take the same approach we do and consolidate then you will run into this problem when you run into password change intervals.  If you don’t have password change intervals, well then that is a post for another day… <grin>

Enjoy!

Thanks,

-Chris