cancel
Showing results for 
Search instead for 
Did you mean: 

EVPM [0x8004011D]

TJensen
Level 4

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?

1 ACCEPTED SOLUTION

Accepted Solutions

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.

 

View solution in original post

8 REPLIES 8

Marcde
Moderator
Moderator
Partner    VIP    Accredited

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

PMCS GmbH & Co. KG - A Serviceware Company
www.serviceware.de

ChrisLangevin
Level 6
Employee

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

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.

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
Moderator
Moderator
Partner    VIP    Accredited Certified

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

Regards. Gertjan

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified

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

Regards. Gertjan

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
Moderator
Moderator
Partner    VIP    Accredited Certified

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

Regards. Gertjan