09-11-2014 07:47 AM
Hi all,
I just joined a new customer which I will support in the next time. One of my first tasks is to get one of the older Enterprise Vault sites back into action.
So EV did not really work for weeks, if I look into the file system even for months. That's the reason why a big queue of items to process has built up.
I already got backup back to work and different other things. In the last days the CPU consumption was very high but meanwhile it calms down.
Unfortunately not everything is working. So I still got the index of the journaling mailbox failing and I tried to fix it with recommendations from here.
But this is not the point.... at the moment I got so many events popping up, that I'm not quite sure which are worse and which event depends on the other (even if I clear the event log)
I recognized that a lot of items desire to be processed which are not available anymore. For example non-existing users or non-existing archives or renamed users.
Event 3420:
Failed to open mailbox. This mailbox will not be synchronized on this run. The problem may be temporary, in which case the mailbox will be correctly synchronized on the next run.
Task: Exchange Mailbox Archiving Task for WE-EX-MAIL02
Mailbox: ...
Event 3196:
An error has occurred whilst synchronizing the properties of mailbox ... server MAIL02.
Error: There is no such object on the server. (0x80072030)
For both I got multiple entries and they are not existing anymore, one is very interesting. A user called Matt James has been renamed to Matthew James and is existent! As far as I understand Enterprise Vault has no problems with AD renamings. The location is still the same.
So my question is, how can I cleanup these orphaned processing requests?
Running: EV 9.0.3
Thanks in advance.
Kind regards,
woelki
09-11-2014 08:42 AM
you're right about EV not having problems with AD renaming so it's likely to be something else. quickest thing might be to zap the users and then reenable them.
09-12-2014 12:51 AM
Zapping the renamed mailbox is a good idea. I will do that now.
Any ideas regarding the other orphaned requests?
09-12-2014 08:52 AM
have you checked the MSMQs?
09-16-2014 02:48 AM
Yes, looks quite normal.
But I got an idea where these requests come from.
I already worked with the Quest Migration Manager in the past. So the constellation with two forests is familiar to me. But in this case the QMM is not only used for migration, but as a permanent solution.
So we got an old forest with EV9 and E2003 and a new one with EV10 and E2010.
So the EV9 find some users for provisioning, but they are already sitched to E2010 and the E2010 servers are not in the scope of EV9.
I guess this causes a lot of additional events in comparison to a single domain forest.
09-16-2014 07:59 AM
EV only knows about the mailboxes you tell it about via the provisioning groups so make sure that you're not crossing environments. each user should only be targeted by 1 EV environment.