cancel
Showing results for 
Search instead for 
Did you mean: 

Restoring Archived Items Issue when Migrating Archive Tasks

ChayDouglas
Level 4
Partner Accredited

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/

1 ACCEPTED SOLUTION

Accepted Solutions

ChayDouglas
Level 4
Partner Accredited

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

Chay
https://www.mirrorsphere.com/enterprise-vault-services/

View solution in original post

5 REPLIES 5

JesusWept3
Level 6
Partner Accredited Certified

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?

https://www.linkedin.com/in/alex-allen-turl-07370146

ChayDouglas
Level 4
Partner Accredited

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

ChayDouglas
Level 4
Partner Accredited

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

ChayDouglas
Level 4
Partner Accredited

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

Chay
https://www.mirrorsphere.com/enterprise-vault-services/

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