Hello all. I have been playing with EV in the lab since version 6. Went to the class. Now we have version 7 in the lab and in production, with pilot users.
I have gotten pretty comfortable with thing like moving a vault store from one EV server to another.
Our challenge is that our company has offices all over the world in different time zones, and we have to rather quickly deploy EV and ingest years worth of mailbox data and PSTs.
At first we thought that we would just deploy EV to various locations as one big EV site, then later consolidate.
However the sticky point is that PST locator task can exist only on one server in a site. On top of that, the temporary PST Collector/PST Migrator file directory can also exist in one location only. So we can't simultaneously archive Sydney and Toronto - if the PST Collector directory is in Toronto, then we will be pulling gigabytes and gigabytes of Sydney PSTs across the WAN and back.
So then we decided to try deploying multiple EV sites and consolidate them later. We have a test lab that mimics our production environment pretty well. So we installed a new test EV server in a separate site, enabled some test mailboxes and archived data. Then we were able to hack the SQL tables, similar to the procedure used to move a vault store from one server to another, only a little more involved. The only little snag occurred when the user got "lost". It turned out that the user got disabled and we just had to go and re-enable the user account in the target site. Everything else workked pretty smoothly, the user is able to archive new messages and retrieve old archived messages.
So today I was taking another look at the console, clicked on Arhives/Exchange and scrolled down to take a look at the user whose store was moved from one site to the other. And I saw two archives listed for this user, they have exactly the same name, they user exactly the same storage and indexing service, but they have different IDs.
Has anyone here tried to do something like this and what was the outcome?
The first thing that I would say is as soon as you start hacking the SQL database you are putting yourself on a very sticky unsupported wicket!!!!!!
Unfortunately moving a user between vault stores is not as easy as you think and the only supported way of doing this is to export all of the users data to a PST file. Disable the user. Delete the archive. Recreate new archive and import data back into the new archive on the new vault server.
The reason for this is as follows:-
If you have the following:-
User A on VaultA
If you just move the archive to VAULTB with a hack then the vault is still within the vault store on VAULTA which is looked after by the storage service on VAULTA
This means that every time you archive an item the request will start on VAULTB then get passed over to VAULTA and the archiving will take place there.
If you are taking on a big projext like this I cannot recommend that you involve our professional services department at the beginning to stop these sort of issues.
Paul, thank you. I figured it was not supported. But we did manage to marry a vault store from SiteB to the storage and indexing services in SiteA. We also found a way to transfer the provisioning groups and policies from SiteB to SiteA.
So we basically didn't just move a user from one vault store to another vault store, we moved the whole vault store from SiteB to SiteA. There is nothing left in SiteB and everything is working from SiteA. The user whose store was moved from SiteB to SiteA can open previously archived items, and can archive new items. We also monitored the MSMQ traffic and it was all going through the EV server in SiteA only.
But I hear you about trying to get support on this if something goes south.
Message Edited by ANDREY FYODOROV on 08-20-200703:06 PM
Message Edited by ANDREY FYODOROV on 08-20-200703:07 PM