Had a nice one this weekend which has led me to try and find out more about Win2k3 SP1.
First of all the story
We upgraded to Win2k3 SP1 on our Exchange servers this weekend, simple enough. Our EV server runs on Win2k3 without SP1 but we thought SP1 on Exchange seemed reasonable.
Well all was OK untill we restarted our Archive/Retrievel services and got a 3077 error which means that we couldn't start any of archive/retrievel services. we know before SP1 was put on Exchange that things worked OK and that our security rights model was correct.
The event text is as follows.
Unable to determine the version of the Exchange server ZSTS124012, the service will shut down Reason: Access Denied
I then went over to the old EV events website just to see what it could tell me. This link might work or might ask you to logon (don't know how you get access to it) http://evevent.veritas.com/EventShowResult.asp?EventNumber=3077
There's lots of info there but the footnote says the following.
This error may occur when starting a service that is connecting to a server running Windows 2003 Service Pack 1. As of 9th May 2005, Windows 2003 Service Pack 1 is not supported and is still being certified. Contact your local support office for the latest information
Anyway, as an idea we added the service account to the Exchange local admin group and then we found we could start our EV services. I can't see why the service account needs these rights, obviously the Exchange rights are correct. We're awaiting a response from support about this problem but at least the workaround works but we just can't find any more supporting info about the Win2k SP1.
The problem in this particular instance is down to the tightening of security in W2k3 SP1. Essentially EV contacts the Service Control Manager to determine the exchange version on service startup.
MS became a bit more stricter in controlling the privilages required when querying the SCM with SP1. (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/service_security_and_access_rights.asp)
Apparently this is supposed to be fixed in V6 SP1 according to support (and I assume V5 SP6 for those still using V5)
I think the last post from Ghost shows the probable cause, thanks for that. Though of course it defies belief that such a simple thing could be missed in the Symantec QA process. Ok, we also let this one slip past our own QA so we'll need to remember to keep vigelent when doing any Exchange server patches or SPs.
Also, just to clarify that this problem was caused by SP1 on the Exchange server and NOT SP1 on the EV server.