9 comments

Failed To Save Local Policy Database

Published on Tuesday, September 14, 2010 in

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.

image_thumb[27]

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

The description:

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.

image

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.

Related Posts

9 Response to Failed To Save Local Policy Database

Anonymous
27 October, 2010 23:43

Thanks for posting this info, I'm having the same problem.
Could you please describe the workaround and how I can do it? I didn't understand exactly how it was solved.

29 October, 2010 12:57

For what security privilege are you seeing this behavior? For the "logon as a service"?

If that's the case you can:
1.Open services.msc pick a service which is configured to use "Local System" and which is not started
2. Configure that service to use your service account and click apply. At this time the service account should be added to the privilege
3. Change the service to use "local system" again.

Alternatively: reinstall IIS

Anonymous
31 October, 2010 02:13

Thanks for the info, I ended up using ntrights.exe to add the account I needed for logon as a service.
DefaultAppPool disappeared, but everything works ok now.

Anonymous
21 December, 2010 00:37

I've talked to Microsoft about this and they acknowledge it's a bug. You have to be careful because in my case I was removing an item from "log on as a service" and my database lost more than just the item I was trying to remove. It took some effort to determine what was removed.

21 December, 2010 19:27

Thanks for the feedback! Please report back if you every come across a hotfix for this.

Anonymous
22 October, 2011 11:22

For those who've encountered this problem there is a supported hotfix available from Microsoft:

KB2411938:
"An external error has occurred" error when you change the user rights of an account in Local Security Policy in Windows Server 2008 R2

24 October, 2011 19:30

Great! Thanks for posting the KB. Might come in handy whenever we come accross this again. For your convenience a link: KB2411938

16 September, 2012 08:42

Create a local Group, drop all the AppPools in there, and then add the group to policies.

Easier to manage too! When you create more appPools, just add them to your new group and then they get the perms needed.

Anonymous
24 June, 2014 22:45

Of course if you aren't running 2008 then the MS "fix" is totally useless.

Add Your Comment