Announcement

**soibien** · 08-01-2009, 09:57 AM

Policy nay truoc gio dang chay ok ha ban?

**thanhtungjsc** · 08-01-2009, 12:07 PM

Originally posted by soibien View Post

Policy nay truoc gio dang chay ok ha ban?

Policy của mình trước đó vẫn ok, nhưng nhưng từ khi mình restore lại hệ thống thì kiểm tra event xuất hiện thông báo lỗi như vậy. Hiện mình vẫn chưa tìm cách xử lý.

**camaptrang** · 08-01-2009, 05:43 PM

Originally posted by thanhtungjsc View Post

Policy của mình trước đó vẫn ok, nhưng nhưng từ khi mình restore lại hệ thống thì kiểm tra event xuất hiện thông báo lỗi như vậy. Hiện mình vẫn chưa tìm cách xử lý.

bạn kiểm tra lại DNS server của bạn xem coi có good không ...

**soibien** · 09-01-2009, 05:33 PM

có thể có policy nào đó yêu cầu run script hiện script đó không còn nữa, hoặc security của file đó ngăn không cho user access. Bạn kiểm tra lại xem có policy nào run script không? và kiểm tra xem user có thể truy xuất file script đó không!

**ngocnet** · 16-01-2009, 02:04 PM

máy server cty mình cũng gặp lỗi y như của bạn vậy, các bạn giúp mình với vì hiện nay các máy con khi log vao domain thì chạy rất chậm

**luandat** · 04-02-2009, 02:06 AM

bạn dùng lệnh dcdiag /fix & netdiag/fix thử xem có cải thiện được tình hình không!

**hipcool1988** · 04-02-2009, 03:30 AM

Anonymous (Last update 12/3/2008):
I started receiving this error with event 1030 on my Windows 2003 x64 server. I checked the C:\windows\SYSVOL\sysvol\<domain name>\scripts folder, which did not have read rights for the "Everyone" group. I added them and the errors went away after a gpupdate /force.

Anonymous (Last update 11/6/2008):
A combination of event 1030, 1058, and 4015 can occur when a NIC is replaced and the binding order is wrong. Go to Network Connections -> Advanced Settings. In the Advanced menu make sure that the most important NIC is on top at the Adapters and Bindings tab.

Anonymous (Last update 7/7/2008):
We experienced this error after renaming a domain, using version 1.4 of the Microsoft domain rename tools. The fix was to unfreeze the forest configuration using the "rendom /end" command, and re-run the gpfixup tool that comes with it. This step had been missed in renaming the domain.

Scott Clement (Last update 4/8/2008):
In my case, the server started rejecting network traffic. Rebooting would fix it for a random amount of time, sometimes for hours and sometimes only for minutes. When it started rejecting traffic, the event logs would display events 1058 and 1030.
It turned out to be an issue with Symantec Endpoint Protection 11.0 that appeared after installing Windows 2003 SP2 and some hotfixes. There is a workaround or a maintenance release that will fix the problem. For more information on this issue, check pages 10 & 11 of this document “Symantec Endpoint Protection 11.0 - SBS 2003 Best Practices White Paper”.

Anonymous (Last update 3/19/2008):
We have two Domain Controllers and we received 1030\1058 errors every 5 minutes on our primary DC as many people have. It would at times, quit for a few hours and then start up again. Rebooting both DCs at the same time would sometimes get this to stop, but recently it just would not quit after installing security updates. Permissions on the "gpt.ini" file were fine. Gpupdate /force worked every time without errors. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\WaitForNetwork=1 was OK.
For me the fix was to add DWORD value in the registry as per M840669 even though the article is not listed as applying to Server 2003. The key and value are HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GpNetworkStartTimeoutPo licyValue = 60.
I rebooted and the errors did not reappear.

Bryan Lockwood (Last update 2/12/2008):
In my case, the problem (on Windows XP Pro, SP2) traced back to a broken DFS client. The following steps solved it:

1. dfsutil /purgemupcache (dfsutil.exe is in the Windows 2003 Support Tools).
2. Checked the following Registry values (two of them were not present): HKLM\System\CurrentControlSet\Services\Mup\Disable DFS=0
HKLM\Software\Policies\Microsoft\Windows\NetCache\ Enabled=1
HKLM\Software\Microsoft\Windows\CurrentVersion\Net Cache\Enabled=1.
3. Kill the mobsync.exe process.
4. Re-initialize CSC cache as explained in Method 1 at M230738. (Note that performing this step without killing mobsync did not have any effect).
5. Reboot the system as directed.

I have placed a full description of the issue and solution, with reference links, at the page “Troubleshooting XP Offline files”.

Anonymous (Last update 2/4/2008):
I fixed this problem on my Windows 2003 SBS server (two NIC cards - one for the Intranet and one for the outside world to access my web server) by moving the Intranet card to the top of the bindings list. Go to Start -> Control Panel -> Network Connections -> Advanced -> Advanced Settings. Under Adaptors and Bindings, move the NIC connected to your Intranet to the top of the list.

Anonymous (Last update 9/15/2007):
I encountered this error with EventID 1030 from source Userenv on Windows XP SP2 on about 10% of 150 workstations, which prevented logon script from running. The solutions varied:

1. Login as a Domain Admin. Then log in as the user.
2) Upgrade McAfee to 8.5i.
3) Remove QoS from networking.
4) Make user administrator of local machine.

One or several solved all of the problems.

Anonymous (Last update 9/7/2007):
I was also receiving multiple 1030/1058 errors every 5 minutes or so. As stated previously, dfsutil /PurgeMupCache also solved my problems. In case you do not have the Windows Server CD on hand, the Windows 2003 SP1 support tools installer can be downloaded from M892777.

Anonymous (Last update 8/25/2007):
I had this error after replacing a defective network card. Somehow, within the TCP/IP stack, the network interface is still present with the configured network card. After successfully configuring my new card, the problem appeared. I checked drivers, netsh, etc for this “ghost” card, but it was nowhere to be found. Therefore, I simply reset Winsock and the TCP/IP stack.
Do the following:
-netsh winsock reset
-netsh interface ip reset
-reboot the server
-reconfigure your ip address
-reboot the server.

Andreas Czech (Last update 8/25/2007):
In our case, the problem was caused by a registry entry that was missing. Under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon, if the "WaitForNetwork" entry is missing, you must add the entry as Dword with a value of "1".

Anonymous (Last update 8/7/2007):
I believe that this error may have been caused by a conflict with my Cisco VPN client (Secure Remote). Closing the application fixed the problem.

Anonymous (Last update 7/22/2007):
I have been having 1058 and 1030 errors for a while. Every time I tried to copy (with domain admin privileges) files from a DC to a member server, it would give me an “account disabled” message. It turned out that the problem was caused by eTrust 7.0 real time that was locking out the account.

Peter Appel (Last update 6/10/2007):
In my case, I installed a W2k3 member server in a Domain with two W2k3 domain controllers. Right after the member server came into the domain, I received events 1058 and 1030 (Access denied) on all three servers. Because the member server has to support the domain with WSUS, I downloaded and installed the "Group Policy Management Console" (gpmc.msi) from Microsoft. When I tried to open the default domain policy, I received several pop-ups: "There is an inconsistency between the GPO Object in SYSVOL and Active Directory. It is recommended to correct this by clicking OK". (Message might be a little different). By clearing the inconsistency problems in the GPO between SYSVOL and Active Directory with the Group Policy Management Console, events 1058 and 1030 were also cleared on all Servers and Clients (about 60).

Adrian Grigorof (Last update 5/25/2007):
The following comments are applicable to this event with "Access denied" as error code for the {31B2F340-016D-11D2-945F-00C04FB984F9} group policy (Default for a domain) on a Windows 2003, SP1 domain controller:
- Verifying the actual GPT.INI file revelead that it was not recently updated
- Trying to update the group policy using the "gpupdate /force" command produced the 1030/1058 events combination. As note, the gpupdate command took very short time to complete returning to the command prompt right away.
- I have verified the permissions on the GPT.INI file and the SYSTEM account had all the right possible to read/modify this file. Based on that I figured that some sort of process keeps the file locked hence the next step
- I followed the suggestions on one of the posts here to flush the the local DFS/MUP cached information. To do that I had to install the Windows 2003 support tools from the installation CD (run the \SUPPORT\TOOLS\SUPTOOLS.MSI). Once installed I ran the following command:
dfsutil /PurgeMupCache
- Following the cache flush I ran again the "gpupdate /force" and the 1030/1058 events were gone. The gpupdate command now took few seconds to complete. In the Application event log event id 1704 ("Security policy in the Group policy objects has been applied successfully.") was recorded.

One thing I noticed is that one has to redo the steps above after every Windows. Something that is reset during restart is affecting the MUP cache and I still have to figure out how to correct this.

* * *

As per M810907 (applicable to Windows XP) this may occur in conjunction with Event id 1030 and it is a confirmed (known) problem with XP. A hotfix is available.

This event is also reported in many instances of upgrades from Windows NT or Windows 2000 to Windows 2003 Server.
Some other recommendations in regards to this (from newsgroup posts) is to verify that:
- DFS service on all DCs is started and set to "Automatic"
- there are no FRS issues - (if there are, toubleshoot those first)
- TCP/IP Netbios Helper service is started and set to "Automatic"
- the "Everyone" has the "bypass traverse checking" user right
on the default domain controller policy
- the antivirus (if installed) is not scanning the sysvol or subfolders, if so, exclude it
- consider that the error description in event id 1058 ("network path not found" or "access denied") is caused by different problems and have different solutions.

Other posts from Microsoft engineer suggest that if a domain controller is multi-homed (more than 1 network card) they may experience this problem (note that "network card" could mean a physical or a virtual one - i.e. VMWare or VPN virtual adapters). The posts also indicate that the Client for Microsoft Networks and the File and Printer Sharing services have to be bound to the network adapter.

See also M307900 on updating Windows 2000 Group Policy for Windows XP.

From a newsgroup post: "I had the 1030 and 1058 errors in the event log every 5 minutes on a W2K3 domain controller that also ran DNS, DHCP, Exchange 2003 Standard, DFS & IIS. After calling Microsoft Tech Support and spending few hours on the phone, the thing that finally got rid of the error messages was reinstalling TCP/IP. This is not a task to be done trivially. My DC was down for about an hour total, so you'll want to make sure you have that much time. M325356 describes how to TCP/IP on a domain controller."

Sometimes it helps to know what is the Group Policy identified by the GUID shown in the actual event message. Here are 2 of them:
- {31B2F340-016D-11D2-945F-00C04FB984F9} - The domain default group policy
- {6AC1786C-016F-11D2-945F-00C04fB984F9} - The "Domain controllers" default group policy

* * *

Reported errors:
Error "Access denied" - For a generic description of such error see the link to Error code 5.
Error "The network path was not found." - See Error code 53.

Jack Brasher (Last update 5/9/2007):
I am running Windows XP Pro SP2 in an SBS 2003 Domain. I tried several options listed in previous comments to resolve this problem with no luck. After reading article M887303, my resolution came from enabling and starting the following 2 services: TCP/IP NetBIOS Helper and the Distributed Transaction Coordinator. After about a minute, policies began processing and the errors disappeared.

Mihai Andrei (Last update 5/3/2007):
This problem occurs when network address translation (NAT) prevents LDAP requests from reaching services on the domain server. See M908370 to fix this problem.

This issue occurs if you use the original release or the April 15, 2003 release of the Rendom.exe utility to rename the domain after you convert a child domain into the root of a domain tree or convert the root of a domain tree into a child domain. See M896983 to solve this problem.

See M935918 and "JSI Tip 8516" for additional information about this event.

Emily Bahgallah (Last update 3/20/2007):
I had this issue also on a Windows 2003 SP1 DC and after reading all the comments here, I decided to reset the password, as that is when the issue started, after an administrator password change. I just changed the password on this DC to the same as it already was and ran a “gpupdate /force” and no more errors.

Matthias Junge (Last update 3/8/2007):
I got the event 1030 and 1058 on a client PC at a remote site, which is connected via a VPN tunnel to our internal network. None of the suggestions has helped me in this case. I solved the problem by allowing NetBIOS traffic through the VPN tunnel. In this case, I have used a router on the remote site to establish the VPN tunnel and I have overlooked the small checkbox ("Allow NetBIOS traffic") that has to be checked. After that, everything worked.

Jon Morrison (Last update 2/28/2007):
I recently resolved this error on a Windows 2003 SP1 DC. There were numerous symptoms including NTFRS failures, host not found errors, inability to open UNC connections to anything on the LAN, and Group Policy being unavailable. The solution turned out to involve re-installation of drivers, clients, protocols and services for the network adapters. The server had two NICs, one of which was normally unused and disabled. By removing all network adapters in device manager and rebooting, I was able to re-detect and install the drivers. I reapplied the static TCP/IP information, Client for Microsoft Networks, and File and Printer Sharing Service. After this, the error messages stopped.

Paul Cocker (Last update 1/4/2007):
The event was occurring in combination with EventID 1030 from source Userenv and was referencing a GPO that existed on the PDC but not on the other site DC, despite this GPO being created the night before. I manually copied the GPO from the PDC Sysvol folder to the DC’s Sysvol folder. The clients were then able to process GPO updates again.

Andy Ferris (Last update 10/12/2006):
This error occured on a Window 2003 Citrix server when users logged in across a citrix session. Applying Microsoft article M314494 by enabling DFS on the server cured it even though it is designed for XP machines.

Kevin Sandbek (Last update 10/4/2006):
In my case, this problem would occur if I took one of my two DCs down. It would only occur on the second DC. I could view \\dcname\anyothershare but not \\dcname\sysvol. Going in the DNS zone config for the zone (WINS tab), only the DC that was down was listed under the "Use WINS forward lookup" option. I added the DC that was still up and this fixed the problem.

Dmitry Akselrod (Last update 9/15/2006):
I had this issue on a Windows 2003 DC. The server has two NICs, one of which is disabled. Opening Network Connections and going to Advanced -> Advanced Setings, I could see the disabled NIC listed first and the enabled NIC second. I changed the order of the NICs and issued a gpupdate /force command. This seems to have solved my problem.

Rolf A. Vaglid (Last update 7/24/2006):
I found event 1058 and 1030 from Userenv after upgrading domain controllers from Windows Server 2000 to Windows Server 2003. I compared the GPO-ID from event 1058 to the GPOs, and found the ID referred to the "Default Domain Policy". GPMC also showed the message "The Enterprise Domain Controllers group does not have read access to this GPO. The Enterprise Domain Controllers group must have read access on all GPOs in the domain in order for Group Policy Modeling to function properly. To learn more about this issue and how you can correct it, click Help".
During domain-upgrade from Windows Server 2000 to 2003, the proper ACLs are not granted on the existing GPOs. To resolve this issue, cd to "\program files\gpmc\scripts" and run "Cscript GrantPermissionOnAllGPOs.wsf "Enterprise Domain Controllers" /Permission:Read /Domain:domain.local". This issue can be avoided during upgrade by using "adprep /domainprep /gpprep" during the domainprep-stage of the domain upgrade.
See JSI tip 8872, M555040, and the link to "Deployment considerations for Group Policy" for details.

Anonymous (Last update 7/19/2006):
I had been having this problem for about a month on both my DCs. Using Group Policy Manager I set all GPOs to "All settings disabled", then did a GPupdate /force on all DCs after replication. I ensured that there are no errors in the event log and then went back and set the GPOs to the same settings they were before. Once again, gpupdate /force.

Rich Stringer (Last update 7/18/2006):
I recently had a 2003 DC start throwing these errors after demoting a W2K box from DC and removing it from the network. Reviewed all the security aspects, checked the other domain controllers (all were as they should be) and narrowed it down to DNS entries. I removed the lingering entries for the old server from DNS and restarted the DNS service. The DC has now run for two days with not a single error.

Anonymous (Last update 7/11/2006):
Check file and printer sharing on the primary NIC. Add them back if you removed them. I also ended up removing my DNS from AD integrated and then returning it into AD integrated. This combination resolved my issues.

Christian (Last update 5/29/2006):
I received this event together with EventID 1030 from source Userenv every 3 to 5 minutes with several DCs when updated from W2k AD to W2k3 AD. We noticed in DNS that the AD-Zone had more than one A-Record for the zone itself with different IP addresses.
We removed all A-Records for the Zone itself (not for the Hosts of the zone) except that with the IP address of the AD-PDC. This solved our problem.

Peter Hayden (Last update 4/11/2006):
Event ID 1030/1058 on a domain controller may indicate that the Group Policy "Digitally sign communications ..." has been set too high. One symptom of this is that you do not have access to the drives of non-domain controllers when you browse the network from some domain controllers.

The Microsoft default settings for the "Default Domain Policy" and "Default Domain Controllers Policy" are:

Console Root
{Group Policy}
Computer Configuration
Software Settings
Windows Settings
Scripts (Startup/Shutdown)
Security Settings
Account Policies
Local Policies
Audit Policy
User Rights Assignment
Security Options
Microsoft network client: Digitally sign communications (always) Not defined
Microsoft network client: Digitally sign communications (if server agrees) enabled Not defined
...
Microsoft network server: Digitally sign communications (always) Not defined
Microsoft network server: Digitally sign communications (if client agrees) Not defined

The Microsoft default settings for the Local Computer Policy for all computers (including those that later are promoted to domain controllers) are:

Console Root
Local Computer Policy
Computer Configuration
Software Settings
Windows Settings
Scripts (Startup/Shutdown)
Security Settings
Account Policies
Local Policies
Audit Policy
User Rights Assignment
Security Options
Microsoft network client: Digitally sign communications (always) Disabled
Microsoft network client: Digitally sign communications (if server agrees) enabled Enabled
...
Microsoft network server: Digitally sign communications (always) Disabled
Microsoft network server: Digitally sign communications (if client agrees) Disabled

To see these settings on a workstation go to Start -> Settings -> Control panel -> Administrative Tools -> Local Security Policy.

To see these settings on a domain controller go to Start -> Run, and enter MMC. Add the Group Policy Object Editor snap-in for the Local Computer.

To restore the domain or domain controllers to the Microsoft default, follow M887303, but create a "Temporary Domain Policy" or a "Temporary Domain Controllers Policy". Disable it (to avoid individual changes locking you out of the Group Policy editor). Move it to the top of the list of Group Policies. Set its security options to Disabled – Enabled – Disabled - Disabled. Enable this Group Policy and allow it to replicate to all computers involved. Set all the Group Policies that are below it in the list to Not defined - Not defined - Not defined - Not defined. Delete the temporary Group Policy.

Sorin Srbu (Last update 12/7/2005):
I decommissioned an obsolete DC and promoted a replacement server. At the same time, I also took the opportunity to deploy a DFS solution for our more-than-irritating-outspread shares, a consolidation if you like.
I did not however consider that most GPOs still pointed to regular server shares (like "\\servername\folder with app to deploy or whatever"). I got many 1030 and 1058 events on the DCs. Using ADSIedit.msc I eventually pinpointed the offending GPOs (corroborating the specific ID code from the 1058 event with the same ID in DC=Domain/CN=System/CN=Policies). Then by choosing properties on the correct GPO I checked what the trivial name ("DisplayName") was and remade that particular GPO in GPMC with pointers using dfs-paths instead. The error stopped within five minutes on the DCs.

Nico Baumgartner (Last update 11/17/2005):
I have had Userenv events 1030 and 1058 after uninstalling the network card team support on an HP Server. Uninstalling both network interfaces and reinstalling them solved the problem for me.

Tony Woods (Last update 11/9/2005):
In our case, we were simply rebooting one of our DCs. When it came back up, the 1030 and 1058 errors were occurring every 5 minutes. Resetting the computer’s password worked for us. From the affected DC, run netdom resetpwd /server:<name of DC> /userd:<domain>\<user id> /passwordd:*.

Ricky Rusland (Last update 11/2/2005):
This error can also occur with McAfee Virus Scan Enterprise 8.0i (VSE). The Access Protection Default rule set prevents remote creation of .ini files and other extensions, thus, the GPO files cannot be updated. Changing the settings for VSE and then changing some of your GPO settings just like Mark Minasi said, will solve it.

Alan Coburn (Last update 10/20/2005):
I got this event, along with EventID 1030, after installing patch KB899587 on a clean build single DC. I removed the patch and i have not received this error since.

Mark Minasi (Last update 10/17/2005):
Looking at the error, it was clearly either a "you-don't-have-a-working-DFS-client" error or a permissions error. Therefore, I checked that I could dir the whole \\domainname\sysvol etc. from the command line. I could, so I assumed that the client worked. So, why the error 5? (Error code 5) Smelled like a permission issue, even though my administrator account could handle it. I checked the Sysvol share permissions, the NTFS permissions, and the GPO permissions. Of course, all were fine. So I said, "what the heck”, and opened up each of the troublesome GPOs. In each case, I changed something, changed it back, and clicked Apply. In other words, I made Active Directory Users and Computers re-write the permission. After this, the problem was solved.

Paul Lockyer (Last update 10/11/2005):
On a couple of multi-homed machines that I was working on I found this problem to be caused by the fact that "File and Printer Sharing" was not bound on what Windows considered to be the primary network adapter. As this was deliberate, I changed the primary adapter and the problem was immediately resolved. See M258296 for information on how to change the binding order of the network adapters so that the adapter that is listed at the top of the Connections list has File and Printer Sharing bound to it.

Steve Johnson (Last update 6/24/2005):
I solved this problem by creating a gpt.ini file at the location where it was trying to find one, and putting a dummy entry in it (on the theory that the software that used this entry either was no longer around, or would "heal" the file, if it could only find it). The contents of the gpt.ini dummy file were:

[General]
Version=0.

Ionut Marin (Last update 3/13/2005):
See M842804 for a hotfix applicable to Microsoft Windows 2000 and Microsoft Windows Server 2003.

See M250842 and M887303, which have information about "troubleshooting group policy application problems".

As per Microsoft: "To work around this issue, you can run the Dfsutil.exe file. At the command prompt, type "dfsutil /PurgeMupCache", and then press ENTER". See M830676 for more details.

As per Microsoft: "These issues may occur when the Distributed File System (DFS) service is stopped on the domain controller". See M834649 for more details.

As per Microsoft: "This behavior occurs if the SMB signing settings for the Workstation service and for the Server service contradict each other. When you configure the domain controller in this way, the Workstation service on the domain controller cannot connect to the domain controller's Sysvol share. Therefore, you cannot start Group Policy snap-ins. Also, if SMB signing policies are set by the default domain controller security policy, the problem affects all the domain controllers on the network. Therefore, Group Policy replication in the Active Directory directory service will fail, and you will not be able to edit Group Policy to undo these settings". See M839499 to fix this problem.

As per Microsoft: "This issue may occur if you have account names that use non-ASCII characters, such as ö and é. Windows 2000 Server and Windows Server 2003 do not distinguish between non-ASCII and ASCII characters in account names". See M883271 for details on this issue.

As per Microsoft: "This issue may occur when a procedure to repair the Group Policy objects (GPO) and the GPO references in the Active Directory directory service on a Windows Small Business Server 2003 computer has not been performed or was not successful. This kind of procedure is typically performed by the original equipment manufacturer (OEM) in a production environment where multiple installations of Windows Small Business Server 2003 are performed". See M888943 to resolve this problem.

From a newsgroup post: "My client’s server was a dual-homed SBS2000 server. The external preferred DNS entry was set to the internal LAN IP. Un-checking the "register this connection with DNS" setting in the external interface did not work (probably because this was a domain controller). This caused the external interface to get registered in DNS, which was being passed down to the clients. To fix this problem I’ve set the external interface to an external DNS server".

From a newsgroup post: "I have begun to receive this error in the event log every 5 minutes. This error message occurred on the only domain controller in the domain. I verified that I could access the SYSVOL folder containing the policies. Whenever I opened Active Directory users and computers, right click on the domain name and click properties, and then click on the group policy tab, an error popped up saying “no domain controllers exist on the network”. My mistake was that I had done several password changes without authenticating. I rebuilt the DC and was very careful with the password until I could build a new EA/SA/DomainAdmin account. Since then, I've not had any problems". See M260930 for information related to this post.

From a newsgroup post: " If your Windows XP computer is a domain member, and the Distributed File System (DFS) client is turned off (disabled), this behavior will occur, because the SYSVOL share requires the DFS client to make a connection. To fix the problem, enable the DFS client:
1.Use the Registry Editor to navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Mup
2.Edit or add Value Name DisableDFS, a REG-DWORD data type. A data value of 0 means that the client is turned on. A data value of 1 disables the client.
3.Press OK and exit the Registry Editor.
4.Verify that File and Printer Sharing for Microsoft Networks is enabled on the interface:
A.Start / Network Connections.
B.Right-click the appropriate connection and press Properties.
C.On the General tab, make sure that File and Printer Sharing for Microsoft Networks is checked.
D.Press OK".

From a newsgroup post: "Here is what you should do to get rid of this error and of Event ID 1058 on Windows Server 2003. Edit the hosts file on each domain controller. Put in the IP address for your domain controller (the local IP address should be first in the list), and then next to the IP address do not put the host name, but put the name of the domain. Then list the IP address for each domain controller in your domain, on the same hosts file (with the domain name next to it). In other words, your hosts file should look like this (if you have just two domain controllers):
<IP 1> yourdomainname.com

<IP 2> yourdomainname.com

Where <IP 1> = the IP address of the local domain controller for this hosts file.
Where <IP 2> = the IP address of your other domain controller.

yourdomainname.com = the name of your domain

The list would be reversed (as far as IP address) on the hosts file on the other domain controller. Yes, you need a hosts file on each domain controller".

See M290647 and MSW2KDB for more details on this event.

Richard Righart van Gelder (Last update 2/9/2005):
This error started on Monday after rebooting our SBS2003 server. I tried "DSFUTIL / PurgeMupCache" to solve this problem but it did not help. I discovered that “\\server\netlogon” was no longer available. I found out by examining a backup session that "C:\WINNT\SYSVOL\sysvol\DOMAIN.local\" no longer contained the Policies and scripts folder. The policies were restored from a recent GroupPolicyEditor backup and the NETLOGON share were restored from a tape. This has solved my problem.

Anonymous (Last update 1/15/2005):
I had this problem on clients. Somehow the DFS root for the SYSVOL share was pointing to a server other than the domain controller. Setting it back fixed my problem.

Daniel Wilson (Last update 10/5/2004):
On my dual-homed Windows Server 2003, this error started to appear after I had removed “Client for Microsoft Networks” and “File and Print Sharing” from the external NIC. Re-binding them caused the errors to stop.

Klaus Charlier (Last update 9/1/2004):
The events 1030 and 1058 occurred on Windows XP clients trying to logon to a Windows 2000 single PDC. In my case for some reason, the NTFS permissions on the PDC in the subdirectories of “\WINNT\SYSVOL\” have lost all settings but those for Administrators. Replacing the permissions on all subdirectories with those of \WINNT\SYSVOL solved the problem for me.

Martin Schürrer (Last update 8/3/2004):
See the link to “Google Thread”. It helped me to resolve this problem. The TCP/IP NetBIOS Helper service has to be started on the client.

Emanuele P. (Last update 4/30/2004):
In my case, “dfsutil /PurgeMupCache” was able to resolve this problem. See M830676 for more details.

Anonymous (Last update 4/30/2004):
I was able to correct this problem by changing the NIC's Advanced TCPIP\NetBIOS settings from "Enable NetBIOS over TCP/IP" to the new "Default" option in Win2k3. The system must have left this setting alone after the upgrade from Win2k.

Jeff Vandervoort (Last update 4/30/2004):
In our case, the problem was occurring on one Win2k3 DC. In this domain, one part of AD-integrated DNS was not up to date for reasons we have not yet determined at this writing. The DNS "folder" “<ServerName>\Forward Lookup Zones\<ZoneName>\_msdcs” was supposed to include a Name Server (NS) record for each DNS server. It contained only one NS record for a DNS server that no longer existed. When I manually added NS records for the current DNS servers the 1030 & 1058 errors stopped some 6 hours later. The first event after the last 1030/1058 pair following it by 6 minutes was a SceCli 1704 policy refresh. I would speculate that the policy refresh was when the server "discovered" the new DNS records in “_msdcs”.

Tobias Punke (Last update 4/6/2004):
I had this problem when I deactivated the DNS Client service but it was not fixed by simply restarting the DNS Client.
If this error appears on one or more Windows 2003 DCs, the problem is not the DNS Client. The 1058/1030 errors are a result of a wrong DNS query. When a DC wants to load and apply the GPs, it is sending a DNS query against the domain name (e.g. \\mydomain.local\sysvol\policies...). Now comes the bug: the DC is getting the wrong IP adress for the sysvol-Dfs-share hosted on each DC. This IP adress is neither a part of your DC configuration nor a part of your subnet. So in fact, the DC tries to reach a machine which isn't there. As a result, you'll get the 1058 error message ("access denied").
I have tried to hotfix this with M830905 which can be obtained from PSS, but in my case it did not work. Thanks to Walter Russo, he suggested a workaround by adding the IP adresses of each DC to local hosts-file. For example, if you have the domain "mydomain.local" you have to edit the hosts file on each DC as follows:

mydomain.local 10.0.0.1 # local DC
mydomain.local 10.0.0.2 # second DC
mydomain.local 10.0.0.3 # third DC

Make sure that you always mention the local adress first. This method works, because by using the hosts file, the local DNS cache is loading the entries with a non-expiry TTL. So no DNS query will be performed for the "mydomain.local" name.

Anonymous (Last update 4/6/2004):
In my case, DCGPOfix.exe was able to repair this problem.

Maxsl75 (Last update 4/6/2004):
I heard of this error being fixed as follows:
1. Click Start, Run, type "cmd" (without the quotation marks) in the "Open" box, and then press ENTER.
2. At the command prompt, type "dfsutil /PurgeMupCache" (without the quotation marks), and then press ENTER.

Note that dfsutil.exe is included with Windows Server 2003 Support Tools. To install Support Tools, run \\SUPPORT\TOOLS\SUPTOOLS.MSI located on your Windows Server 2003 CD-ROM. You can also extract it
directly from the \\SUPPORT\TOOLS\SUPPORT.CAB cabinet file.

Michael Roper (Last update 12/3/2003):
I started receiving this event along with event ID 1030 from source Userenv, after adding additional IPs to the internal NIC on a dual-homed 2003 server. Even though they seemed to be registered properly, the errors came every five minutes until I eliminated all but one IP for the internal NIC.

RShurer (Last update 11/24/2003):
A restart of the DFS service on the Domain Controllers and on the client has solved the problem.

Scott Truman (Last update 10/1/2003):
I had this problem on a multihomed 2003 server when I removed ''unwanted'' bindings and TCP/IP settings” (Client for Microsoft Networks, File and Printer sharing, netbios, etc) and firewalled the external network interface. Make sure your internal interface with all proper bindings needed for resolution is the first in the network access order list "Network Connections >Advanced>Advanced Settings>Adapters and Bindings".

Alexandr A. Bilyk (Last update 5/14/2003):
This can take place if TCP/IP NetBIOS Helper Service is turned off or set to manual startup.

Alanden (Last update 5/14/2003):
Where the NetBIOS and DFS fixes don't fix the problem, a patch is available from Microsoft that does fix it. Call PSS - no charge. See M810907 link below.

Sean Wallbridge
In the past, I was configuring Domain Controller's in a Windows 2000 domain to have the Distributed File System Services stopped and set to manual until such time as they were needed. This was a recommendation based on services that could be stopped according to Microsoft from some time ago to bring machines to a "only what is required state". We disabled DFS worldwide with Windows 2000, NT and Win98 clients with no issues incurred by this.

However, after a while I discovered I was having all sorts of Group Policy application errors on my Windows XP workstation in my Windows 2000 domain.

Looks like Windows XP speaks quite a bit differently to AD and wants/needs more information (and expects it from DFS shares - \\<domain>.<name>). In fact, from my XP machine, I tried connecting to my domain share (\\<domain>.<name>) and I was told access was denied yet it was available from Win2k machines (event ids 1030 and 1058). So, if you have Windows XP clients or just plain aren't worried about someone cranking up DFS and screwing something up somewhere, plan on leaving DFS enabled again.

Also, while working through this I discovered that besides the already cool "Resultant Set of Policy" MMC snap-in in Windows XP, there is also a "GPUPDATE" command in Windows XP which, when used with the /force switch, will blast computer policy settings to your Windows XP machine immediately.

Joerg Hermanns
I had this problem when I accidentally modified the permissions on the SYSVOL share, so that the client computers were not able to read the group policies and scripts that are stored there.

Tom Holland
As per Microsoft: "This behavior may occur if both of the following conditions are true:
Your Windows XP-based computer is a member of a domain.
-and-
The Microsoft Distributed File System (DFS) client is turned off (disabled).
NOTE: The \\Active Directory Domain Name\Sysvol share is a special share that requires the DFS client to make a connection." See M314494.

**trainingit** · 05-02-2009, 10:00 AM

bạn thử cài Service Pack xem có sửa được lỗi này ko ?

Announcement

Xin giúp đỡ về Windows server 2003

Xin giúp đỡ về Windows server 2003

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment