\[Editor's Note: Share your security discoveries, comments, problems, solutions, and experiences with products. Email your contributions (500 words or less) to [email protected] We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
A few months ago, I needed to restrict logons for one of my organization's Windows 2000 Professional users. When I tried to access Domain Security Policy and select Security Settings, I received the error message Windows cannot open the Template. In addition, the errors event ID 1000 (Userenv), which Web Figure 1 (http://www.secadministrator.com, InstantDoc ID 26441) shows, and event ID 1001 (SceCli), which Web Figure 2 shows, were logging in Windows NT Event Viewer every 5 minutes because of a missing or corrupt gpttmpl.inf file on both domain controllers (DCs).
The Microsoft article "Group Policy Error Message When Appropriate Sysvol Contents Are Missing" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q253268) discusses missing \sysvol content and suggests rebuilding or restoring the sysvol structure from backup. My backups aren't easy to restore from, so I rebuilt the content. I compared my two servers' structure item by item and found the same content.
The Microsoft article "Error Message: Security Policies Are Propagated with Warning. 0x534" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q247482) explains that when you have a permission left over from a deleted account (e.g., a deleted user), with a policy still set for the user object, Security Policy is propagated with 0x534 warnings. The article recommends editing the registry to enable the winlogon.log entry and thus improve your debugging logging. I followed the article's advice, but I still had the problem.
The Microsoft article "Event ID 1000, 1001 Is Logged Every 5 Minutes in the Application Event Log" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q290647) suggests that event ID 1000 and event ID 1001 might occur because you've improperly assigned Bypass Traverse Checking and therefore don't have permission to access \sysvol content. This article discusses the \sysvol folder and file structures' default permissions; however, the article is unclear about whether you should select the Allow inheritable permissions from parent to propagate to this object check box.
As an additional check, I used the Group Policy Results utility (gpresult.exe) and the Group Policy Verification Tool utility (gpotool .exe). The Group Policy Results output looked normal. But the Group Policy Verification Tool output, which Web Figure 3 shows, showed a version mismatch on my servers. However, the Details field was blank, and the Group Policy Verification Tool output offered no explanation or suggestion for how to proceed.
The Microsoft article "HOW TO: Reset User Rights in the Default Domain Group Policy"(http://support.microsoft.com/default.aspx?scid=kb;en-us;q226243) explains that you need to reset user rights under Domain Policy. I knew that my problem wasn't a matter of not having permission to view the Domain Policy, because I had already checked the permissions on each folder. Section 2b in the article explains how to increase the Domain Policy's version number so that the Domain Policy's version will replicate as the newest version. I knew I had a version mismatch. The article says to make a backup copy of gpttmpl.inf (i.e., the Group Policy Template file). But first, I decided to compare my gpttmpl.inf file's contents with the default settings that the article gives as an example. I opened gpttmpl.inf in WordPad, and the file was empty. So, I copied the default contents into my gpttmpl.inf file, then saved and closed the file. Next, I increased the version of the gpttmpl.inf file in gpt.ini so that the version number was the highest on the network. Finally, I ran the following command:
secedit /refreshpolicy machine_policy
These actions fixed the problem.