Project Server: A good reason not to run services with accounts with which you log on to your servers


Thanks to my colleague Jon Cantrell for this posting.

There’s a new trend in Project Server issues we’re seeing as more users start deploying on Windows Server 2008. There is a change in how Windows handles user profiles that was introduced with Windows Vista and first made it into the server branch of code with Windows Server 2008. The change is that when a user account logs off, their profile is forcibly unloaded. In the past, services or applications that had registry handles or other items still open were allowed to continue using these resources. These issues can be a little more difficult to pin down as an IISReset will temporarily resolve the issue and this can make the error appear to be more intermittent.

Where we see this impact the Project world is when someone logs on to a Windows session on one of the Project Servers in the farm using the same account that one of the IIS Application Pools is running under. By default, when the user then logs off, the application pool has its access to the registry and other resources revoked. This can lead to many downstream issues that include the Project Server Queue no longer processing jobs as well as an error similar to the following: “Retrieving the COM class factory for component with CLSID {BDEADEE2-C265-11D0-BCED-00A0C90AB50F} failed due to the following error: 800703fa”. These are just some of the symptoms that we’ve tracked down to this behavior, there probably many others due to the nature of this issue.

There are two options you can use for a resolution. First, we recommend that non-user accounts be used to run the application pools. As such, their accounts should not be experiencing logoff events. If it is unavoidable that these accounts will log on and logoff then there is a new option for application pools in IIS7. That option is on the Advanced Settings page for Application Pools and is “Load User Profile”. If you set that to “True”, then the applications will maintain their registry and file access through Windows logon and logoff events.

How can you tell if this is might be the root cause of a problem you’re experiencing? It’s actually rather simple. When the profile is forcibly logged off in such a fashion there is an event logged in the Windows Application Event Log.

Log Name: Application
Source: Microsoft-Windows-User Profiles Service
Date: Date
Event ID: 1530
Task Category: None
Level: Warning
Keywords: Classic
User: SYSTEM
Computer: ComputerName
Description:
Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards.


Comments (1)

  1. michael wharton says:

    Thanks Brian.  That's explains a lot of unexplained behavior.  

    Do have any recommended settings for app pool logon accounts and policy that should be set as well?  For example, should policy be set to non-interactive and logon-as-a-service?

Skip to main content