Automation of Password Updates…

Recently I stumbled upon a SharePoint 2010 environment setup a long time ago where the managed accounts and accounts in general were setup a little funny… in particular the issue was that the profile service stopped syncing. I asked the administrator what the issue was and they stated that they’d setup the system to use a managed account for the farm service account and other service application service accounts to automatically change the password in the background. That’s all fine and dandy for the most part, ‘cept that there are caveats with the Farm Account. And low and behold, I checked and sure enough the system’s Farm account was setup now as a Managed Account in our trusty, friendly SharePoint 2010 instance.

Issue – the profile synchronization service runs as this service account. Caveat, profile sync requires that you enter the account information and credentials since you may not necessarily be sync’ing with the Active Directory resource forest that your SharePoint system leverages as its Windows Networking Infrastructure platform.

So how did we attempt to remedy this… not knowing the Farm password, it was updated in Active Directory and then using Set-SPManagedAccount with the -UseExistingPassword argument, the password was properly updated. It was then synchronized across the farm with Repair-SPManagedAccountDeployment.

So SharePoint should now be up and operational with the managed account password updated, but we also have to go and update the synchronization connection with the new password. All should be working and fine, crisis averted, just have to go in Central Admin and make the update there… But, what I thought would be a five minute fix… well, yeah, not so much.

Hello 503 error.

Oddly, after all of the troubleshooting it ended up being the bitness setting for the Application Pool that operates SharePoint was modified to operate in x86 emulation mode. This comes in handy when you need to run two different compilations of a DLL through IIS, but with our native 64 bit SharePoint application, this doesn’t work so well. Why does this happen though? Not certain but it would seem that several folks seem to have this problem when they’ve been running their SharePoint system with managed accounts automatically updating and then reverting back to an “unmanaged mode” so to speak where the metabase becomes corrupt and suddenly the fitness for x86 emulation is set to true.

More on running in both x86 and x64 mode is available here:

Please only modify this if you’re running into this problem – definitely make a backup copy before making any changes!!!

So if I want to avert this, I can force the Application Pool to start in 64bit mode by adding a “bitness64” flag… this is done in the ApplicationHost.config located in


Within the Global Modules section of the ApplicationHost.config, you should search for the SharePoint14Module which should look something like this:

<add name=”SharePoint14Module” image=”C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14isapiowssvr.dll” preCondition=”appPoolName=SharePoint Central Administration v4″ />

If you want to force your App Pool to always start without x86 emulation… then you’ll want to add the following argument of “bitness64” so that you end up with something like this:

<add name=”SharePoint14Module” image=”C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14isapiowssvr.dll” preCondition=”appPoolName=SharePoint Central Administration v4,bitness64″ />

Note you’ll have to do this for each of the Web Applications that are registered – if you choose to make this modification.

And just like that… I start the application pool and all is well. Went and updated the synchronization connection and our UPS started syncing again. Qed.

More on ApplicationHost.config available here:

SharePoint Users Group of New York

This past week, Scott Hoag and I had the privilege of presenting a session to the New York SharePoint User’s Group, hosted by Microsoft at their offices there in New York City on the Avenue of the Americas. There were a few familiar faces in the crowd such as Paul Galvin, Mary Leigh Mackie, Randi Parrish, Greg Hurlman and Jeremy Thake which made the large crowd a little less intimidating (or maybe more so to have peers evaluating us right?).

Before we presented though we had a few things to explore… such as the Apple Cube on 5th Avenue
I have to say that it was a pretty cool sight to see – the fact that the store is underground is in and of itself an interesting concept.

After a quick stop through we began wandering toward the Microsoft offices on foot… in the wrong direction… which got us caught up in remembering what it’s like to be a kid at FAO Schwarz… having never been inside the store I didn’t really know what to expect except for what I’d seen in the Smurfs movie that I saw last Fall… needless to say it was pretty crazy to see all of the candy and Gummi bears (oh and the nerds) as well as every popular toy that you could imagine from Star Wars apparel and masks to Thundercats action figures to even BatMan in Lego form.

All well worth the time spent in New York City, but for those that happen to be looking for a copy of our presentation, you can find it here through SlideShare.

If you need a copy to go offline with, you can grab a copy here – Avoiding Administrator Blunders in PPTX format.

Recycle an Application Pool – #ITProTip

So you’ve deployed an updated solution to your SharePoint 2007 or 2010 farm and you need to recycle the application pool associated with the web application that the solution is deployed to but you don’t want to take down the entire SharePoint farm? No problem, just recycle the single application pool that’s associated with that web application using a quick little command from command shell.

For those running SharePoint 2007 on Windows Server 2003 / 2003 R2:

cscript c:windowssystem32iisapp.vbs /a "%SharePointApplicationPool%" /r

where %SharePointApplicationPool% is the application pool that needs to be recycled. Note that iisapp.vbs resides within %systemroot%system32

For those running SharePoint 2007 or SharePoint 2010 on Windows Server 2008 / 2008 R2:

appcmd recycle apppool /

.csharpcode, .csharpcode pre
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
background-color: #f4f4f4;
width: 100%;
margin: 0em;
.csharpcode .lnum { color: #606060; }

where %SharePointApplicationPool% is the application pool that needs to be recycled.  Note that appcmd resides within %systemroot%system32inetsrv

The alternative for this of course is just to go in IIS Manager 6 or 7, select the application pool associated with the web application that requires recycling and recycle the pool manually through the UI.


No, don’t pull that cord out of the wall…

Are you ever working on a server and you wander away for a few minutes only to come back and find that you’ve been disconnected and your session terminated? Never something fun to work through, especially if you’re installing and configuring a software product.

In most enterprise settings this is something that you’d find in a global policy object enforcing a particular amount of time that you’re able to be Idle prior to being booted from the server. Also there’s another setting regarding the maximum connection timeout – basically how long until your session gets trashed because you decided after you’d been booted for being idle you weren’t going to log back in.

If you’re searching around for these settings, they can be found through your friendly neighborhood group policy object at:

Console RootLocal Computer PolicyComputer ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop SessionSession Time Limits

Specifically you’re looking to see what the settings for the following policies are:

  • Set time limit for disconnected sessions
  • Set time limit for active but idle Remote Desktop Services sessions
  • Set time limit for active Remote Desktop Services sessions
  • Terminate session when time limits are reached

While they may all seem friendly, upon closer examination you’re likely to find that one of these policies is your culprit (more than like the second and third in conjunction with the fourth).

However, oddly enough some folks still use security templates to tighten the policies on their servers.  In which case, there’s also a Registry edit required and a reboot.  Note you should always backup your registry before you make any changes – not for the squeamish of heart.

You’ll find this information along with other helpful information for allowing and disallowing things like the use of the Clipboard (fDisableClip) in the registry branch of:

ComputerHKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindows NTTerminal Services

Note that it’s still called Windows NT and also Terminal Services – I guess that some things never change 🙂

Specifically you’re looking for the following registry strings to modify:

  • MaxDisconnectionTime
  • MaxIdleTime

The decimal values that correspond to these are counted in milliseconds.  For instance, if the MaxDisconnectionTime is set to 300000, this corresponds to 5 minutes (60 seconds/minute x 1000 milliseconds/second x 5 minutes).  If you don’t want to be disconnected or have a max idle time, just set the value to 0 and you’ll be all set.

Happy Implementing!

And if you’re wondering where the title for this blog post came from, check out the Fireside Theater’s “We’re All Bozos On This Bus” radio show. Has something similar where the robot gets unplugged 🙂

SharePoint 2010 – Drive Space Conundrum

One of the new capabilities of SharePoint 2010 that comes in handy is the Health Monitoring alerts that pop up on the front page of Central Admin. One thing you might run into is when you start to run out of disk space.  You’ll probably see something similar to this:

Always something that you want to see while you’re working on your environment right? Not so much.

For some reason it always seems that just when things are going well, profiles are synchronizing, users are starting to engage the SharePoint platform, and boom, whammo, the file system fills up with log files, trace logs and event logs. So just a gentle reminder to examine where your log files are and consider moving them to an alternate drive than the core OS drive.

How do I do this you ask?  Pretty simply…

First off, decide what your disk plan is for your SharePoint Servers – hopefully you’ve got more than just a single drive in your system, if not slap on an extra drive (either physical or virtual) for log files, or if you’ve got a SAN handy, request an extra drive on separate spindles from where your data is stored and have them zone it for your SharePoint server to be added for offloading.

Next, for your IIS logs, simply open up IIS and go to the server name (in my case SP2010WFE-01) and then in the main information pane of IIS, scroll down to Logging underneath IIS.

Locate the Directory location and modify it to the location that you’ve setup for log files, in my case I’ve added an additional drive to my SharePoint server with the logical volume “E:”

Once IIS creates the structure, you’ll want to copy over old log files from your core OS drive (C:inetpublogs) to your new location.

Next up, Trace Logs for the Unified Logging System…

Within SharePoint Central Admin, navigate to Monitoring, within Reporting select “Configure Diagnostic Logging”.

Direct Link – http://<NetBiosNameOfSharePointServer&gt;:<CentralAdminPort>/_admin/metrics.aspx

Scroll down to the Trace Log section where you’ll see something like this:

Simply input the drive that you’d prefer to use, in my case replacing %CommonProgramFiles% with “E:Program Filescommon files”, and you end up with something like this:

Go ahead and copy over the contents of the Logs file on the original instance to the new instance to consolidate your log files.

Lastly, moving your event logs to the log drive is definitely a consideration to make – especially the Security Log file as this will grow quickly once you’ve implemented Kerberos and opened your system to your user base (NTLM spawns quite a few security events too). Out of the box you’ll see your event logs like this:

Application Event Logs

Security Event Logs

System Event Logs

Simply modify the “File” location to the new location where you are looking to store your files, in my case I use “E:Windows EventsLogs” as the directory followed by the appropriate event log file name. This is documented in:

Further, to ensure that log files don’t explode, leverage the “AutoBackupLogFiles” property within the Application Events (you’ll have to add this to the Security and System Event Logs, simple DWORD property). Setting the value to “1” or any value other than “0” will create backup files in the file location specified.

This is documented in (though it’s specific to 2000/2003 server, it works for 2008).

These three simple changes should assist in keeping your core OS drive lighter weight and prevent your system from a hiccup caused by a disk filling up.

SharePoint Server 2007 – December 2009 CU

Microsoft has released the SharePoint 2007 December 2009 Cumulative Update as of 29 January 2010. The cumulative update like all other updates includes all hotfixes since the most recent Service Pack, in this case SP2.

Information pertaining to this cumulative update is available at from the Update Resource Center at:

The WSS v3 December 2009 CU infopage is available at:

The MOSS 2007 December 2009 CU infopage is available at:

When requesting the appropriate CUs, if you’re downloading from an x86 client machine and your environment is x64 or vice versa, please note the “Show hotfixes for all platforms and languages” text next to “Number 1”.

Some insight from Joerg Sinemus regarding the December 2009 CU:

Last but not least… please remember to test all service packs, cumulative updates and hotfixes in a staging or development environment prior to implementing in your system’s production environment.