julisanto
asked on
setting up new exchange environment and migrate mailbox
Hi All,
i am in need of help here. I have a scenario of 2 Active directory forest.
1. ABC.com
2. 123.com
Both are residing at different country. Now, ABC.com is hosting an exchange server where user from 123.com connects their mailbox all the way to ABC.com
I am going to setup an exchange at 123.com and migrate all the users over from abc to 123.
My plan is to have all users save their email into .PST first.
THen i will create mailbox for them, BUT i want to do it seamless where user feels nothing on the migration (the next day they come into office, they wont be having 2 account / password, when they run outlook, it connects).
My concern here is: when they run outlook, it connects automatically and they can send or receive email using the same email address they used to be.
Can i assume auto discover is the solution for me? if so, what should i set the auto discover URL?
assuming the autodiscover for abc.com is abc.com/autodiscover then what should be the autodiscover for the new exchange server in order to make it seamless and transparent for user?
i am in need of help here. I have a scenario of 2 Active directory forest.
1. ABC.com
2. 123.com
Both are residing at different country. Now, ABC.com is hosting an exchange server where user from 123.com connects their mailbox all the way to ABC.com
I am going to setup an exchange at 123.com and migrate all the users over from abc to 123.
My plan is to have all users save their email into .PST first.
THen i will create mailbox for them, BUT i want to do it seamless where user feels nothing on the migration (the next day they come into office, they wont be having 2 account / password, when they run outlook, it connects).
My concern here is: when they run outlook, it connects automatically and they can send or receive email using the same email address they used to be.
Can i assume auto discover is the solution for me? if so, what should i set the auto discover URL?
assuming the autodiscover for abc.com is abc.com/autodiscover then what should be the autodiscover for the new exchange server in order to make it seamless and transparent for user?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi,
It depends of other parameters of your migration...
As an example, do you plan to make user to log in the new domain ?
If yes they'll loose their user profile and their Outlook Profile and then you may rely on Outlook auto configuration to recreate a profile. But if users had local address book or local PST files they will have to reload them.
But this is not the big part of your problem... If you plan for user to log in the new domain your real problem is to manage Windows user profiles else when they connect with their new account, even if you use same login and password, it is considered as a new user and Windows will create a new user profile, loosing all desktop configuration, outlook profile and other application profiles.
If you don't plan to make user to log in the new domain, then you have to find a way to recreate a new Outlook Profile... And in this case yes you can use any MS tool that can create the Outlook profile. You can not use Outlook auto-configuration because the SCP object in AD will not point to the Exchange Organization in the new forest.
Whatever the way, it's not a so easy job. You'll have to script something, manage synchronization between the mailbox transfer and the Outlook profile rebuild, etc...
It depends of other parameters of your migration...
As an example, do you plan to make user to log in the new domain ?
If yes they'll loose their user profile and their Outlook Profile and then you may rely on Outlook auto configuration to recreate a profile. But if users had local address book or local PST files they will have to reload them.
But this is not the big part of your problem... If you plan for user to log in the new domain your real problem is to manage Windows user profiles else when they connect with their new account, even if you use same login and password, it is considered as a new user and Windows will create a new user profile, loosing all desktop configuration, outlook profile and other application profiles.
If you don't plan to make user to log in the new domain, then you have to find a way to recreate a new Outlook Profile... And in this case yes you can use any MS tool that can create the Outlook profile. You can not use Outlook auto-configuration because the SCP object in AD will not point to the Exchange Organization in the new forest.
Whatever the way, it's not a so easy job. You'll have to script something, manage synchronization between the mailbox transfer and the Outlook profile rebuild, etc...
ASKER
User will remain at their local domain where i am going to configure exchange server locally for them rather than they have to connect to other country that host their exchange server.
Okay,
Then it won't be too difficult in fact.
The outlook auto-configuration should work if you remove the Outlook Profile. As the user account and the mailbox are in the same domain and as the mailbox is attached to the user account the SCP (Service Connection Point) in AD should permit Outlook to locate the server and the mailbox.
If you just remove Outlook profiles (you can do a sort of force removal by just deleting all subkeys under HKCU\Software\Microsoft\Wi
This will not remove the Outlook profile files but Outlook will create new files.
This method is quiet easy but the new profile will not keep any PST file that might be attached to the old profile.
Also, you should delete the .NK2 file if you find it. The .NK2 file contains the addresses cache used by Outlook. The addresses contained in this cache won't match anymore after the mailbox move and the cache will lead to trouble when users will choose recipients from this cache instead of type the full new e-mail address.
Then it won't be too difficult in fact.
The outlook auto-configuration should work if you remove the Outlook Profile. As the user account and the mailbox are in the same domain and as the mailbox is attached to the user account the SCP (Service Connection Point) in AD should permit Outlook to locate the server and the mailbox.
If you just remove Outlook profiles (you can do a sort of force removal by just deleting all subkeys under HKCU\Software\Microsoft\Wi
This will not remove the Outlook profile files but Outlook will create new files.
This method is quiet easy but the new profile will not keep any PST file that might be attached to the old profile.
Also, you should delete the .NK2 file if you find it. The .NK2 file contains the addresses cache used by Outlook. The addresses contained in this cache won't match anymore after the mailbox move and the cache will lead to trouble when users will choose recipients from this cache instead of type the full new e-mail address.
ASKER
Hi PaciB,
i understand your point. the thing is, i am facing a difficult way to make it transparent to user. Management has made a decision where users are not to be disturbed. Maybe it is due to the large number of users, and most of them doesnt understand IT. So i am looking for a way to automate the whole process for end user or else my IT dept will have hard time approaching every single end user.
i understand your point. the thing is, i am facing a difficult way to make it transparent to user. Management has made a decision where users are not to be disturbed. Maybe it is due to the large number of users, and most of them doesnt understand IT. So i am looking for a way to automate the whole process for end user or else my IT dept will have hard time approaching every single end user.
ASKER
sorry for my bad communication way, i do not mean any offend please.. i am just stating my current situation in order to have a solution. :)
Hi,
In your type of migration, be "transparent" is impossible. What you can reach is that user has nothing to configure and just wait for a scripted process to occur and click "OK"... That's the best you can reach, but anyway it requires a lot of preparation.
You probably won't void to script Outlook profile creation. But Outlook profiles are hard to script because all is in the registry, stored in keys that do not have clear names.
What you can imagine (I already did a migration like that, from linux POP mailbox to Exchange) is to write a login script that will be launch by a Group Policy in your domain. The group policy only applies to a group of user. Putting users in that group will make them to execute the login script.
The easiest way is to make the script to remove the existing Outlook profiles. This is not really smart but it's quiet easy.
Then launch Outlook that should auto-configure on the new mailbox. What user will have to do is just to confirm the profile creation in Outlook.
Problems with that way :
1) If user had mount a PST file in its previous Outlook profile the PST file is not mounted in the new profile. The PST file is not lost but it is no more mounted in Outlook and must be mounted manually.
2) If something is worng in the process, as the previous Outlook profiles have been deleted in the registry the user cannot reach is old mailbox anymore and a physical intervention must be done on its computer.
Another possible way, but that requires strong script skills and knowledge of Outlook profiles structure in registry:
This time, the login script reads registry keys to locate the default Outlook profile.
The script then reads the Outlook profile structure to note any PST file that is mounted in the profile and locate PST files paths.
The script may also read the structure to locate any personal address book stored locally and memorize the file path.
Then the script may use some external tool to create an minimum Outlook profile associated to the user mailbox (on Internet you should find a tool called RICHPROFILE).
Finally the script will launch Outlook and automatically mount PST files that has been noted before.
Advantage: the previous Outlook profiles are not deleted. In case of problem in the migration the user can be assisted by phone to open its old Outlook profile.
This sort of script is possible, I already done like that for a Linux to Exchange mailbox migration.
Problems:
1) On shared computers that contains several Outlook profiles, only the default profile can be processed. RICHPROFILE is quiet limited and can not create several profiles.
2) If PST files are password protected the script will fail to mount them.
It may exist some expensive migration tools that may help you to process Outlook profiles. Usually these tools are very very very expensive.
Anyway, your type of migration will require long time preparation and scripting skills.
And, personally in this case I don't believe in Santa Claus and I don't believe in a totally transparent process. Or if this process exists it will cost so much that you will probably think twice about that.
Your problem is that some "management brain" had probably believed he was god and decide "shall it be transparent" ! HAHA ! Ask him to walk on water now...
Have a good day.
In your type of migration, be "transparent" is impossible. What you can reach is that user has nothing to configure and just wait for a scripted process to occur and click "OK"... That's the best you can reach, but anyway it requires a lot of preparation.
You probably won't void to script Outlook profile creation. But Outlook profiles are hard to script because all is in the registry, stored in keys that do not have clear names.
What you can imagine (I already did a migration like that, from linux POP mailbox to Exchange) is to write a login script that will be launch by a Group Policy in your domain. The group policy only applies to a group of user. Putting users in that group will make them to execute the login script.
The easiest way is to make the script to remove the existing Outlook profiles. This is not really smart but it's quiet easy.
Then launch Outlook that should auto-configure on the new mailbox. What user will have to do is just to confirm the profile creation in Outlook.
Problems with that way :
1) If user had mount a PST file in its previous Outlook profile the PST file is not mounted in the new profile. The PST file is not lost but it is no more mounted in Outlook and must be mounted manually.
2) If something is worng in the process, as the previous Outlook profiles have been deleted in the registry the user cannot reach is old mailbox anymore and a physical intervention must be done on its computer.
Another possible way, but that requires strong script skills and knowledge of Outlook profiles structure in registry:
This time, the login script reads registry keys to locate the default Outlook profile.
The script then reads the Outlook profile structure to note any PST file that is mounted in the profile and locate PST files paths.
The script may also read the structure to locate any personal address book stored locally and memorize the file path.
Then the script may use some external tool to create an minimum Outlook profile associated to the user mailbox (on Internet you should find a tool called RICHPROFILE).
Finally the script will launch Outlook and automatically mount PST files that has been noted before.
Advantage: the previous Outlook profiles are not deleted. In case of problem in the migration the user can be assisted by phone to open its old Outlook profile.
This sort of script is possible, I already done like that for a Linux to Exchange mailbox migration.
Problems:
1) On shared computers that contains several Outlook profiles, only the default profile can be processed. RICHPROFILE is quiet limited and can not create several profiles.
2) If PST files are password protected the script will fail to mount them.
It may exist some expensive migration tools that may help you to process Outlook profiles. Usually these tools are very very very expensive.
Anyway, your type of migration will require long time preparation and scripting skills.
And, personally in this case I don't believe in Santa Claus and I don't believe in a totally transparent process. Or if this process exists it will cost so much that you will probably think twice about that.
Your problem is that some "management brain" had probably believed he was god and decide "shall it be transparent" ! HAHA ! Ask him to walk on water now...
Have a good day.
ASKER