Today a colleague of mine was installing SCCM. One of the steps involved adding a service account (domain user) to the “Log on as a service” User Right on a given server. This can be done through GPO or locally using secpol.msc. After clicking apply the following error popped up: An extended error has occurred. Failed to save Local Policy Database.
In this case I cheated by taking an other User Right (Create a token object) as I didn’t wanted to screw my security configuration. Because after clicking ok and reloading the security policy, both the IIS APPPOOL\DefaultAppPool and IIS APPPOOL\Classic .NET AppPool are gone! And you can’t re-add them as the error pops up. To get them back you can first uninstall IIS and then install IIS. Or perhaps the first workaround I describe next can be applied…
I could easily reproduce this on an other server. Someone also logged this at MS connect: https://connect.microsoft.com/WindowsServerFeedback/feedback/details/557506/local-security-policy-editor-error-when-changing-log-on-as-a-service-privilege?wa=wsignin1.0
After installing Exchange 2010, it added the IIS APPPOOL\DefaultAppPool and IIS APPPOOL\Classic .NET AppPool identities to the "Log on as a service" privilege. When you try to add another principal to the "Log on as service" privilege an error occurs when saving. When you close the local security policy editor, reopen it and look at the "log on as service" privilege, the "DefaultAppPool" and "Classic .NET AppPool" identities did not save.
You can re-add the IIS APPPOOL\DefaultAppPool and IIS APPPOOL\Classic .NET AppPool identities to the "Log on as service" privilege, but when you try to save the changes an error occurs and they are not saved.
The workaround my colleagues found was to add the service account to the User Right by cheating a little bit. Being a member of the local administrators they configured a given service to “log on” as that specific account which in turns add the account the “log on as a service” User Right upon clicking apply. All this from within the services.msc console. And that seemed to do the trick.
An other possible workaround is to add your service account before you install the IIS components, as it’s the IIS role installation which adds these accounts in the first place.