Win2000 Group Policy strange issue

Hello,

This related to Windows 2000 Advanced Server SP4.

While I was able to fully resolve my issue, I am not certain why it was an issue in the first place and would appreciate community feedback.

A misspelled ValueName existed ONLY in the GptTmpl.inf file (not any Policy). Two files by that name live: C:\WINNT\SYSVOL\domain\Policies\{POLICY GUID}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf
as well as C:\WINNT\SYSVOL\sysvol\{DOMAIN}\Policies\{POLICY GUID}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

The INF setting with the typo was:
MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\TcpMaxHalfOpenRetired=4,160

The particular setting could be seen in the registry as:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"tcpmaxhalfopenretired"=dword:000000a0

... where "tcpmaxhalfopenretired" should have been "tcpmaxhalfopenretried".

Once I changed the typo in the FIRST GptTmpl.inf file mentioned above, it no longer propagated to the Registry. I merely deleted the wrong entry in the Registy and then forced Group Policy to update on the DC using commands:
secedit /refreshpolicy machine_policy /enforce
secedit /refreshpolicy user_policy /enforce

My question is: How did that setting get into GptTmpl.inf file in the first place? I could find no reference of it any any policy; default or otherwise. I even used Group Policy Management Console GPMC 3.0 from a WinXP client to gather a Settings report, just to be certain. I would offer a guess that, at one time, a custom ADM admin template introduced that typo into the Default Domain Controller Policy ... then the ADM was later removed. Thus, the typo persisted, albeit unrelated to anything, in the GptTempl.inf file. Yet, if that was true, I would have expected to see an error in the GPMC Settings report.

As a follow-up question, what is the "flowchart" for Group Policy settings? I previously believed they originate from a Policy (default or otherwise) and then make their way to the registry or associated placeholder ... and are recorded in the .INF file(s) for later management using a Policy editor GUI.

Thanks in advance,
Paulie D
TechGuru1

If you upgrade an Active Directory GPO to support the new Windows XP policy settings, Windows 2000-based clients ignore any Windows XP-specific settings. This behavior occurs on a per-setting level. If a policy object contains a policy setting that is not supported, all other supported policy settings from that policy object are applied.

To upgrade a Windows 2000 GPO, follow these steps on a Windows XP-based domain member:

1. Click Start, click Run, type mmc, and then click OK.
2. On the File menu, click Add/Remove Snap-in.
3. In the Add/Remove Snap-in dialog box, click Add.
4. In the Add Standalone Snap-in dialog box, click Group Policy, and then click Add.
5. In the Select Group Policy Object dialog box, Local Computer appears as the target object. Click Browse, select the GPO that you want to upgrade, and then click OK.
Note When you click Browse, a delay might occur while Windows searches for the policy objects in the domain.
6. Click Close.
7. Click OK.

You can now adjust the policy settings in this Policy object by using the Group Policy console from the Windows XP-based client.

Important:- After you apply Windows 2000 Service Pack 4 (SP4), the Group Policy security templates are restored to the Windows 2000 default security settings. Because of this change, you must repeat these seven steps after you apply Windows 2000 SP4.

The .adm files are automatically updated if all the following conditions are true:

• The .adm file on the local computer has a newer timestamp than the one that is located in the \Adm folder on the domain controller.
• The .adm files have different file sizes.
• The “Turn off Automatic Update of ADM files is disabled" Group Policy is not enabled for the user.

These are some high-level steps for troubleshooting Group Policy issue -

• Check the required infrastructure. Make sure required services and components are running and configured as expected.
  
  
• Check the core configuration. Verify that the computer is connected to the network, joined to the domain, and has the correct system time.
  
  
• Check Group Policy exceptions. Verify that exceptions (scope of management) such as security filtering, WMI filters, block inheritance, enforcement , loopback processing and slow link settings are not affecting normal GPO processing.
  
  
• Use tools like GPResult.exe, GPOTool.exe and the GPMC to ensure that Group Policy settings that are expected to be delivered are actually delivered and that Group Policy objects on domain controllers are consistent and available.
  
  
• Use event logs, userenv logs, and CSE logs to analyze the problem and find a solution.

I have seen this misspelling in the secregvl.inf file that is used to provide the security options found in group policy. Microsoft (and later DISA) distributed them under one of the MSS settings.

To find the error, open %systemroot%\inf and load the secregvl.inf file in your favorite text editor. Chances are you will find the setting there. To remove it from your group policy editor, you will need to find the setting in HKLM\Software\Microsoft\Windows NT\CurrentVersion\SeCEdit\Reg Values. Delete the key that corresponds to it (when you correct the spelling in secregvl.inf the setting will show up twice in the GPO editor).

Hope it helps..

v/r
KLF
CISSP, MCSE, MCSA, N+, A+

Here's another similar situation:

I have a Win 2000 laptop that is a member of the domain but refused to have its Local Security updated, as defined by the Win 2000 DC's Group Policies. As it turns out, files on the laptop at C:\WINNT\security\templates\policies\*.inf & *.dom were set to READ ONLY. I assume that this action was taken, as a desperate attempt to prevent future policy changes from impacting the laptop in our DOD environment, since computers are typically imaged for deployment.

After renaming the .DOM and .INF files, I forced a GPUPDATE ( in Win 2000, using this command: secedit /refreshpolicy user_policy /enforce then secedit /refreshpolicy machine_policy /enforce ). Once that completed, the aforementioned files were automatically replaced with the proper, up-to-date settings from the Domain Controller.

What lead me to the resolve was looking at the C:\WINNT\security\logs\winlogon.log file and seeing the correct GPO names (eg: gpt00001.inf, gpt00002.doc, etc) and then finding the aforementioned files in the POLICIES folder as read-only ... and, of course, with a very old timestamp which confirmed they weren't being updated.

You would think that Microsoft would create a clearly-worded event log for this situation, stating that the local policy templates could not be deleted / replaced due to the READ-ONLY attribute ... but that would make things too easy. Instead, the only related entry I found was in the Security Log > Category: Object Access > Event ID: 560 > Type: Failure which stated that C:\SYSTEM VOLUME INFORMATION was failing to synchronize.

Anyway ... I hope this information comes in handy to you.