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: 1058 Source: Userenv
Source
Level
Description
Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=<domain name>,DC=com. The file must be present at the location <\\<domain name>\sysvol\<domain name>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>. (<error description>.). Group Policy processing aborted.
English
This information is only available to
subscribers. An example of English, please!
Concepts to understand
Comments
Every now and then id 1030 and 1058. After a while we discovered that it happened when two network users opened the same Excel file on a network share. All the network shares gone, very slow logon on workstations and server, administrator couldn't edit group policies. every time it happened we had to restart to server. The problem for us turned out to be Symantec EndPoint Security. I installed the latest version, excluded Sysvol and now everything works as it should. Our server is Windows Server 2003 R2 SP2.
I was having this problem on a 2008 DC newly promoted. On the folder of the faulting GPO, right click and select Properties. Under DFS, the active access was the old DC one's. I activated the access on this DC and the problem was fixed.
The netlogon share was ok but not the Sysvol share. I enabled sharing on Sysvol with the necessary permissions. and the problem was fixed.
Ensure that the "TCP/IP NetBIOS Helper Service" is activated. I've struggled with 1058 and 1030 for months, then I discovered that "TCP/IP NetBIOS Helper Service" was disabled. Once enabled, the problem was gone.
I had the same issue of not being able to access anything outside the domain controller (such as \\domain.local\share. It happened after I moved the DC from a Virtual Server to Hyper-V and it received new network card drivers. In the network adapter settings I had to activate the "Client for Microsoft Networks".
Problem occurred with a logon/logoff script. One of two DCs logged 1030 and 1058 errors. The problem was solved by changing the permissions of the group policy for the Authenticated Users group to Everyone to read and apply GPO.
If you are running a Linksys VPN router BEFVP41 V2 it will not allow the GP to update. Setup a soft vpn on the server and it will update, or use a RV016 family.
In my case, I found that the sysvol subfolder {TD1415- etc} had been renamed. I recreated it and the errors went away after a gpupdate /force.
Userenv errors 1058 and 1030 have occurred on one of our two Windows 2003 domain controllers, twice now. Resolved this two months ago and it returned. Has been resolved again. 1058 error lists Access denied as reason.
Followed steps in ME887303, which also refers to ME290647. Step 8 in ME887303 - purging the MUP cache - worked here to resolve the errors both times.
Since this was an Access denied error, I paid particular attention to step 5 and permissions on the sysvol folder and subfolders. I did not follow steps 1c-f of ME290647 for Windows 2003 servers, which describe removing inheritance from parent folder on two subfolders. In our case, there were no other permissions other than those, so these two subfolders would have been left with no permissions at all.
Followed steps in ME887303, which also refers to ME290647. Step 8 in ME887303 - purging the MUP cache - worked here to resolve the errors both times.
Since this was an Access denied error, I paid particular attention to step 5 and permissions on the sysvol folder and subfolders. I did not follow steps 1c-f of ME290647 for Windows 2003 servers, which describe removing inheritance from parent folder on two subfolders. In our case, there were no other permissions other than those, so these two subfolders would have been left with no permissions at all.
Have been getting the Userenv 1058 and 1030 errors on one of two domain controllers each month for the past 4 months. Alternates as to which DC it afflicts. Have followed many suggesstions and articles, but the only thing that has worked is to run the dfsutil /PurgeMUPCache command from the command prompt of the affected DC.
In my case the solution was quite easy. Replmon (from Windows Support Tools) has shown me the two versions of the GPO. One was v2 and the othere v9. I've just copied the newer files from server 1 manually to the sysvol folder of server 2 and suddenly the error message was gone!
Than a gpupdate /force and a ipconfig /flushdns on both servers, and the problem was gone.
Than a gpupdate /force and a ipconfig /flushdns on both servers, and the problem was gone.
Above all else make sure of this, Go to Control Panel > Network connections > Advanced > Advanced settings and make sure that your internal connection has Windows File and Print Share turned on. If not your Group Policy share isn't going to work.
Use the file c:\program files\GPMC\Scripts\DumpGPOInfo.wsf to get the name of the offending GPO:
cscript DumpGPOInfo.wsf {446D667F-A290-47A1-B0DB-390290AB0C25}
Will give the name of the offending GPO. i.e. Install UPHClean.
Go to the Group Policy Management Console and attempt to edit the offending GPO. In my case, I received Unable to locate file. I deleted the GPO, reran GPUdate /force and the 1058/1030 errors went away. I then recreated the original GPO.
cscript DumpGPOInfo.wsf {446D667F-A290-47A1-B0DB-390290AB0C25}
Will give the name of the offending GPO. i.e. Install UPHClean.
Go to the Group Policy Management Console and attempt to edit the offending GPO. In my case, I received Unable to locate file. I deleted the GPO, reran GPUdate /force and the 1058/1030 errors went away. I then recreated the original GPO.
Our event ID 1030 and 1058 issues were caused by the downandup virus. Make sure to check security logs for failure audits.
I was getting this event every 5 minutes on my SBS 2003 DC after I was unable to open/edit several group policy objects. The problem was that I'd changed the domain password complexity requirements and my existing admin password didn't meet them. Once I changed my password to adhere to the requirements, the errors stopped and I could edit group policy objects once again.
After using the VMWare converter to virtualize my windows server 2003 R2 domain controller, I was getting errors with event ID 1058 and 1030. I logged on to the machine and saw it needed to be activated. Once I did that the errors stopped.
I had the same errors (1058 and 1030 every five minutes) and the ipconfig /registerdns command worked for me.
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.
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.
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.
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”.
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”.
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 ME840669 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\GpNetworkStartTimeoutPolicyValue = 60.
I rebooted and the errors did not reappear.
For me the fix was to add DWORD value in the registry as per ME840669 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\GpNetworkStartTimeoutPolicyValue = 60.
I rebooted and the errors did not reappear.
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\DisableDFS=0
HKLM\Software\Policies\Microsoft\Windows\NetCache\Enabled=1
HKLM\Software\Microsoft\Windows\CurrentVersion\NetCache\Enabled=1.
3. Kill the mobsync.exe process.
4. Re-initialize CSC cache as explained in Method 1 at ME230738. (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”.
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\DisableDFS=0
HKLM\Software\Policies\Microsoft\Windows\NetCache\Enabled=1
HKLM\Software\Microsoft\Windows\CurrentVersion\NetCache\Enabled=1.
3. Kill the mobsync.exe process.
4. Re-initialize CSC cache as explained in Method 1 at ME230738. (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”.
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.
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.
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 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 ME892777.
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.
Do the following:
-netsh winsock reset
-netsh interface ip reset
-reboot the server
-reconfigure your ip address
-reboot the server.
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".
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.
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.
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).
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 ME810907 (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 ME307900 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. ME325356 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.
- 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 ME810907 (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 ME307900 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. ME325356 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.
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 ME887303, 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.
This problem occurs when network address translation (NAT) prevents LDAP requests from reaching services on the domain server. See ME908370 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 ME896983 to solve this problem.
See ME935918 and WITP81903 for additional information about this event.
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 ME896983 to solve this problem.
See ME935918 and WITP81903 for additional information about this event.
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.
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 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.
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.
This error occurred on a Window 2003 Citrix server when users logged in across a citrix session. Applying Microsoft article ME314494 by enabling DFS on the server cured it even though it is designed for XP machines.
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.
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.
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 WITP82658, ME555040, and the link to "Deployment considerations for Group Policy" for details.
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 WITP82658, ME555040, and the link to "Deployment considerations for Group Policy" for details.
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.
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.
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.
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.
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.
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 ME887303, 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.
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 ME887303, 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.
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.
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.
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.
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:*.
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.
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.
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.
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 ME258296 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.
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.
[General]
Version=0.
See ME842804 for a hotfix applicable to Microsoft Windows 2000 and Microsoft Windows Server 2003.
See ME250842 and ME887303, 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 ME830676 for more details.
As per Microsoft: "These issues may occur when the Distributed File System (DFS) service is stopped on the domain controller". See ME834649 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 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". See ME883271 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 ME888943 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 ME260930 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\Services\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 ME290647 and MSW2KDB for more details on this event.
See ME250842 and ME887303, 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 ME830676 for more details.
As per Microsoft: "These issues may occur when the Distributed File System (DFS) service is stopped on the domain controller". See ME834649 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 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". See ME883271 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 ME888943 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 ME260930 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\Services\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 ME290647 and MSW2KDB for more details on this event.
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.
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.
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.
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.
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.
In my case, “dfsutil /PurgeMupCache” was able to resolve this problem. See ME830676 for more details.
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.
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”.
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 ME830905 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.
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 ME830905 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.
In my case, DCGPOfix.exe was able to repair this problem.
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.
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.
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.
A restart of the DFS service on the Domain Controllers and on the client has solved the problem.
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".
This can take place if TCP/IP NetBIOS Helper Service is turned off or set to manual startup.
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 ME810907 link below.
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.
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.
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.
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.
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.
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.
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.