Applying Group Policy causes Userenv errors and events to occur on your computers that are running Windows Server 2003, Windows XP, or Windows 2000 (887303)

RESOLUTION

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

To resolve this issue, you must troubleshoot the configuration of your network to narrow the cause of the issue, and then correct the configuration. To troubleshoot the possible cause of this issue, follow these steps:

Step one: Examine the DNS settings and network properties on the servers and client computers

In the local area connection properties, Client for Microsoft Networks must be enabled on all servers and client computers. The File and Printer Sharing for Microsoft Networks component must be enabled on all domain controllers.

Additionally, every computer on the network must use DNS servers that can resolve SRV records and host names for the Active Directory forest where the computer is a member. Typically, a common configuration error is for the client computers to use the DNS servers that belong to your Internet service provider (ISP).

On all the computers that have logged the Userenv errors, examine the DNS settings and network properties. Additionally, check these settings on all domain controllers, whether or not they log Userenv errors.

To verify DNS settings and network properties on Windows XP-based computers in your network, follow these steps:

1. Click Start, and then click Control Panel.
2. If Control Panel is set to Category View, click Switch to Classic View.
3. Double-click Network Connections, right-click Local Area Connection, and then click Properties.
4. On the General tab, click to select the Client for Microsoft Networks check box.
5. Click Internet Protocol (TCP/IP), and then click Properties.
6. If Use the following DNS server addresses is selected, make sure that the IP addresses for the preferred and alternate DNS servers are the IP addresses of DNS servers that can resolve SRV records and host names in Active Directory. Specifically, the computer must not use the DNS servers that belong to your ISP. If the DNS server addresses are not correct, type the IP addresses of the correct DNS servers in the Preferred DNS server and Alternate DNS server boxes.
7. Click Advanced, and then click the DNS tab.
8. Click to select the Register this connection's addresses in DNS check box, and then click OK three times.
9. Start a command prompt. To do this, click Start, click Run, type cmd, and then click OK.
10. Type ipconfig /flushdns, and then press ENTER. Type ipconfig /registerdns, and then press ENTER.
11. Restart the computer for your changes to take effect.

To verify DNS settings and network properties on Windows 2000-based computers in your network, follow these steps:

1. Click Start, point to Settings, and then click Control Panel.
2. Double-click Network and Dial-up Connections.
3. Right-click Local area connection, and then click Properties.
4. On the General tab, click to select the Client for Microsoft Networks check box.
5. If the computer is a domain controller, click to select the File and Printer Sharing for Microsoft Networks check box.
   
   Note On multi-homed Remote Access servers and Microsoft Internet Security and Acceleration (ISA) Server-based servers, you can disable the File and Printer Sharing for Microsoft Networks component for the network adaptor that is connected to the Internet. However, the Client for Microsoft Networks component must be enabled for all the server's network adaptors.
6. Click Internet Protocol (TCP/IP), and then click Properties.
7. If Use the following DNS server addresses is selected, make sure that the IP addresses for the preferred and alternate DNS servers are the IP addresses of DNS servers that can resolve SRV records and host names in Active Directory. Specifically, the computer must not use the DNS servers that belong to your ISP. If the DNS server addresses are not correct, type the IP addresses of the correct DNS servers in the Preferred DNS server and Alternate DNS server boxes.
8. Click Advanced, and then click the DNS tab.
9. Click to select the Register this connection's addresses in DNS check box, and then click OK three times.
10. Start a command prompt. To do this, click Start, click Run, type cmd in the Open box, and then click OK.
11. Type ipconfig /flushdns, and then press ENTER. Type ipconfig /registerdns, and then press ENTER.
12. Restart the computer.

To verify DNS settings and network properties on Windows Server 2003-based computers in your network, follow these steps:

1. Click Start, point to Control Panel, and then double-click Network Connections.
2. Right-click the local area connection, and then click Properties.
3. On the General tab, click to select the Client for Microsoft Networks check box.
4. If the computer is a domain controller, click to select the File and Printer Sharing for Microsoft Networks check box.
   
   Note On multi-homed Remote Access servers and ISA Server-based servers, , you can disable the File and Printer Sharing for Microsoft Networks component for the network adaptor that is connected to the Internet. However, the Client for Microsoft Networks component must be enabled for all the server's network adaptors.
5. Click Internet Protocol (TCP/IP), and then click Properties.
6. If Use the following DNS server addresses is selected, make sure that the IP addresses for the preferred and alternate DNS servers are the IP addresses of DNS servers that can resolve SRV records and host names in Active Directory. Specifically, the computer must not use the DNS servers that belong to your ISP. If the DNS server addresses are not correct, type the IP addresses of the correct DNS servers in the Preferred DNS server and Alternate DNS server boxes.
7. Click Advanced, and then click the DNS tab.
8. Click to select the Register this connection's addresses in DNS check box, and then click OK three times.
9. Start a command prompt. To do this, click Start, click Run, type cmd, and then click OK.
10. Type ipconfig /flushdns, and then press ENTER. Type ipconfig /registerdns, and then press ENTER.
11. Restart the computer for your changes to take effect.

If the client computers in your network are configured to obtain their IP addresses automatically, make sure that the computer that is running the DHCP service assigns the IP addresses of DNS servers that can resolve SRV records and host names in the Active Directory.

To determine what IP addresses a computer is using for DNS, follow these steps:

1. Start a command prompt. To do this, click Start, click Run, type cmd in the Open box, and then click OK.
2. Type ipconfig /all, and then press ENTER.
3. Note the DNS entries that are listed on the screen.

If computers that are configured to obtain IP addresses automatically are not using the correct DNS servers, view the documentation for your DHCP server for information about how to configure the DNS servers option. Additionally, make sure that each computer can resolve the IP address of the domain. To do this, type ping Your_Domain_Name.Your_Domain_Root at a command prompt, and then press ENTER. Alternatively, type nslookup Your_Domain_Name.Your_Domain_Root, and then press ENTER.

Note It is expected that this host name will resolve to the IP address of one of the domain controllers on the network. If the computer cannot resolve this name, or if the name resolves to the wrong IP address, make sure that the forward lookup zone for the domain contains valid (same as parent folder) Host (A) records.

To make sure that the forward lookup zone for the domain contains valid (same as parent folder) Host (A) records on a Windows 2000-based computer, follow these steps:

1. On a domain controller that is running DNS, click Start, point to Programs, point to Administrative Tools, and then click DNS.
2. Expand Your_Server_Name, expand Forward Lookup Zones, and then click the forward lookup zone for your domain.
3. Look for (same as parent folder) Host (A) records.
4. If a (same as parent folder) Host (A) record does not exist, follow these steps to create one:
   1. On the Action menu, click New Host.
   2. In the IP address box, type the IP address of the domain controller's local network adaptor.
   3. Click to select the Create associated pointer (PTR) record check box, and then click Add Host.
   4. When you receive the following message, click Yes:(same as parent folder) is not a valid host name. Are you sure you want to add this record?
5. Double-click the (same as parent folder) Host (A) record.
6. Verify that the correct IP address is listed in the IP address box.
7. If the IP address in the IP address box is not valid, type the correct IP address in the IP address box, and then click OK.
8. Alternatively, you can delete the (same as parent folder) Host (A) record that contains an IP address that is not valid. To delete the (same as parent folder) Host (A) record, right-click it, and then click Delete.
9. If the DNS server is a domain controller that is also a Routing and Remote Access server, view the following Microsoft Knowledge Base article:

   292822 Name resolution and connectivity issues on a Routing and Remote Access Server that also runs DNS or WINS

10. On all computers where you add, delete, or modify DNS records, type ipconfig /flushdns at a command prompt, and then press ENTER.

To make sure that the forward lookup zone for the domain contains valid (same as parent folder) Host (A) records on a Windows Server 2003-based computer, follow these steps:

1. On a domain controller that is running DNS, click Start, point to Administrative Tools, and then click DNS.
2. Expand Your_Server_Name, expand Forward Lookup Zones, and then click the forward lookup zone for your domain.
3. Look for the (same as parent folder) Host (A) record.
4. If the (same as parent folder) Host (A) record does not exist, follow these steps to create one:
   1. On the Action menu, click New Host (A).
   2. In the IP address box, type the IP address of the domain controller's local network adaptor.
   3. Click to select the Create associated pointer (PTR) record check box, and then click Add Host.
   4. When you receive the following message, click Yes:(same as parent folder) is not a valid host name. Are you sure you want to add this record?
5. Double-click the (same as parent folder) Host (A) record.
6. Verify that the correct IP address is listed in the IP address box.
7. If the IP address is in the IP address box is not valid, type the correct IP address in the IP address box, and then click OK.
8. Alternatively, you can delete the (same as parent folder) Host (A) record that contains the IP address that is not valid. To delete the Host (A) record, right-click (same as parent folder), and then click Delete.
9. If the DNS server is a domain controller that is also a Routing and Remote Access server, view the following Microsoft Knowledge Base article:

   292822 Name resolution and connectivity issues on a Routing and Remote Access Server that also runs DNS or WINS

10. On all computers where you add, delete, or modify DNS records, type ipconfig /flushdns at a command prompt, and then press ENTER.

Step two: Examine the Server Message Block signing settings on the client computers and member servers

The Server Message Block (SMB) signing settings define whether the computers on the network digitally sign communications. If the SMB signing settings are not configured correctly, the client computers, or the member servers, may not be able to connect to the domain controllers.

For example, SMB signing may be required by the domain controllers, but SMB signing may be disabled on the client computers. If this issue occurs, Group Policy cannot be applied correctly. Therefore, the client computers log user environment (Userenv) errors in the Application log.
Sometimes, the SMB signing settings for the Server service and the Workstation service on a domain controller may conflict with each other.

For example, SMB signing may be disabled for the domain controller's Workstation service, but SMB signing is required for the domain controller's Server service. In this scenario, you cannot open one or more of the domain controller's local file shares if you are logged on to the server. Additionally, you cannot open Group Policy snap-ins if you are logged on to the server. For more information about how to troubleshoot this problem on a domain controller, click the following article number to view the article in the Microsoft Knowledge Base: If Group Policy errors only occur on client computers and member servers, or if you determine that KB article 839499 does not apply to your situation, continue to troubleshoot the issue.

By default, SMB signing is enabled but is not required for client communication on client computers and member servers that are running Windows XP, Windows 2000, or Windows Server 2003. We recommend that you use the default configuration because the client computers can use SMB signing when it is possible, but will still communicate with servers that have SMB signing disabled.

To configure the client computers and member servers so that SMB signing is enabled but not required, you must change the values for some registry entries. To make the registry changes on the client computers, follow these steps:

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. Expand the following registry subkey:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

3. In the right pane, right-click enablesecuritysignature, and then click Modify.
4. In the Value data box, type 0, and then click OK.
5. Right-click requiresecuritysignature, and then click Modify.
6. In the Value data box, type 0, and then click OK.
7. Expand the following registry subkey:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters

8. In the right pane, right-click enablesecuritysignature, and then click Modify.
9. In the Value data box, type 1, and then click OK.
10. Right-click requiresecuritysignature, and then click Modify.
11. In the Value data box, type 0, and then click OK.

After you change the registry values, restart the Server and Workstation services. Do not restart the computers because this may cause group policies to be applied, and the Group Policy settings may configure conflicting values again.

After you change the registry values and restart the Server and Workstation services on the affected computers, follow these steps:

1. View the Group Policy settings for the GPO or GPOs that apply to the affected computer accounts.
2. Make sure that the group policies do not conflict with the required registry settings.
3. Use the Group Policy Object Editor to view the policy settings in the following folder:

   Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options

On a computer that is running Windows Server 2003, the SMB signing Group Policy settings have the following names:

• Microsoft network server: Digitally sign communications (always)
• Microsoft network server: Digitally sign communications (if client agrees)
• Microsoft network client: Digitally sign communications (always)
• Microsoft network client: Digitally sign communications (if server agrees)

On a computer that is running Windows 2000 Server, the SMB signing Group Policy settings have the following names:

• Digitally sign server communication (always)
• Digitally sign server communication (when possible)
• Digitally sign client communications (always)
• Digitally sign client communications (when possible)

Typically, the SMB signing Group Policy settings are configured as "Not Defined". If you define the SMB signing Group Policy settings, make sure that you understand how the settings may affect network connectivity. For more information about the SMB signing settings, click the following article number to view the article in the Microsoft Knowledge Base: If you change the GPO settings on a domain controller that is running Windows 2000 Server, follow these steps:

1. Start a command prompt. To do this, click Start, click Run, type cmd in the Open box, and then click OK.
2. Type secedit /refreshpolicy machine_policy /enforce, and then press ENTER.
3. Restart the affected client computers.
4. Re-check the SMB signing values in the registry on the client computers to make sure that they did not change unexpectedly.

If you change the GPO settings on a domain controller that is running Windows Server 2003, follow these steps:

1. Start a command prompt. To do this, click Start, click Run, type cmd in the Open box, and then click OK.
2. Type gpupdate /force, and then press ENTER.
3. Restart the affected client computers.
4. Re-check the SMB signing values in the registry on the client computers to make sure that they did not change unexpectedly.

If the SMB signing values in the registry change unexpectedly after you restart the client computers, use one of the following methods to view the applied policy settings that are applied to a client computer:

• On a Windows XP-based computer, use the Resultant Set of Policy MMC snap-in (Rsop.msc). For more information about Resultant Set of Policy, visit the following Microsoft "Resultant Set of Policy" Web site:

  http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prda_dcm_bpxs.asp

• On Windows 2000, use the Gpresult.exe command-line tool to examine the Group Policy results. To do this, follow these steps:
  1. Install Gpresult.exe from the Windows 2000 Resource Kit.
     
     Alternatively, you can download Gpresult.exe from the following Microsoft "Gpresult.exe: Group Policy Results" Web site:

     http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpresult-o.asp

  2. At a command prompt, type gpresult /scope computer, and then press ENTER.
  3. In the Applied Group Policy Objects section of the output, note the Group Policy objects that are applied to the computer account.
  4. Compare the Group Policy objects that are applied to the computer account that has the SMB signing policy settings on the domain controller for these Group Policy objects.

Step three: Make sure that the TCP/IP NetBIOS Helper service is started on all computers

All computers on the network must run the TCP/IP NetBIOS Helper service.

To verify that the TCP/IP NetBIOS Helper service is running on a Windows XP-based computer, follow these steps:

1. Click Start, and then click Control Panel.
2. If Control Panel is in Category View, click Switch to Classic View.
3. Double-click Administrative Tools.
4. Double-click Services.
5. In the Services list, click TCP/IP NetBIOS Helper. Verify that the value under the Status column is Started. Verify that the value under the Startup Type column is Automatic. If the Status or the Startup Type values are not correct, follow these steps:
   1. Right-click TCP/IP NetBIOS Helper, and then click Properties.
   2. In the Startup type list, click Automatic.
   3. In the Service status area, if the service is not started, click Start.
   4. Click OK.

To verify that the TCP/IP NetBIOS Helper service is running on a Windows Server 2003-based computer, follow these steps:

1. Click Start, point to Administrative Tools, and then click Services.
2. In the Services list, click TCP/IP NetBIOS Helper. Verify that the value under the Status column is Started. Verify that the value under the Startup Type column is Automatic. If the Status or the Startup Type values are not correct, follow these steps:
   1. Right-click TCP/IP NetBIOS Helper, and then click Properties.
   2. In the Startup type list, click Automatic.
   3. In the Service status area, if the service is not started, click Start.
   4. Click OK.

To verify that the TCP/IP NetBIOS Helper service is running on a Windows 2000-based computer, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click Services.
2. In the Services list, click TCP/IP NetBIOS Helper Service. Verify that the value under the Status column is Started. Verify that the value under the Startup Type column is Automatic. If the Status or the Startup Type values are not correct, follow these steps:
   1. Right-click TCP/IP NetBIOS Helper Service, and then click Properties.
   2. In the Startup type list, click Automatic.
   3. In the Service status area, if the service is not started, click Start.
   4. Click OK.

Additionally, make sure that you have not disabled one or more of the required system services by using Group Policy objects. View these policy settings by using the Group Policy Object Editor in the "Computer Configuration/Windows Settings/Security Settings/System Services" folder.

On Windows Server 2003 and Windows XP, you can use the Resultant Set of Policy MMC snap-in (Rsop.msc) to check all applied policy settings that are applied to a computer. To do this, click Start, click Run, type rsop.msc in the Open box, and then click OK.

On Windows 2000, use the Gpresult.exe command-line tool to examine the Group Policy results. To do this, follow these steps:

1. Install Gpresult.exe from the Windows 2000 Resource Kit.
   
   Alternatively, to download Gpresult.exe, visit the following Microsoft "Gpresult.exe: Group Policy Results" Web site:

   http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpresult-o.asp

2. At a command prompt, type gpresult /scope computer, and then press ENTER.
3. In the Applied Group Policy Objects section of the output, note the Group Policy objects that are applied to the computer account.
4. Compare the Group Policy objects that are applied to the computer account with the SMB signing policy settings on the domain controller for these Group Policy objects.

Note If the TCP/IP NetBIOS Helper service is disabled on many desktops, you can use the following sample Microsoft Visual Basic script to start the TCP/IP NetBIOS Helper service on all computers in an organizational unit (OU) at the same time.

Microsoft provides programming examples for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and with the tools that are used to create and to debug procedures. Microsoft support engineers can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific requirements.

Set objDictionary = CreateObject("Scripting.Dictionary") 
i = 0 
Set objOU = GetObject("LDAP://OU=Computers, OU=OUName, OU=OUName, DC=OUName, 
DC=OUName,DC=CompanyName, 
DC=com") 
objOU.Filter = Array("Computer") 
For Each objComputer In objOU 
        objDictionary.Add i, objComputer.CN 
        i = i + 1 
Next 
For Each objItem In objDictionary 
        strComputer = objDictionary.Item(objItem) 
        Set objWMIService = 
GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & 
"\root\cimv2")

        Set colServices = objWMIService.ExecQuery _ 
                ("Select * from Win32_Service where Name = 'LmHosts'") 
        For Each objService In colServices 
                If objService.StartMode = "Disabled" Then 
                        objService.Change( , , , , "Automatic") 
                End If 
        Next 
Next 

Step four: Make sure that Distributed File System (DFS) is enabled on all computers

All domain controllers must run the Distributed File System service because the Sysvol share is a DFS volume. Additionally, the DFS client must be enabled in the registry on all computers.

To make sure that the Distributed File System service is running on Windows Server 2003-based domain controllers, follow these steps:

1. Click Start, point to Administrative Tools, and then click Services.
2. In the Services list, click Distributed File System service. Verify that the value under the Status column is Started. Verify that the value under the Startup Type column is Automatic. If the Status or the Startup Type values are not correct, follow these steps:
   1. Right-click Distributed File System, and then click Properties.
   2. In the Startup type list, click Automatic.
   3. In the Service status area, if the service is not started, click Start.
   4. Click OK.

To make sure that the Distributed File System service is running on Windows 2000 Server-based domain controllers, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click Services.
2. In the Services list, click Distributed File System service. Verify that the value under the Status column is Started. Verify that the value under the Startup Type column is Automatic. If the Status or the Startup Type values are not correct, follow these steps:
   1. Right-click Distributed File System, and then click Properties.
   2. In the Startup type list, click Automatic.
   3. In the Service status area, if the service is not started, click Start.
   4. Click OK.

For more information about a related topic, click the following article number to view the article in the Microsoft Knowledge Base: To make sure that the Distributed File System client is enabled on all client computers, follow these steps:

1. Click Start, click Run, type regedit in the Open box, and then click OK.
2. Expand the following subkey:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup

3. Click Mup, and then in the right pane, search for a DWORD value entry that is named DisableDFS.
4. If the DisableDFS entry exists and the value data is 1, double-click DisableDFS. In the Value data box, type 0, and then click OK. If the DisableDFS value data is already 0, or if the DisableDFS entry does not exist, do not make any change.
5. Quit Registry Editor.
6. If you changed the DisableDFS value data, restart the computer.

For more information about a related topic, click the following article number to view the article in the Microsoft Knowledge Base:

Step five: Examine the contents and the permissions of the Sysvol folder

By default, the Sysvol folder is located in the %systemroot% folder. The Sysvol folder contains the domain's Group Policy objects, the Sysvol and Netlogon shares, and the File Replication service (FRS) staging folder.

If the permissions on the Sysvol folder or the Sysvol share are too restrictive, group policies cannot be applied correctly, and cause user environment (Userenv) errors. Additionally, Userenv errors may occur if the Sysvol share or Group Policy objects are missing.
To make sure that the Sysvol share is available, run the net share command at a command prompt on each domain controller. To do this, follow these steps:

1. Click Start, click Run, type cmd in the Open box, and then click OK.
2. Type net share, and then press ENTER.
3. Locate SYSVOL and NETLOGON in the list of folders.

If the Sysvol or Netlogon shares are missing from one or more domain controllers, you must troubleshoot the cause of the problem. For more information about how to troubleshoot the missing Sysvol and Netlogon shares in Windows 2000 Server, click the following article number to view the article in the Microsoft Knowledge Base: For more information about how to rebuild the Sysvol share in Windows Server 2003, click the following article number to view the article in the Microsoft Knowledge Base: After you make sure that the Sysvol share is available, make sure that the Sysvol folder, the Sysvol share, and the root folder of the volume that contains the Sysvol folder are configured with the correct permissions. For more information about the permissions that are required by the Sysvol share and the Sysvol folder, click the following article number to view the article in the Microsoft Knowledge Base: Additionally, on Windows 2000 Server, the Everyone group must be granted Full Control permission on the root folder of the volume that contains the Sysvol folder. On Windows Server 2003, the Everyone group must be granted the Read & Execute special permission to "This folder only," and the domain\Users group must be granted the following standard permissions:

• Read & Execute
• List Folder Contents
• Read

Additionally, on Windows Server 2003, the domain\Users group must have the following special permissions:

• Read & Execute permission to "This folder, subfolders and files."
• Create Folder / Append Data permission to "This folder and subfolders."
• Create Files / Write Data permission to "Subfolders only."

After you verify the Sysvol permissions, make sure that the Sysvol folder contains the required Group Policy objects. To look for the required Group Policy objects, use the Gpotool.exe program from the Windows 2000 or the Windows Server 2003 Resource Kit.

To download the Windows 2000 Server Gpotool.exe program, visit the following Microsoft "Gpotool.exe: Group Policy Verification Tool" Web site: To download the Windows Server 2003 Resource Kit tools, visit the following Microsoft "Windows Server 2003 Resource Kit Tools" Web site: If you run the Gpotool.exe program without any options, it scans for all the Group Policy objects on all domain controllers in the domain. If you include the /checkacl switch, the tool also scans the Sysvol access control list (ACL). For detailed output when you run the Gpotool.exe program, use the /verbose switch.

Alternatively, you can manually verify the individual GPO in the SYSVOL folder. For example, if the description in the Userenv 1058 event lists the name of a GPO, you can manually verify the individual GPO in the SYSVOL folder. You can do this to make sure that it contains a USER folder, a MACHINE folder, and a Gpt.ini file. To manually verify the individual GPO in the SYSVOL folder, follow these steps:

1. Start a command prompt. To do this, click Start, click Run, type cmd in the Open box, and then click OK.
2. Type at Time /interactive /next: cmd.exe, and then press ENTER, where Time is 1 or 2 minutes later than the present time, and is written in 24-hour time format. For example, 3 minutes after 1:00 p.m. would be 13:03 in 24-hour time format.
3. At the time that you specify in the previous command, a new Command Prompt window opens. Type net use j: \\domainname.com\sysvol\domainname.com\Policies\{GUID} , and then press ENTER, where GUID is the GUID of the GPO that is in the Userenv event description. For example, if the Userenv 1058 event description says, "The file must be present at the location <\\Domain_Name.com\sysvol\Domain_Name.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984 F9}\gpt.ini>," the GUID that you would use in the command is 31B2F340-016D-11D2-945F-00C04FB984F9.
4. Type dir j:\*.*, and then press ENTER.
5. Verify that a USER folder, a MACHINE folder, and a Gpt.ini file are listed in the folder listing for the I drive. If any one of these folders and files are missing, the computers on the network are likely to log Userenv errors in the Application log.

If one or more Group Policy objects are missing from the Sysvol folder , run the Windows Server 2003 Default Group Policy Restore Utility (Dcgpofix.exe), or the Windows 2000 Default Group Policy Restore Tool (Recreatedefpol.exe), to re-create the default Group Policy objects.

The Dcgpofix.exe program is included with Windows Server 2003. For additional information about the Dcgpofix.exe program, run the dcgpofix /? command at a command prompt.

For information about the Recreatedefpol.exe program, visit the following Microsoft Windows 2000 Default Group Policy Restore Tool Web site: Make sure to set the recommended exclusions when you are scanning the Sysvol drive with antivirus software. Scanning with antivirus software can block access to the required files, such as the Gpt.ini file. You must configure these exclusions for all real-time, scheduled, and manual antivirus scans. For more information about the recommended exclusions when you run antivirus programs on Windows-based servers, click the following article number to view the article in the Microsoft Knowledge Base:

Step six: Make sure that the Bypass traverse checking right is granted to the required groups

The Bypass traverse checking right must be granted to the following groups on the domain controllers:

• Administrators
• Authenticated Users
• Everyone
• Pre-Windows 2000 Compatible Access

To verify that the Bypass traverse checking right has been granted on a Windows Server 2003-based domain controller, follow these steps:

1. Click Start, point to Administrative Tools, and then click Domain Controller Security Policy.
2. Expand Local Policies, and then click User Rights Assignment.
3. Double-click Bypass traverse checking.
4. Click to select the Define these policy settings check box.
5. Verify that the Administrators, Authenticated Users, Everyone, and Pre-Windows 2000 Compatible Access groups are listed for this policy setting. If any of these groups are missing, follow these steps:
   1. Click Add User or Group.
   2. In the User and group names box, type the name of the missing group, and then click OK.
6. Click OK to close the policy setting.
7. Start a command prompt. To do this, click Start, click Run, type cmd in the Open box, and then click OK.
8. Type gpupdate /force, and then press ENTER.

To verify that the Bypass traverse checking right has been granted on a Windows 2000 Server-based domain controller, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click Domain Controller Security Policy.
2. Expand Security Settings, expand Local Policies, and then click User Rights Assignment.
3. Double-click Bypass traverse checking.
4. Click to select the Define these policy settings check box.
5. Verify that the Administrators, Authenticated Users, Everyone, and Pre-Windows 2000 Compatible Access groups are listed for this policy setting. If any one of these groups are missing, follow these steps:
   1. Click Add.
   2. In the User and group names box, type the name of the missing group, and then click OK.
6. Click OK to close the policy setting.
7. Start a command prompt. To do this, click Start, click Run, type cmd in the Open box, and then click OK.
8. Type secedit /refreshpolicy machine_policy /enforce, and then press ENTER.

Step seven: Make sure that the domain controllers are not in a journal wrap state

To see if a domain controller is in a journal wrap state, view the File Replication service log in Event Viewer, and search for NTFRS event ID 13568. Event ID 13568 is similar to the following Event ID: Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13568
Date: DATE
Time: TIME
User: N/A
Computer: ServerName
Description: The File Replication Service has detected that the replica set "<1>" is in JRNL_WRAP_ERROR. Replica set name is : "<1>" Replica root path is : "<2>" Replica root volume is : "<3>" If NTFRS event ID 13568 is logged on a domain controller, view the following Microsoft Knowledge Base article for information about how to troubleshoot journal wrap errors:

Step eight: Run the Dfsutil /PurgeMupCache command

Run the Dfsutil.exe program with the /PurgeMupCache switch to flush the local DFS/MUP cached information. The Dfsutil.exe program is included in the Windows 2000 Server Support Tools and the Windows Server 2003 Support Tools. For more information about a related topic, click the following article number to view the article in the Microsoft Knowledge Base: