****
*
*
*
*







*
*
                                      
*
*
Windows Server



    

Authoritative Userenv 1030 and 1058 Troubleshooting Guide    

*
*

*
*

Authoritative Userenv 1030 and 1058 Troubleshooting Guide



Apr
16

Authoritative Userenv 1030 and 1058 Troubleshooting Guide

 

Authoritative Userenv 1030 and 1058 Troubleshooting Guide

Number          :           SOX030714700054

TITLE: Authoritative Userenv 1030 and 1058 Troubleshooting Guide

Problem Windows Server 2003 Standard

ID: SOX030714700054

 

Problem Description

SYMPTOMS

========

 

Windows XP Professional and Windows Server 2003 computers may log events in the

application log that are similar to the following:

 

Event Type: Error

Event Source: Userenv

Event Category: None

Event ID: 1058

Date: Date

Time: Time

User: DOMAINNAME\Username

Computer: COMPUTERNAME

Description:

Windows cannot access the file gpt.ini for GPO

CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domainname,DC=com

. The file must be present at the location

<\\domainname.com\sysvol\domainname.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984

F9}\gpt.ini>. (<Error message> ). Group Policy processing aborted.

 

For more information, see Help and Support Center at

http://go.microsoft.com/fwlink/events.asp.

 

Event Type: Error

Event Source: Userenv

Event Category: None

Event ID: 1030

Date: Date

Time: Time

User: DOMAINNAME\Username

Computer: COMPUTERNAME

Description:

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.

 

For more information, see Help and Support Center at

http://go.microsoft.com/fwlink/events.asp.

 

Note: The specific error message in the Description field of the Userenv 1058 event

appears in the parentheses after the gpt.ini file location. The following are some

of the common error messages that occur:

 

The network path was not found.

Access is denied.

Configuration information could not be read from the domain controller, either

because the machine is unavailable, or access has been denied.

 

Typically, client computers and member servers log these events at startup, and

domain controllers log these events every five minutes.

 

Also, Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced

Server computers may log an event in the application log that is similar to the

following:

 

Event Type: Error

Event Source: Userenv

Event Category: None

Event ID: 1000

Date: Date

Time: Time

User: NT AUTHORITY\SYSTEM

Computer: COMPUTERNAME

Description:

Windows cannot access the registry information at

\\domainname.com\sysvol\domainname.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F

9}\Machine\registry.pol with (<Error code>).

 

Note: The specific error code in the Description field of the Userenv 1000 event

appears in the parentheses after the registry.pol file location. Some of the common

error codes are 5, 51, 53, 1231, 1240, and 1722.

 

When these errors occur, group policy settings fail to apply to the affected

computers, or group policy replication fails between the domain controllers on the

network. In some cases, you are not able to open group policy snap-ins such as the

Domain Controller Security Policy snap-in or the Domain Security Policy snap-in.

For example, the group policy snap-ins may fail to open with an error message that

is similar to one of the following:

 

Failed to open the Group Policy Object. You may not have the appropriate rights.

 

Details:

The account is not authorized to log in from this station.

 

-or-

 

You do not have permission to perform this operation.

 

Details:

Access is denied.

 

-or-

 

Failed to open the Group Policy Object. You may not have the appropriate rights.

 

Details:

The system cannot find the path specified.

 

You also may receive errors when accessing file shares on domain controllers, even

if you are logged on to the server's console and trying to access a share that is

local. In particular, this may affect access to a domain controller's Sysvol share.

When you try to access the file shares, you may receive repeated password prompts,

or you may receive an error message that is similar to the following:

 

\\servername\sharename is not accessible. You might not have permission to use this

network resource. Contact the administrator of this server to find out if you have

access permissions.

 

The account is not authorized to log in from this station.

 

-or-

 

\\servername\sharename is not accessible.

 

The account is not authorized to log in from this station.

 

-or-

 

The network path was not found.

 

 

CAUSE

=====

 

These errors may occur when computers on the network are not able to connect to the

group policy objects in the Sysvol folders on the domain controllers.

 

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> 

Resolution

 

 

RELATED ISSUES

==============

 

If a DC is logging these Userenv errors, and you are not able to open the group

policy snap-ins on the DC, this often is because the server's SMB signing settings

for its Server and Workstation services contradict each other. For example, SMB

signing may be disabled for the Workstation service on a domain controller, but SMB

signing is required for the Server service on the same domain controller. For more

information about this issue, see the following KB article:

 

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

Additionally, the issue that is described in Window SE bug 79284 may cause a

Windows Server computer to log these Userenv events. In this case, the server may

stop responding after resuming from standby, and the "Applying Personal Settings"

message box may appear for up to an hour before the desktop appears. For additional

information about this issue, see the following KB article:

 

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

On an OEM copy of Windows Small Business Server 2003, the gpt.ini file path that

appears in the Userenv 1058 description may list a domain that starts with "OEM"

instead of the domain name that you selected during mini-setup. For example, the

gpt.ini path may be similar to

\\OEMSBSDN-9601.local\sysvol\OEMSBSDN-9601.local\Policies\{GUID}. If this is the

case, see SOX040119700097 for the cause and resolution to this issue.

 

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.

 

 

RESOLUTION

==========

 

If none of the related issues that are described earlier apply, follow these steps

to troubleshoot the Userenv errors:

 

===============================================================================

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 misconfiguration 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, 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 2000, double-click Network and Dial-up Connections. 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.

 

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. In

particular, the computer must *not* use the DNS servers that belong to your ISP. 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 AD. To find out what IP addresses a

computer is using for DNS, 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, 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 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, make sure that the forward

lookup zone for the domain contains valid "(same as parent folder)" Host (A)

records. To do so, 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, 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, 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.

 

By default, SMB signing is enabled - but not required - 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, if

possible, but can still communicate with servers that have SMB signing disabled. To

configure the client computers this way, 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, change the values on the computers to match what is listed

here. Then, restart the Server and Workstation services. But do not restart the

computers yet. 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, 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 2003:

 

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)

 

These are the names of the comparable policy settings on Windows 2000 Server:

 

Digitally sign server communication (always)

Digitally sign server communication (when possible)

Digitally sign client communications (always)

Digitally sign client communications (when possible)

 

In most cases, these policy settings should be "Not Defined." If you define these

policy settings, 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 2003, run the

command "gpupdate /force". On a DC that is running Windows 2000 Server, run the

command "secedit /refreshpolicy machine_policy /enforce". 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, 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 make sure that the Netlogon and Remote Procecure Call (RPC) are Started and

Automatic on all computers.

 

Finally, 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

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. 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 System Services policy settings in all

of the applied group policy objects.

 

NOTE: If the TCP/IP NetBIOS Helper service is disabled on a large number of

desktops, the More Information section of this SO contains a sample VB script to

start the service on all computers at one time.

 

 

===============================================================================

Step 4: 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. In addition, the DFS client must be enabled in the

registry on all computers.

 

To make sure that the Distributed File System service is running on the domain

controllers, 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.

 

NOTE: This issue currently is documented in the following KB article:

 

834649 Client computers record Event ID 1030 and Event ID 1058 when DFS is not

started on a Windows 2000-based domain controller

http://support.microsoft.com/?id=834649

To make sure that the Distributed File System client is enabled on all computers,

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.

 

NOTE: This issue currently is documented in the following KB articles:

 

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

259398 SceCli Event ID 1001 and UserEnv Event ID 1000 When Dfs Client Is Disabled

(Windows 2000)

http://support.microsoft.com/default.aspx?id=259398

 

 

 

 

===============================================================================

Step 5: Check the contents and the permissions of the Sysvol folder

===============================================================================

 

By default, the Sysvol folder is located in the %systemroot% folder. Syvol 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. Also, make sure that the Netlogon share

is listed. Repeat this step on all domain controllers on the network. If the Sysvol

or Netlogon share is missing from one or more domain controllers, see the following

articles for information about troubleshooting this problem:

 

327781 How to Troubleshoot Missing SYSVOL and NETLOGON Shares on Windows Server

2003 Domain Controllers

http://support.microsoft.com/?id=327781

257338 Troubleshooting Missing SYSVOL and NETLOGON Shares on Windows 2000

http://support.microsoft.com/?id=257338

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.

 

On Windows 2000 Server, the Everyone group should have Full Control on the root of

the volume that contains the Sysvol folder. For the root of the volume on Windows

Server 2003, the Everyone group should have the Read & Execute special permission

applied to "This folder only", and the domain\Users group should have the following

standard permissions:

 

Read & Execute

List Folder Contents

Read

 

Additionally, on Windows Server 2003, 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. To check for these, 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 Web site:

 

Gpotool.exe: Group Policy Verification Tool

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

To download the Windows Server 2003 Resource Kit tools, visit the following Web

site:

 

Windows Server 2003 Resource Kit Tools

http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18

c4790cffd&DisplayLang=en

 

If you run the gpotool.exe program without any options, it will check for all the

group policy objects on all domain controllers in the domain. If you include the

/checkacl option, the tool additionally will check the Sysvol access control list

(ACL). Use the /verbose option for more detailed information.

 

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.

 

If you determine that the Sysvol folder is missing one or more group policy

objects, you can run the Windows Server 2003 Default Group Policy Restore Utility

(DcGPOFix.exe) or the Windows 2000 Default Group Policy Restore Tool

(RecreateDefpol.exe) to recreate the default group policy objects. The DcGPOFix.exe

program is included on Windows Server 2003. For help on using this program, run the

command "dcgpofix /?" in a command prompt window. For information about the

RecreateDefpol.exe program, visit the following Web site:

 

Windows 2000 Default Group Policy Restore Tool

http://www.microsoft.com/downloads/details.aspx?FamilyID=b5b685ae-b7dd-4bb5-ab2a-976

d6873129d&DisplayLang=en

 

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, 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

315070 Event 13568 Is Logged in the File Replication Service Event Log

 

 

===============================================================================

Step 8: Run the "dfsutil /PurgeMupCache" command

===============================================================================

 

The issue that is described in Windows SE bug 62977 may cause Userenv 1058 and 1030

errors. To work around this problem, run the dfsutil.exe program from the Windows

2000 Server or Windows Server 2003 Support Tools with the /PurgeMupCache option.

This option will flush the local DFS/MUP cached information. For additional

information about this issue, see the following KB article:

 

830676 Group Policy processing fails with Events 1058 and 1030 in Windows Server

2003

http://support.microsoft.com/?id=830676

MORE INFORMATION

================

 

The following is a sample VB script to start the TCP/IP NetBIOS Helper on all

computers on the network:

 

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

 

Here is another way to remotely start the service:

 

166819 Using Sc.exe and Netsvc.exe to Control Services Remotely

http://support.microsoft.com/?id=166819

C:\> sc \\RemoteComp config LmHosts start= demand

 

C:\> netsvc /start \\RemoteComp "LmHosts"

 

Note: LmHosts is the short name for the TCP/IP Netbios Helper service

 

===============================================================================

 

Here is a method to check an individual GPO in the SYSVOL folder:

 

Run the following command, where "time" is the time in 24-hour time format that is

1 or 2 minutes later than the current time:

 

at time /interactive /next: cmd.exe

 

For example, if the current time that appears in the notification at the far right

of the taskbar is 3:03 PM, type 15:04 for the time parameter in the at command

line. When you do this, the command is scheduled to run at 3:04 PM.

 

When the new Command Prompt window opens, enter the following command, where "GUID"

is the GUID of the GPO that appears in the Userenv event description:

 

net use j: \\domainname.com\sysvol\domainname.com\Policies\{GUID}

 

For example, if the Userenv 1058 event description says, "The file must be present

at the location

<\\domainname.com\sysvol\domainname.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984

F9}\gpt.ini>," use 31B2F340-016D-11D2-945F-00C04FB984F9 for the GUID. In this case, the resulting command will be:

 

net use j: \\domainname.com\sysvol\domainname.com\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}

 

Then enter the command:

 

dir j:\*.*

 

The directory listing for the J drive should contain a USER folder, a MACHINE folder, and a gpt.ini file. If any of these are missing, computers on the network are likely to log Userenv errors.

 

 =======================================================================

 

 

 



No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/3132

Leave a comment








*
*

administrator
Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!


*
*
*
*
****



*****



    Desktop
  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
    PDA
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
    more...
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011