Forum Discussion

ChayDouglas's avatar
11 years ago
Solved

Restoring Archived Items Issue when Migrating Archive Tasks

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/

  • 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/

5 Replies

  • 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

  • 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/

    • Mike-J's avatar
      Mike-J
      Level 2

      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