Forum Discussion

TJensen's avatar
TJensen
Level 4
5 years ago

EVPM [0x8004011D]

Situation. I'm trying to ZAP acounts due to multiple duplicate archives being created for some users. I've follow the directions so far but I'm getting the following: Creating privileged MAPI sessio...
  • TJensen's avatar
    TJensen
    5 years ago

    This is interesting. The SynchInMigration value was already set to "1", but when re-enabling users (on a different server than originally) they were still getting a new blank archive instead of re-connecting them to their original archive.

    Going further down the rabbit hole I started comparing the legacyexchangedn value I was zapping to the value in ADSI editor. I found that the values I was pulling from the EV database for the zap were different than the value in ADSI. This article was what I was following to zap, but I was getting the wrong value. https://www.veritas.com/content/support/en_US/article.100016639.html

    This article is essentially what I was trying to accomplish: https://www.veritas.com/support/en_US/article.100019496 but was failing because 1. i couldn't get a good "zap" and 2. there were two entries for each user in the EnterpriseVaultDirectory database table. As long as I wasn't removing both database entries reconnecting the user to the archive, or running a next-next-next enable operation wasn't working.

    Here's the process I had to take to fix the issue:

    1. Identify which archive is blank and delete it

    2. Get the correct legacyexchangedn value from ADSI editor and zap it

    3. Delete both entries for the user in the EnterpriseVaultDirectory database

    4. Run the provisioning task

    5. Run the enable user wizard and select the original archive for the user

    Now that I have the existing users sorted out, I have to figure out why this is happening so I can prevent it with future re-onboarded employees. Thanks for your help everyone.

     

ChrisLangevin's avatar
ChrisLangevin
Level 6

8004011D is a failure of the Exchange Provider. This usually means that the Outlook profile is not set up correctly to connect to the mailbox. Are you able to open this mailbox using Outlook on the EV server while logged in as the VSA? If not, then this will fail too. Check connection protocol, endpoint name, certificate, etc. This dtrace shows you're only zapping this one mailbox; can you zap any others or do they fail too?

You cannot zap a mailbox using SQL because the information we're deleting ("zapping") lives in the Exchange mailbox, not our database. You can delete it using MFCMAPI instead, although it may be tedious to comb through all the folders looking for our filter messages. (Somebody really ought to script that with EWS...)

--Chris

TJensen's avatar
TJensen
Level 4
5 years ago

Are you able to open this mailbox using Outlook on the EV server while logged in as the VSA? Yes

This dtrace shows you're only zapping this one mailbox; can you zap any others or do they fail too? I'm trying to get it right on one user before I move on. I've tried on other affected mailboxes, they consistently fail to allow me to zap on old archives (where theres data) but suceed on new duplicate archives (empty).

  • GertjanA's avatar
    GertjanA
    Moderator
    5 years ago

    Hello,

    To remove the rootcause, you need to set registrykey "SynchInMigrationMode". Set it to 1. See Registry Guide.

    As for the other issue you have. If I recall correct, this has to do with later Exchange versions adding a space to the legacyexchangedn. The other way you can try (although lengthy and needing to use SQL) is the below. I've done this in the past, but have not had the pleasure of using user mailbox archiving for a few years now, so I am not sure my memory serves me right.

    Disable user from archiving. Remove entry for user from ExchangeMailboxEntry table in directory database. Run provisioning. Enable user manually. At enabling, I believe you get the option to assign an archive. Select the 'old' archive.

    I also recall reading somewhere mailbox permissions for the VSA were removed, then set again. This following a check to see if the VSA could open the EVSystemMailbox used in the EVPM command (which failed).

    As last, worth a check, see THIS forum entry. Someone found that using ADSIEDIT there was a

    • GertjanA's avatar
      GertjanA
      Moderator
      5 years ago

      Hello again,

      Are you on EV12.3 (or later) by any chance?

      I just noticed THIS kb, indicating an issue with EVPM in 12.3

      The advise is to "This issue can be worked around by using the 12.1 version of evpm.exe"

      You can contact support to get the 12.1 version of the executable..

    • TJensen's avatar
      TJensen
      Level 4
      5 years ago

      This is interesting. The SynchInMigration value was already set to "1", but when re-enabling users (on a different server than originally) they were still getting a new blank archive instead of re-connecting them to their original archive.

      Going further down the rabbit hole I started comparing the legacyexchangedn value I was zapping to the value in ADSI editor. I found that the values I was pulling from the EV database for the zap were different than the value in ADSI. This article was what I was following to zap, but I was getting the wrong value. https://www.veritas.com/content/support/en_US/article.100016639.html

      This article is essentially what I was trying to accomplish: https://www.veritas.com/support/en_US/article.100019496 but was failing because 1. i couldn't get a good "zap" and 2. there were two entries for each user in the EnterpriseVaultDirectory database table. As long as I wasn't removing both database entries reconnecting the user to the archive, or running a next-next-next enable operation wasn't working.

      Here's the process I had to take to fix the issue:

      1. Identify which archive is blank and delete it

      2. Get the correct legacyexchangedn value from ADSI editor and zap it

      3. Delete both entries for the user in the EnterpriseVaultDirectory database

      4. Run the provisioning task

      5. Run the enable user wizard and select the original archive for the user

      Now that I have the existing users sorted out, I have to figure out why this is happening so I can prevent it with future re-onboarded employees. Thanks for your help everyone.

       

      • GertjanA's avatar
        GertjanA
        Moderator
        5 years ago

        Hello again,

        Good to see you could figure out what was wrong, and thanks for the detailed write up.

        There can be 2 reasons for getting duplicate archives. Mailbox moved to a different Exchange server, without SynchInMigrationMode set, or

        User left, mailbox removed, came back, new mailbox, same DN/Email etc.

        Due to the new mailbox, a new LegacyMBXDN will be made, and thus a new archive.. You might need to test using the Synch key, or enable them manually, and assign the old archive.

        There is 2 additional KB's:

        This and This2