Crypt32 Errors In Event Viewer After SEP 11.0 Installation
I am seeing a lot of errors from Source: Crypt32 on my machines after installing SEP 11.0 Agents. We are using SEPM MR4. Is there any connection between the two? Also due to this errors the machines sometimes go into a HUNG state and recover only after a while.
The error that is sown in the Event Viewer is:
Event Type: Error
Event Source: crypt32
Event Category: None
Event ID: 8
Date: 4/25/2009
Time: 4:48:47 PM
User: N/A
Computer: XXXXX
Description:
Failed auto update retrieval of third-party root list sequence number from: <http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt> with error: This network connection does not exist.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Crypt32 Errors In Event Viewer After SEP 11.0 Installation
Hi,
This behavior can occur if the Update Root Certificates component is turned on and the computer cannot connect to the Windows Update server on the Internet. The Update Root Certificates component automatically updates trusted root-certificate authorities from the Microsoft Update server at regular intervals.
The reason why the computer cannot connect to the Windows Update Server might be WRONG PROXY settings. SEP makes uses of the SYSTEM account for the proxy settings which are taking from a different registry keys.
Now to take care of this issue Please do the following :-
- Allow the computer to connect to the Windows Update Server
- Set up the right PROXY settings for the SYSTEM account
- Follow MS KB http://support.microsoft.com/kb/317541/en-us:
* In the SEPM server run command: proxycfg -u
* Restart IIS
http://support.microsoft.com/kb/317541/en-us
Thanks & Regards
Sandip
Thanks & Regards
Sandip C Sali
Doesnt solve the issue
Hi Sandip
Thanks for the prompt response. But sadly this solution doesnt help resolve the issue. I dont want to remove the UPDATE ROOT CERTIFICATES from the Windows Add Remove, so, i tried the proxy config command, but that didnt help.
When i stop the symantec services this crypt32 errors dont show up, but when i start the symantec services, immediately the errors start popping up. Im sure there is a connection between this error and symantec services. Somewhere Symantec is stopping the Root Certificates from getting updated.
I have seen these in a lot of machines in my network. I am flooded with calls due to this. The impact is that this makes the machine boot up very slowly and sometimes it even takes more than 10 minutes. But when the SEP is disabled, the same machine boots up in minutes.
Please help.
I'm having the same exact
I'm having the same exact problem with crypt32 errors after upgrading from SAV to the latest version of SEP. This definetly is an after affect from the installation of SEP. If I filter the eventlog, I can see that it started right after the installation of SEP.
We use WSUS for our microsoft updates, so I don't know why it even goes to microsoft.com for these updates anyway.
We also use a proxy server in our environment.
There's another post on this board that says the crypt errors are possible generated by the PTP scan, because it happens every hour, and that looks to be the case.
I'm sure others are having the same problem, unless maybe your machines have a direct connection to the net?
Re
Please Install Root Certificates Update (rootsupd.exe) from Microsoft
There are a few things to check:
1. Make sure your DNS is set up properly.
2. Make sure the account you are requesting with has the authority to request certificates through the Certification Authority.
3. In my case, I had to go to Add/Remove programs/Windows Components and uncheck Update Root Certificates as per M317541.
4. After all above are good, reboot.
Anyone else have any update
Anyone else have any update on this?
Thanks
Download and update manually
Here is the link for the latest Root Certificate Update.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=f814ec0e-ee7e-435e-99f8-20b44d4531b0
These can be manually downloaded periodically and distributed into your environment if required. You can also setup a WSUS server for the purpose of keeping your network up to date as well. But that's a different topic for a different forum and thread.
**************
To understand the behavior, you need to understand what this update is.
Basically the root Certifcate Update is a list of vendors and distributors that are known to be good- this is the simplest explanation.
For a longer more descriptive look at what these are and how they affect you, you can read this article.
http://www.tech-faq.com/root-certificate-update.shtml
Jason, As I already mentioned
Jason,
As I already mentioned above we use WSUS in our environment.
- This error never came up when SCS was installed. Definetly after SEP was installed.
We do use a proxy in our enivorment. Even if we were to use the solution that Sandip posted above, it still would not work for as our proxy requires authentication.
I just don't understand why this is happening just becuase we upgraded from SAV
I think as long as there is a user logged on (and that user has Internet access thru our proxy) the errors don't happen.
Hi, I also face this problem
Hi,
I also face this problem just after upgrade for SAV10 to SEP11 MR5.
But as bjohn had asked, why this issue happen just because we upgraded from SAV.
Potential Fix
Hi all,
Had the same problem - upgraded from SAV10 to SEP11 MR5 (AV & AS only) and some workstations (but not all weirdly) started getting the crypt32 errors. All my workstations go through an MS ISA proxy.
Rather than muck around with proxy settings or uninstalling automatic root updates on my clients (which seems a bad idea to me anyway) I had a look at the traffic going through my proxy. After allowing unauthenticated HTTP access to the following sites the problematic machines successfully updated their root lists;
*.download.windowsupdate.com
*.update.microsoft.com
*.windowsupdate.com
*.windowsupdate.microsoft.com
download.microsoft.com
download.windowsupdate.com
ntservicepack.microsoft.com
windowsupdate.microsoft.com
wustat.windows.com
Look out for crypt32 events 2 & 7 after a successful update. If you use ISA 2006 there should already be a 'Microsoft Update Domain Name' set for you to use in your access rule.
Why this happens only when SEP11 is installed I don't really know (nor care to be honest) but it looks like this issue has also affected users of McAfee VSE in the past too.
Anyway, I hope this info helps. I'll post back when I'm certain the problem is now solved on my network .
Cheers,
Zinc666
This may me because of the
This may me because of the presence of the firewall which is
present in SEP. Try by installing only AV/AS and see any errors are appearing in
event viewer .
Anyone get this working yet ????
We just upgraded and we are encountering this same issue.
We also use WSUS and authenticaation to internet access.
I have this same CRYPT32
I have this same CRYPT32 error (Event ID: 8) but only on one machine (as far as I can tell thus far). It happens to be on our SEPM Management Console machine. Here is what I have tried thus far to fix it (unsuccessfully):
-- checked that I can access http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt using IE (I can, both with proxy turned OFF and with proxy turned ON, so I seriously doubt its a proxy issue
-- rebooted the server
-- followed Microsoft's KB article advice and ran PROXYCFG -U to ensure that proxy settings were set
-- restarted Cryptographic Services service
-- restarted IIS (and also dependant Symantec Endpoint Protection Manager service)
The error is still occurring, roughly every 11 minutes.
The error started immediately following deployment of the v11.0.5000 SEP client to the server.
The client is configured to run both AV+AS and also NTP.
We do not use SEP's firewall.
OK, it looks like I may have
OK, it looks like I may have solved my issue. Some credit goes to ZINC666 (see above) as I followed his advice regarding proxy rules. Unfortunately I did not keep careful notes on the exact sequence of things that I did. Here's roughly the process:
(1) checked our MS ISA Proxy 2004 setup. I added a new firewall rule which I called "Microsoft Update" and set it so that it allowed traffic from anywhere on my network to the domains listed above (see ZINC666's post). I specifically set it so that it would allow traffic for system services, not just authenticated users
(2) I restarted some services on my affected server: Cryptographic Services, IIS+Symantec, as well as another that I noticed which was the WinHTTP Web Proxy Auto-Discovery Service (not sure if any of that was required, but anyway, that's what I did).
(3) I used the PROXYCFG app to try to turn off use of the proxy by this server (I don't think this worked, but ...)
Now here's an odd thing. The very next time the CRYPT32 process showed into the Event Log on the affected server, it was an error. I was quite discouraged, so I decided to try Diagnostic Logging on the ISA server.
The error had been happening regularly every 11 minutes. So I waited until about 10 seconds before it was due, turned on the logging, waited for the error ... and ... for some reason it then WORKED and did not fail.
I cannot explain this. But it may be that between the first time it failed and the time it worked, the WinHTTP Web Proxy Auto-Discovery Service was stopped. I am not sure. But maybe this will help someone.
After the update worked, I checked the Event Logs on the proxy server and found a few interesting things. At the time the update worked there were event items such as:
-- connected client was not authenticated (I presume this means it was a system service of some kind)
-- the rule Microsoft Update matches the packet. The packet is allowed. (This is the new rule I set up according to ZINC666's list above)
Sorry this is semi-incoherent. But maybe someone can make some sense of it and it may help.
SEP should not force company changes
We are having this same issue, filling our eventlogs with the Event ID 8 Crypt32 error after migrating to SEP 11.0.5.
Since we have hundreds of servers and not all of them are in a/the same domain,
this isn't something we can solve temporarily with a policy by disabling the Root Certificates Update option.
Enabling unauthenticated accounts to connect to a list of websites isn't an enterprise best practice solution.
I did not yet receive a reply on the case I submitted concerning this.
Has anyone else?
I found that if I use
I found that if I use proxycfg to force our proxy server on the system then the issue goes away, and we get a nice "Successful" event rather than the errors.
Still puzzles me why this is the case when our proxies allow all windowsupdate.com and microsoft.com traffic through, it almost seems as if SEP doesn't like direct access? Who knows.
Would you like to reply?
Login or Register to post your comment.