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

Parsing input file: F:\zap.ini
Processing input file

Processing mailbox: /o=cndomain/ou=Exchange Administrative Group (FYDIBOHF23SPDLT
)/cn=Recipients/cn=1a662457e14345e8a4e2fdabad35e8e8-Smith Jane
Error - Whilst processing mailbox with dn: /o=cndomain/ou=Exchange Administrative
 Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=1a662457e14345e8a4e2fdabad35e8e8-Smith Jane [0x8004011D]

Attached is my DTrace log (sanitized). I would appreciate the help sorting this out.

Is there another way to zap accounts via SQL?

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

     

8 Replies

Sort By
  • Marcde's avatar
    Marcde
    Moderator
    5 years ago

    Hi, 

    this is a common error that comes up in combination with exchange. Are you logged in as the VSA? Can EV archive the mailbox without any issues? Can you execute that script against another mailbox or is it failing for all? Are the archiving tasks working properly?

    You could also try deleting EV properties from the mailbox in question using MFCMAPI. 

    May I ask what you are trying to achieve? There might be another way to get done what you want to do. 

     

    Regards

    Marc

    • TJensen's avatar
      TJensen
      Level 4
      5 years ago

      May I ask what you are trying to achieve? We onboard and offboard contractors and staff augmentatio workers constantly. When someone is done working at my company we move them to an OU where their account gets a policy which archives everything, then we "disable" the account in Exchange which removes the mailbox database. We don't remove the AD object because then we'd have trouble with Sharepoint and other things which are tied into the GUID and we are quite serious about records keeping. Many of these users might come back to work for us later on, like this user. Due to some load balancing and changes in SOP the user's mailbox was created on a different Exchange server than they originally were on. When they were created on a new server they got a new empty archive in EV (they can access the old one through the web, but they want it through Outlook).

      I'm trying to follow the instructions here to remove the empty archive and attach them to the old archive, but failing at the Zap stage. https://www.veritas.com/support/en_US/article.100017155

      Are you logged in as the VSA? Yes

      Can EV archive the mailbox without any issues?Nothing in the mailbox is old enough to archive yet

      Can you execute that script against another mailbox or is it failing for all? the Zap works against some mailboxes, but not others. so for instance, this use has two mailboxes (old and new). the Zap works against the new (empty) one but not against the old.

      Are the archiving tasks working properly? yes, as far as i can tell.

  • ChrisLangevin's avatar
    ChrisLangevin
    Level 6
    5 years ago

    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