Hi, I have a Windows 2003 server that is giving me the error1054,1030 and1058.The DCs with Windows 2003 SP2. I have updated drivers for NICs, updates, change the wiring, ect. but I can not resolve the situation. You can help me?. Thank you**************************************************************************Event ID: 1054Source: UserenvType: ErrorDescription: Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted.**************************************************************************Event ID: 1030Event Source: UserenvEvent Type: ErrorDescription:Windows cannot query for the list of Group Policy objects. A message that describes the reason for this was previously logged by the policy engine.**************************************************************************Event ID: 1058Event Source: UserenvType: ErrorDescription:Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=office. The file must be present at the location <\\office\sysvol\office\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (The network path was not found. ). Group Policy processing aborted.**************************************************************************

Hi Frank, Since the Userenv 1030, 1050 and 1058 error may be caused by several aspects, I have list some common troubleshooting steps for your references. Please refer to the steps and the KB articles and check if it helps. Troubleshooting steps: Step 1: Check the DNS settings and network properties on the servers and client computers In the local area connection properties, the Client for Microsoft Networks must be enabled on all servers and client computers, and the File and Printer Sharing for Microsoft Networks component must be enabled on all domain controllers. In addition, every computer on the network must use DNS servers that can resolve SRV records and host names for the Active Directory forest that the computer is a member of. A common mis-configuration is for client computers to use the DNS servers that belong to your ISP. Check these settings on all computers that are logging the Userenv errors. Additionally, check these settings on all domain controllers, whether they are logging Userenv errors or not. To check DNS settings and network properties, pleaser follow these steps: 1. Click Start, point to Settings, and then click Control Panel. 2. On Windows XP, if Control Panel is in Category View, click Switch to Classic View. 3. On Windows Server 2003 and Windows XP, double-click Network Connections. 4. Right-click the icon for the local area connection, and then click Properties. 5. On the General tab of the connection properties, make sure that Client for Microsoft Networks is checked in the list of components. On domain controllers, also make sure that File and Printer Sharing for Microsoft Networks is checked. If these components are not checked, click to check them. Please note: On multi-homed Remote Access and ISA servers, you can disable the File and Printer Sharing component for the network adapter that is connected to the Internet. However, the Client for Microsoft Networks component must be enabled for all of the server's adapters. 6. Click to select Internet Protocol (TCP/IP), and then click Properties (do not un-check the box for this component). 7. If the "Use the following DNS server addresses" option 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 the AD. If the DNS server addresses are not correct, enter the IP addresses of the correct DNS servers. 8. Click Advanced. 9. Click the DNS tab. 10. Click to check the "Register this connection's addresses in DNS" option. 11. Click OK three times. 12. Run the command "ipconfig /flushdns". 13. Run the command "ipconfig /registerdns". 14. If you enabled one of the networking components on step 5, reboot the computer for this change to take effect. If client computers are configured to obtain their IP addresses automatically, make sure that the DHCP server is assigning the IP addresses of DNS servers that can resolve SRV records and host names in the Active Directory. To find out what IP addresses a computer is using for DNS, please run the command "ipconfig /all". If computers that are configured to obtain IP addresses automatically are not using the correct DNS servers, see the documentation for your DHCP server for information about how to configure the DNS servers option. Also, please make sure that each computer can resolve the IP address of the domain. To test this, run the command "ping domainname.local" or the command "nslookup domainname.local", where domainname.local is the name of the domain that the computer is a member of. This host name should 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, please make sure that the forward lookup zone for the domain contains valid "(same as parent folder)" Host (A) records. To do so, please follow these steps: 1. On a DC in the domain that is running DNS, click Start, point to Programs or All Programs, point to Administrative Tools, and then click DNS. 2. Expand the server object, expand the Forward Lookup Zones folder, and then click the forward lookup zone for the domain. 3. Look for Host (A) records with the name "(same as parent folder)". 4. If a Host (A) record with this name does not exist, use these steps to create one: a. On the Action menu, click New Host. b. In the "IP address" text box, type the IP address of the domain controller's local network adapter. c. Leave the Name box empty, click Create Associated PTR Record, and then click Add Host. d. When you receive the "(same as parent folder) is not a valid host name. Are you sure you want to add this record?" message, click Yes. 5. If one or more "(same as parent folder)" Host (A) records contains an invalid IP address, double-click the invalid record to change the IP address, or delete the invalid record. To delete a record, right-click the record, and then click Delete. If the DNS server is a domain controller that is also a Routing and Remote Access server, please see the following KB article: 292822 Name resolution and connectivity issues on a Routing and Remote Access Server that also runs DNS or WINS http://support.microsoft.com/?id=292822 6. If you add, delete, or modify DNS records, run the command "ipconfig /flushdns" on all affected computers. Step 2: Check the SMB signing settings on the client computers The SMB signing settings define whether or not the computers on the network digitally sign communications. If the SMB signing settings are not configured correctly, the client computers may not be able to connect to domain controllers. For example, a common misconfiguration is requiring SMB signing on the domain controllers, but disabling SMB signing on the client computers. When this occurs, group policy application fails, and the client computers log Userenv errors 1030 and 1058 By default, SMB signing is enabled for client communication on Windows XP and Windows 2000 Professional computers. This is the recommended configuration because computers configured this way will use SMB signing can still communicate with servers that have SMB signing disabled. To configure the client computers this way, please set the following registry values: In the subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters Value name: enablesecuritysignature Data type: REG_DWORD Value data: 0 Value name: requiresecuritysignature Data type: REG_DWORD Value data: 0 In the subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters Value name: enablesecuritysignature Data type: REG_DWORD Value data: 1 Value name: requiresecuritysignature Data type: REG_DWORD Value data: 0 If the registry values on the affected client computers do not match the values that are listed here, please change the values on the computers to match what is listed here. Then, restart the Server and Workstation services. Restarting the computers may cause group policies to apply, 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, please check the group policy settings that apply to the affected computer accounts to make sure that they do not conflict. In the Group Policy Object Editor on a DC, these policy settings are located under Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options. These are the names of the SMB signing policy settings on Windows Server 2008: 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) In most cases, these policy settings should be "Not Defined". If you define these policy settings, please be sure that you understand how the settings may affect network connectivity. For more information about the SMB signing settings, see the "Digitally sign communications" sections of the following KB article: 823659 Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments http://support.microsoft.com/?id=823659 If you change GPO settings on a DC that is running Windows Server 2008, run the command "gpupdate /force". After you do this, restart the affected client computers, and then re-check the SMB signing registry values to make sure that they did not change unexpectedly. If the SMB signing registry values change unexpectedly after a reboot, you can use the Resultant Set of Policy MMC snap-in (rsop.msc) on Windows XP to check all applied policy settings that are applied to the computer. On Windows 2000, install gpresult.exe from the Windows 2000 Resource Kit to check the group policy results. To download gpresult.exe, visit the following Web site: Gpresult.exe: Group Policy Results http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpresult-o.asp After you install gpresult.exe, run the command, "gpresult /scope computer" on the affected computer. The "Applied Group Policy Objects" section of this command's output will list all of the group policy objects that are applied to the computer account. Once you have this list, check the SMB signing policy settings on the DC for these group policy objects. Step 3: 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 check the TCP/IP NetBIOS Helper service, please follow these steps: 1. Click Start, point to Settings, and then click Control Panel. 2. On Windows XP, 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 console, check the Status and the Startup Type value for the TCP/IP NetBIOS Helper service. The Status should be Started, and the Startup Type should be Automatic. 6. If the Status and the Startup Type are not Started and Automatic, right-click TCP/IP NetBIOS Helper service, and then click Properties. 7. In the TCP/IP NetBIOS Helper Properties, click to select Automatic in the "Startup type" box. 8. If the service is not started, click Start to start the service, and then click OK. Also please make sure that the Netlogon and Remote Procedure Call (RPC) are Started and Automatic on all computers. Finally, please make sure that you have not disabled any of the required system services using group policy objects. These policy settings are under Computer Configuration/Windows Settings/Security Settings/System Services. On Windows Server 2008 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. Step 4: Make sure that Distributed File System (DFS) is enabled on all computers If the domain functional level is "Windows Server 2008", the all domain controllers must run the Distributed File System service because the SYSVOL share depends on the DFS-R service to replicate the sysvol folder among the DCs . To make sure that the Distributed File System service is running on the domain controllers, please follow these steps: 1. On each domain controller, click Start, point to Programs or All Programs, point to Administrative Tools, and then click Services. 2. In the Services console, check the Status and the Startup Type value for the Distributed File System service. The Status should be Started, and the Startup Type should be Automatic. 3. If the Status and the Startup Type are not Started and Automatic, right-click Distributed File System service, and then click Properties. 4. In the Distributed File System Properties, click to select Automatic in the "Startup type" box. 5. If the service is not started, click Start to start the service, and then click OK. To make sure that the Distributed File System client is enabled on all computers, please follow these steps: 1. Click Start, and then click Run. 2. In the Run box, type "regedit", and then click OK. 3. In the Registry Editor, open the following subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup 4. In the Mup subkey, look for a DWORD value named DisableDFS. 5. If the DisableDFS value exists, and the value data is 1, double-click this value, type "0" in the "Value data" box, and then click OK. If the DisableDFS value data is already 0, or if this value does not exist, do not make any change. 6. Close Registry Editor. 7. If you changed the DisableDFS value, restart the computer for this setting to take effect. Step 5: Check the contents and the permissions of the Sysvol folder By default, the Sysvol folder is located in the %systemroot% folder. SySvol 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, this can cause group policies to fail with Userenv errors. Additionally, Userenv errors can occur if the Sysvol share or group policy objects are missing. To make sure the Sysvol share is available, run the "net share" command on the DC. SYSVOL should appear in the list of shares. Please make sure that the Netlogon share is listed. If the Sysvol or Netlogon share is missing from one or more domain controllers, please see the following articles for information about troubleshooting this problem: After you make sure the Sysvol share is available, make sure that the Sysvol folder, the Sysvol share, and the root of the volume that contains the Sysvol folder are configured with the the correct permissions. Additionally, on Windows Server 2008, the domain\Users group should have the following special permissions: Read & Execute applied to "This folder, subfolders and files" Create Folder / Append Data applied to "This folder and subfolders" Create Files / Write Data applied to "Subfolders only" For the permissions required for the Sysvol folder and the Sysvol share, see the following KB article: 290647 Event ID 1000, 1001 Is Logged Every Five Minutes in the Application http://support.microsoft.com/?id=290647 After you check the Sysvol permissions, make sure that the Sysvol folder contains the required group policy objects. NOTE: The More Information section contains the syntax for manually checking an individual GPO in the SYSVOL folder. For example, if the description in the Userenv 1058 event lists the GPO named {31B2F340-016D-11D2-945F-00C04FB984F9}, you can check the folder for this GPO to make sure that it contains a USER folder, a MACHINE folder, and a GPT.INI file. Finally, make sure to set the recommended exclusions when you are scanning the Sysvol drive with anti-virus software. AV scanning 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 AV scans. For more information about virus scanning on Windows Server domain controllers, see the following KB article: 822158 Virus scanning recommendations on a Windows 2000 or on a Windows Server 2003 domain controller http://support.microsoft.com/?id=822158 Step 6: Make sure that the "Bypass traverse checking" right is granted to the required groups To check the "Bypass traverse checking" right, please follow these steps: 1. On a DC, click Start, point to Programs or All 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 the "Bypass traverse checking" policy setting. 4. Click to check the "Define these policy settings" box, if the option is not enabled already. 5. The following groups should be listed for this policy setting: Administrators Authenticated Users Everyone Pre-Windows 2000 Compatible Access If any of these groups are missing, click Add, type the name of the missing group, and then click OK. 6. Click OK to close the policy setting. 7. On Windows Server 2003, run the "gpupdate /force" command. On Windows 2000, run "secedit /refreshpolicy machine_policy /enforce". Step 7: Make sure that the domain controllers are not in a journal wrap state To see if a DC is in a journal wrap state, open the File Replication Service log in Event Viewer, and then look for NTFRS event ID 13568. This event will have details similar to the following: 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 you see NTFRS event ID 13568 logged on a DC, see the following KB articles for information about troubleshooting journal wrap errors: 292438 Troubleshooting journal_wrap errors on Sysvol and DFS replica sets http://support.microsoft.com/?id=292438 Steps 8: Check on the Windows XP client to see if the cached credentials are used. On a Windows XP Professional computer, if the specific error message in the Userenv 1058 description is "Logon failure: unknown user name or bad password", this may be the result of the computer using cached credentials. To troubleshoot this error, open User Accounts in Control Panel, click the Advanced tab, click Manage Passwords, and then remove all of the cached credentials by selecting the credentials and clicking Remove. Meanwhile, please check the following KB articles to see if it is helpful for you. 839499 You cannot open file shares or Group Policy snap-ins when you disable SMB signing for the Workstation or Server service on a domain controller http://support.microsoft.com/?id=839499 842804 Group Policy processing does not work and events 1030 and 1058 are logged in the application log of a domain controller http://support.microsoft.com/?id=842804 314494 Group policies are not applied the way you expect; "Event ID 1058" and "Event ID 1030" errors in the application log (Windows XP) http://support.microsoft.com/?id=314494 Userenv errors occur and events are logged after you apply Group Policy to computers that are running Windows Server 2003, Windows XP, or Windows 2000 http://support.microsoft.com/kb/887303 How to Troubleshoot Missing SYSVOL and NETLOGON Shares on Windows Server 2003 Domain Controllers http://support.microsoft.com/?id=327781 Hope it helps.David Shen - MSFT