Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 1030

Source
Level
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.
Comments
 
We got this on a virtualized domain controller. It came along with event id 1058. The vmware tools were up-to-date. Replacement of the flexible network card with a e1000 nic (reboot, reconfigure network TCP/IP settings, reboot) solved the problem.
These errors were logged alongside event 1006. They were simply there because the user had a suspended session on ther server, and the user had changed their password since logging on to that server.

To fix just logout of that session or login and update your credentials by locking and unlocking the computer.
I haven't given it quite enough time yet, but I may have resolved this by removing some invalid "(same as parent folder)" DNS A records in dnsmgmt under domain, domain\_msdcs\gc, domain\DomainDNSZones, and domain\ForestDNSZones. I tried accessing the GPO in the error by going to \\domain\sysvol\domain\policies\{GPO} and was unable to access  the first time although I could access \\server\sysvol\domain\policies for each of the servers. Running nslookup showed me the extra invalid record for the domain. No other solutions in here had worked yet. This event is also appearing with error 1058 from Userenv. Intermittently, gpupdate was working and logging event 1704 from SceCli showing it was working.
I work for a school district with over 3000+ computers. These errors showed up on (3) computers randomly (2 were older Dell machines and the other was just built from scratch and updated to WinXP SP3). After going through many steps listed here, the web, and elsewhere (i.e. Mark Minasi's support forums - see EV100039), a co-worker decided to change the network card to a new one, and Bingo.....problem solved. I don't really know why this would effect some logons, and not others, but it did work for us.
I fixed this issue by "refreshing" the permissions on the Active Directory policies. Check a box uncheck the same box and apply. During this process I found a GP that was corrupt. I deleted the corrupt AD policy and GP processing started working correctly.


In my case, it turned out that the problem here was the share permission for ''NT AUTHORITY\SYSTEM'' was missing on the SYSVOL share. Added NT AUTHORITY\SYSTEM with ''Full Controll'' permissions and with this, my problem was solved.
We got this on a virtualized domain controller. It came along with event id 1058. In our case, it helped to upgrade VMWare Tools on our virtualized Domain Controller (Win 2003 SP2). The strange thing is, the other DCs - virtualized the same way - do not have this problem. Anyway, this is what fixed the problem here.
This can also occur when the system's disk is full. Look for Userenv event ID 1505. Windows cannot load the user's profile but has logged you on with the default profile for the system. DETAIL - There is not enough space on the disk.
In our case, this event was recorded along with event 11 from KDC on the domain controller. The problem started as we changed the domain administrator password. From that moment our domain controller started logging KDC event 11 stating "there are multiple accounts with name MSSQLSVC/servername:1433 of TYPE DS_SERVICE_PRINCIPAL_NAME". On the affected computer, a SQL server, event id 1030 from Userenv was being recorded, as the server could not authenticate with Kerberos anymore. Editing with ADSI, like described in another comment on this page, and deleting the offending duplicate entry solved the problem.
In many cases, this problem is the effect of from incorrect permissions on the SYSVOL share. Please verify that the following users and groups have the right permissions for the folder shared as SYSVOL (typically this is C:\Windows\Sysvol):

Administrators – Full Control (these are the default, inherited permissions and should be shown grayed out).
Authenticated Users – Read & Execute, List Folder Contents, Read.
Creator Owner – Default inherited permissions only (shown grayed out).
Server Operators – Read & Executed, List Folder Contents, Read.
System – Full Control (inherited permissions and should be shown grayed out).

For the SYSVOL share itself (remember that the permissions for the folder and the ones for the share combine and the most restrictive apply) check:

Administrators – Full Control
Authenticated Users – Full Control
Everyone - Read

If the settings were changed, you need to reset them and then you also need to restore the security settings. To to this, please use the following command:

secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

See ME313222 for more details about the security settings restore.

After these steps are performed, reapply the group policy using:

Gpupdate

Verify in the event log if the group policy was applied successfully.
When combined with 1065 and 9097 errors, check to see if you can run msinfo32.exe, or open wmimgmt.msc and check get into properties at the root level. If you get: WMI: Initialization failure, then try running the following script:

Create a FIXWMI.CMD batch file from the below script and run it and see if this corrects your problem.

FIXWMI.CMD
------------------------

@echo on
cd /d c:\temp
if not exist %windir%\system32\wbem goto TryInstall
cd /d %windir%\system32\wbem
net stop winmgmt
winmgmt /kill
if exist Rep_bak rd Rep_bak /s /q
rename Repository Rep_bak
for %%i in (*.dll) do RegSvr32 -s %%i
for %%i in (*.exe) do call :FixSrv %%i
for %%i in (*.mof, *.mfl) do Mofcomp %%i
net start winmgmt
goto End

:FixSrv
if /I (%1) == (wbemcntl.exe) goto SkipSrv
if /I (%1) == (wbemtest.exe) goto SkipSrv
if /I (%1) == (mofcomp.exe) goto SkipSrv
%1 /RegServer

:SkipSrv
goto End

:TryInstall
if not exist wmicore.exe goto End
wmicore /s
net start winmgmt
:End

This cleared the errors right up.
Thank you Dave Lipman for that fix. :D
This event occurred on a Windows XP client in conjucture with Event ID 1080 and 4356. The problem was that for this particular user Group Policy was not being applied when he logged in, therefore not enabling "My Documents Redirection". Another post regarding Event ID 1030 mentioned that passwords stored in the User Account control panel option, then under Password management could be causing the issue. I found a couple stored Outlook and domain login passwords stored here and deleted them. This fixed the issue in my case.
In my case, the 1030 & 1058 event were fixed by:

1) Change the binding order of the network adapters (ncpa.cpl-advanced-advanced settings), so that the adapter that is listed at the top of the Connections list has File and Printer Sharing bound to it.
2) Make sure File and Printer Sharing for Microsoft Networks checkbox is enabled on the interface.
3) Disable unplugged network adapters if you have more than one adapters in the computers.
4) Run the gpupdate /force command and check the eventlog to see if the errors are gone. You should find an 1704 info about security policy in the GPO applied sucessfully.

This also solved the problem of being able to access the \\servername\sysvol, but unable to access the \\domainname\sysvol.
Also, access to the Domain controller security policy & the Domain security policy MMC snap-in's was restored by this solution.
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.


In my scenario, we transferred FSMO roles to a virtual Windows 2003 Standard Edition server from a Windows 2003 SBS server. The SBS group policies followed. A week later after rebuilding the SBS server as a Windows 2003 Standard Edition server we transferred the FSMO roles from the Virtual server back to the rebuilt server. Again, those annoying SBS policies followed. At that point, we received events 1030 and 1058 every 4 or 5 minutes.  The solution was to delete the SBS policies leaving only the DEFAULT DOMAIN POLICY. Finally, after issuing the GPUPDATE /FORCE command I then noted a single SCECLI event informing me the group policy was successfully applied.
I had the same problem a few weeks ago. First, I received an error message if I tried to log on my DC. The seventh attempted log on was successful. I changed the password of my admin user and after that the log on worked properly.
However, now I had an entry in the event log that there are problems with the GPO-Infrastructure. Marina Roos wrote an article about this failure but did not tell how to solve the problem.
Click Start -> Run and enter "control keymgr.dll". After that, a popup opens and you must delete the stored password entry for your DC on which you are logged on. Click your DC entry and then on Remove. After that try a “gpupdate /force” and have a look in the event viewer after. You should not have the entry with the failure. See also ME555651 for more information.
This event preceded by an Event ID 1006 from the same source can repeatedly appear on a virtual machine. Updating the network driver on the host machine clears up the error.
I encountered this error with EventID 1058 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.
I was receiving event 1030 and 1097 every five minutes on a Windows 2003 DC after a reboot. The issue ended up being caused by the KDC service, which was set to manual and was not started. Once started and set to “Auto” the errors ceased. I found this problem by running dcdiag.exe.
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).
If you receive this event along with event id 1097 from the same source, there may be an issue in the Userenv.dll file. See ME913463 for a hotfix applicable to Microsoft Windows Server 2003.

This problem occurs when network address translation (NAT) prevents LDAP requests from reaching services on the domain server. See ME908370 to solve this problem.

This problem occurs because the Group Policy engine in Windows XP Professional and Windows Server 2003 does not have read permissions to the gPLink and gPOptions attributes of the parent OUs. See ME909260 to solve this problem.

See ME935918, WITP79913 and WITP81903 for additional information about this event.
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.
I corrected this issue for two different customers. Both had recently upgraded their SBS2003 servers from Trend Micro CSM suite 2.0 to 3.0. In each case the affected computers would experience 1006, 1030, 40960 and 40961 errors, as well as having huge connectivity problems to mapped drives and Exchange. The error that tipped me off was the 2022 error, which indicated something about file access. I removed the Trend Micro client software from the server but left the other components (security console, exchange scanner). All problems disappeared immediately thereafter.


This event only occurred when a specific user logged in on a specific XP SP2 machine, together with EventID 40961 from source LsaSrv. The User configuration policy was unable to be applied. If another user logged in on that same machine, no errors appeared and all policies were applied.
It turned out that there was a stored password on the machine when this specific user was logged in. When that was deleted from User accounts Password Management, the errors disappeared and Folder Redirection finally happened for this user.
If you see this in conjunction with an Event ID 1058 from source Userenv on a Windows 2003 server, try going to a command line and running the following command:

netsh winsock reset

This resolved the issue for me. You must reboot the server to complete the reset of the TCP/IP stack.
Error 1030 and error 1006 were showing in the event log. According to a Microsoft engineer, the problem appeared because UDP packets were being dropped when the client workstation was authenticating with the server using Kerberos. We forced Kerberos to use TCP instead of UDP as per article ME244747 and it worked like a charm.

Perform the following troubleshooting steps as per the article:

1. Start Registry Editor.
2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters. Note If the Parameters key does not exist, create it now.
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type MaxPacketSize, and then press ENTER.
5. Double-click MaxPacketSize, type 1 in the Value data box, click to select the Decimal option, and then click OK.
6. Quit Registry Editor.
7. Restart your computer.
As a test on a Windows 2003 SP1 domain controller that was not experiencing this problem, I followed the procedure in ME325356 and it was successful. I would add that it is probably best practice to export any registry key that is about to be deleted to a ".reg" file. In addition, the procedure clears the network configuration, so I recommend doing an "ipconfig /all > ipconfig.txt" to record the network settings in a text file somewhere before starting, so that they can be applied again later.
As per ME810907 (applicable to Windows XP) this may occur in conjunction with Event id 1058 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 ME307900 on updating Windows 2000 Group Policy for Windows XP.

In some other conditions (upgrading to Windows 2003 Server), the 1030 event appears together with event id 1097 from Userenv. From a newsgroup post by a Microsoft engineer: "What is happening is that the TCP/IP Netbios Helper Service is trying to start before the KDC starts upon reboot. It corrects itself. You can safely ignore it. I am trying to get these errors suppressed in a later service pack or hotfix. You can track this running subsequent userenv and netlogon logs. See ME221833 and ME109626."

If this occurs in conjunction with event id 1058 you can work around this issue by using the Dfsutil.exe file - see ME830676.

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. ME325356 describes how to TCP/IP on a domain controller."
I had this issue and was only able to solve it after reading Microsoft article ME555651.
This event can occur on Windows Server 2003 (any service pack) if digital signing of network communications has been disabled in the Local Security Policy of the member server, assuming that the domain is configured to use digital signing (the default setting in Windows Server 2003).
We started to receive this error in the event logs of a new DC for a new domain after rebooting. The server in question has a dual port ethernet card, Intel 1000MT. We created a "Team", two ethernet ports functioning as one, using the Intel PROSet software and Intel drivers. We were also getting the Userenv 1058 error in our event logs. We found that the Intel drivers being used were from the year 2004. We went to the server manufacturer web site looking for updated drivers, but found that the drivers on the website were the same as the ones we had loaded on the server. Went to the Intel web site and downloaded the most recent drivers for the 1000MT. After installing the updated drivers and rebooting, the errors in the event log have ceased to occur.
We encountered this event at approximately 2 hour intervals on one of our Windows 2003 Domain Controllers. At the same time as the 1030 event was generated, a corresponding Event 40960 and 40961 from source LsaSrv was generated in the System Log. Additionally, at the same point in time, an Event 675 entry in the Security Log was generated by the same user whose credentials appeared on the 1030 Event. By checking the Client Address on the security event we traced the issue to a disconnected Remote Desktop session on that Domain Controller. Resetting the disconnected session cleared the issue.


See ME842804 for a hotfix applicable to Microsoft Windows 2000 and Microsoft Windows Server 2003.

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 ME839499 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.
Windows NT 4.0 distinguishes between ASCII and non-ASCII characters in account names. For example, in a Windows NT 4.0-based domain, you can use Administrator and Administratör as separate account names. However, in Active Directory, both Administrator and Administratör effectively have the same logon credentials. This scenario causes the conflict". See ME883271 for details on this issue.

From a newsgroup post: "I connected to the Sysvol share as the current user (non- administrator), and noticed that I could get into "mydomain" directory, but when I tried to get into Policies I received "Access Denied". All of the share/file permissions were correct, allowing this user to get to the share and to traverse/read the files within it. I tracked it down to the fact that I was not allowing read access for Authenticated Users, Everyone, Domain Users, and/or the users Group from the root (C:) to the SYSVOL directory. Once I allowed Everyone, or Authenticated Users, or Domain Users read permissions to from C: -> WINNT -> SYSVOL the users were then able to receive the GPO’s".

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

Also check ME290647, ME832215, ME834649, ME886516, ME887303, ME887421, ME888943, and MSW2KDB for more details on this event.
This happened when I was prompted to change my password, and did, but I stayed logged on to a remote Windows 2003 server with my old credentials. The server locked after the timeout and I left it that way for a couple days. The error stopped when I logged off and logged back on with the new password.
Our XP Clients started showing up these errors in the Application Log after we installed Service Pack 2. There is a corresponding warning EventID 40961 from source LsaSrv in the System log. The problem seems to be related to the background group policy refresh failing if the user has locked the workstation. Setting group policy to prevent lock workstation corrects the problem but a better fix seems to be uninstalling the Client for Microsoft Networks from the NIC, reinstalling it, and rebooting.
I saw this error in my class after one of my students was working on renaming his domain controller. I fixed the problem by running DCGPOFIX on the Win2k3 server followed by a reboot. See the link to “Dcgpofix” for details on this command.
After upgrading from Win2k to Win2k3 I found I was getting this error every 5 minutes in event log along with error 1053. To solve it I had set the following attributes in the Default Domain Controller Policy:
1. Network Access: Let Everyone permissions apply to anonymous users = "Enabled".
2. Network Access: Shares that can be accessed anonymously -> Add SYSVOL to the list. This is because the servers are trying to access the SYSVOL share as LocalSystem which by default does not have access to network resources.
On Windows 2003 I received this error when I disabled TCP/IP NetBios help service. Apparently this has changed since Windows 2000. You can no longer disable this service and have access to Group Policy Objects.
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.
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 ME314494.

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net.

Read more...

 

Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.

Read more...