When you are installing System Center Configuration Manager (ConfigMgr) 2007 in environments where group policies are used to control the User Rights Assignment and Security Options security settings of the Servers, because if you don’t the settings coming from the ConfigMgr installation will be overwritten at the next policy refresh, which could result in interesting scenario’s. To mitigate this you have to provide the settings needed to make the Server work correctly to the Group Policy Administrators.

How to determine the Policy Settings:

In order to determine the correct settings, its best to build ConfigMgr in a test environment, where the servers are isolated from Group Policies when you are installing them. Start with detailing the configuration of the Security Settings of the machine in the state which you received it, or just after you installed the machine yourself. This can be easily done by exporting the User Rights Assigment and the Security Options settings using the Export List… options when you rights click the User Rights Assignment or Security Options node. Save the output, and make sure you detail the fact that this settings reflect your start position. (more)

The Second step should be that you configure the requirements needed on the Server in order to be able to install Configuration Manager, like IIS, WSUS etc.. (detailed here). When finished repeat the same procedure and make sure you name the output files to reflect the pre ConfigMgr installation state.

The Third step, is the ConfigMgr installation itself, install ConfigMgr and make sure the Site (or site system) is working properly. Repeat the described procedure and make sure you name the output files to reflect the post ConfigMgr installation state. There are probably more ways to achieve this goal, but this works with out of the box functionality.

The outcome of my investigation, which is the difference between the first and the last output saved, resulted in the following settings:

User Rights Assignment:

Adjust Memory Quotas for a process: Add Classic .NET AppPool,DefaultAppPool

Generate Security audits: Add Classic .NET AppPool,DefaultAppPool

Impersonate a client after authentication: Add IIS_IUSRS

Log on as a batch job: Add IIS_IUSRS

Log on as a service: Add Classic .NET AppPool,DefaultAppPool

Replace a process level token: Add Classic .NET AppPool,DefaultAppPool

Security Options:

Network access: Remotely accessible registry paths and sub-paths: Add Software\Microsoft\SMS

Keep in mind, that when you configure a so called Delta Policy for your ConfigMgr servers – which only contain the settings needed for that type of machine, you have to provide the default settings plus the above settings in the policy in order for the setting to be applied successfully.

The Caveat (without it it wouldn’t be fun…)

As always, when implementing these settings you run into some other “Challenges”, in my case it was because of the fact that the IIS Classic .NET AppPool and DefaultAppPool accounts weren’t added successfully to the registry after applying the newly configured policy. When you run a GPResult /H Report.html the report details that the settings are successfully applied, but when opening the local policy editor (Gpedit.msc) or the Resultant Set of Policy tool (RSOP.msc) when troubleshooting further you will notice that the settings are not applied.

The fact that the settings are not applied is also logged in the Application event log and searching for eventid 1202, resulting in the following error:

You can also see how Group Policies are applied by looking at the winlogon.log file created in the %windir%\security\logs\ folder during logon.

Configuring SeImpersonatePrivilege for this account is not supported.

Configure Classic .NET AppPool.

Error 1332: No mapping between account names and security IDs was done.

After this, then Google or you other favorite search engine is your friend, eventually resulting in finding the following KB article 977695: http://support.microsoft.com/kb/977695

The KB Article describes that when the Group Policy Management Editor changes settings under User Rights Assignment, it translates per-Service SIDs to service names, it does not add the NT Service or IIS AppPool prefix when doing so though, resulting in the behavior that only the supplied name in the Group Policy Management Editor (for example Classic .NET AppPool) is written to the GptTmpl.inf file while this should be IIS AppPool\Classic .NET AppPool instead.

The KB Article provides two solutions, by either requesting a hotfix to fix the Group Policy Management Editor, or by manually editing the GptTmpl.inf file. I decided to just the last option to edit the GptTmpl.inf file directly (search for the GUID of the Policy, and locate the correct .inf file)

[Privilege Rights]

SeIncreaseQuotaPrivilege = IIS AppPool\DefaultAppPool,IIS AppPool\Classic .NET AppPool,*S-1-5-32-544

SeAuditPrivilege = IIS AppPool\Classic .NET AppPool,IIS AppPool\DefaultAppPool

SeBatchLogonRight = IIS_IUSRS

SeServiceLogonRight = IIS AppPool\Classic .NET AppPool,IIS AppPool\DefaultAppPool

SeAssignPrimaryTokenPrivilege = IIS AppPool\DefaultAppPool,IIS AppPool\Classic .NET AppPool

SeImpersonatePrivilege = *S-1-5-6,IIS_IUSRS,*S-1-5-32-544

After modifying the GptTmpl.inf file and running a GPUpdate /force, i was able to check a Resultant Set of Policy, which gave the expected result.

Challenge solved