03-10-2015 09:10 AM - edited 10-18-2017 07:14 AM
Hi All,
We have recently split up an EV environment for a customer into 2 mailbox archiving and 2 journal archiving servers.
There are 2 active Exchange Servers and each mailbox archiving server is responsible for one Exchange Server.
Our issue is, when the archiving tasks are all on EV server 1, everything works perfectly.
When we move the migration task for Exchange 2 to EV server 2, everything works except the restore function on these mailboxes (all mailboxes on Exchange server 1, processed by EV server 1 work fine).
There is little given from any logs. In the IIS log we get 503 errors when users attempt to restore and
10/03/2015 10:52:09.212[10616][H]: HTTP request error: 366 (503) 10/03/2015 10:52:09.213[10616][M]: HTTP request error. Enterprise Vault is currently unavailable. Try again later. 503
from the client trace.
It may be also worth noting that all IIS action is happening on EV Server 1 even though the users are being processed by EV Server 2.
Any ideas on where I can go from here?
Cheers
Chay
https://www.mirrorsphere.com/enterprise-vault-services/
Solved! Go to Solution.
09-16-2015 07:14 AM - edited 10-18-2017 07:15 AM
Just to update this. We got it resolved, thanks to Symantec Support.
After running a DTrace against w3wp.exe we could see the lines:
144 10:52:02.311 [9864] (w3wp) <19636> EV:L {VaultCoCreateInstanceEx} CLSID [{3342DB60-B74A-11D1-9E4B-0000F8789EA8}] Server Name [evserver02.domain.com] Used Server Name [evserver02.domain.com] Num of attempts [1] Total elapsed [0.038s] Result [Success (0)]
145 10:52:02.311 [9864] (w3wp) <19636> EV:L {CClientAuthenticate::GenAuthString:#361} Generating auth string...
146 10:52:02.327 [9864] (w3wp) <19636> EV:M ClientAuthHelperImpl::GenAuthString Authentication Type: Currently impersonated user Client:(null) ==> AuthToken:evserver01.domain.com Ql7o*****
147 10:52:02.327 [9864] (w3wp) <19636> EV:M CAutoAgentsOnline::RequestAction - AuthToken [evserver01.domain.com Ql7oF7FIeqw= ?????????????]
148 10:52:02.327 [9864] (w3wp) <19636> EV:L CAuthHelper::Reset Cancel registration? True CancelId: 24941984
149 10:52:02.327 [9864] (w3wp) <19636> EV:M CAutoAgentsOnline::RequestAction - Com Result [0x80070721]
And using a Network Trace we see the following Kerberos Errors:
247 15:01:53 09/09/2015 39.2564935 172.20.2.109 172.20.2.21 KerberosV5 KerberosV5:TGS Request Realm:DOMAIN Sname: evserver01$ {TCP:3082, IPv4:123}
248 15:01:53 09/09/2015 39.2604816 172.20.2.21 172.20.2.109 KerberosV5 KerberosV5:TGS Response Cname: testuser {TCP:3082, IPv4:123}
As such the following technote resolved the issue (even though the resolution was for Discovery Accelerator, the underlying COM / SPN issue was the same.
https://support.symantec.com/en_US/article.TECH144238.html
setspn -A DCOMService/DCOMServer Domain\DCOMServiceAccount
setspn -A DCOMService/DCOMServerFQDN Domain\DCOMServiceAccount
With the DCOMService being EnterpriseVault.ExchangeArchivingAgentQueue as per the CLSID 3342DB60-B74A-11D1-9E4B-0000F8789EA8, which can be traced by finding the entry in regedit.
Once the setspn commands were made, the issue was resolved.
Cheers
03-10-2015 09:57 AM
URL requests will always go to the storage server and not the exchange archiving task server
can you get to http://evserver1/EnterpriseVault/ ok?
can you search and use archive explorer?
03-10-2015 10:22 AM
You're correct, the URL requests are going through the storage server, EVserver1.
I can browse http://evserver1/EnterpriseVault/ and http://evserver2/EnterpriseVault/ fine.
evserver2 appears to be archiving fine and users can retrieve items, it's just the restore.
I have added authenticated users to the permissions of the Shopping location on both servers...
08-24-2015 08:35 AM
Hi Guys,
Still stuck with this. It's true for both manual store / restore when one archive task is talking to the storage service on the other EV server.
I have DCOMs on, Firewall set to allow all, Aunthenticated and IIS_IUSRS granted full permissions on the EV installation files.
There seems to be very little in the way of errors in the event viewer.
Just IIS 503 and client 503 errors.
Oddly, the issue only happens intermittently with no consistency. Sometimes users can be affected for 12 hours sometimes only for 30mins...
Any advise?
Cheers
09-16-2015 07:14 AM - edited 10-18-2017 07:15 AM
Just to update this. We got it resolved, thanks to Symantec Support.
After running a DTrace against w3wp.exe we could see the lines:
144 10:52:02.311 [9864] (w3wp) <19636> EV:L {VaultCoCreateInstanceEx} CLSID [{3342DB60-B74A-11D1-9E4B-0000F8789EA8}] Server Name [evserver02.domain.com] Used Server Name [evserver02.domain.com] Num of attempts [1] Total elapsed [0.038s] Result [Success (0)]
145 10:52:02.311 [9864] (w3wp) <19636> EV:L {CClientAuthenticate::GenAuthString:#361} Generating auth string...
146 10:52:02.327 [9864] (w3wp) <19636> EV:M ClientAuthHelperImpl::GenAuthString Authentication Type: Currently impersonated user Client:(null) ==> AuthToken:evserver01.domain.com Ql7o*****
147 10:52:02.327 [9864] (w3wp) <19636> EV:M CAutoAgentsOnline::RequestAction - AuthToken [evserver01.domain.com Ql7oF7FIeqw= ?????????????]
148 10:52:02.327 [9864] (w3wp) <19636> EV:L CAuthHelper::Reset Cancel registration? True CancelId: 24941984
149 10:52:02.327 [9864] (w3wp) <19636> EV:M CAutoAgentsOnline::RequestAction - Com Result [0x80070721]
And using a Network Trace we see the following Kerberos Errors:
247 15:01:53 09/09/2015 39.2564935 172.20.2.109 172.20.2.21 KerberosV5 KerberosV5:TGS Request Realm:DOMAIN Sname: evserver01$ {TCP:3082, IPv4:123}
248 15:01:53 09/09/2015 39.2604816 172.20.2.21 172.20.2.109 KerberosV5 KerberosV5:TGS Response Cname: testuser {TCP:3082, IPv4:123}
As such the following technote resolved the issue (even though the resolution was for Discovery Accelerator, the underlying COM / SPN issue was the same.
https://support.symantec.com/en_US/article.TECH144238.html
setspn -A DCOMService/DCOMServer Domain\DCOMServiceAccount
setspn -A DCOMService/DCOMServerFQDN Domain\DCOMServiceAccount
With the DCOMService being EnterpriseVault.ExchangeArchivingAgentQueue as per the CLSID 3342DB60-B74A-11D1-9E4B-0000F8789EA8, which can be traced by finding the entry in regedit.
Once the setspn commands were made, the issue was resolved.
Cheers
03-22-2017 06:13 AM
Hello Douglas,
I have the same issue in my environment.
It is not really clear to me, if I have to use in the setspn command the real computername of the EV server or the DNS alias for the EV server.
What does I have to use?
Many Thanks
Michael