Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1960
  • Last Modified:

Office 365 Cutover Migration Question

Greetings.  We've been using Directory Sync. with our on-premises Exchange 2010 (SP3) server and Exchange Online Protection.

I understand with a cutover migration that DirSync is not used.

In our "Office 365" portal, there are "user" accounts already created for all mail-enabled users.

In the "Exchange" section of the portal, Recipients, there are no mailboxes created yet.

When we create the first cutover migration batch, will there be a problem creating Exchange user accounts in the cloud because those "user" accounts already exist under "Office 365" ?   We're using a temporary non-Microsoft SPAM filtering solution, so in theory I can delete all those "users" already created.

Thanks much.
-Stephen

OFFICE-365-ADMIN.jpg
Exchange Admin Center tab
0
lapavoni
Asked:
lapavoni
  • 4
  • 4
  • 2
2 Solutions
 
Vasil Michev (MVP)Commented:
The cutover migration process provisions new accounts based on the value of the "WindowsEmailAddress" attribute. If a user with the same address already exists, it will throw an error. So at the end, you might end up deleting those accounts anyway. See for example this thread on the community forums: http://community.office365.com/en-us/f/685/t/188571.aspx
0
 
Sudhir BidyeCommented:
As Vasil Michev said earlier, No need to create user's manually in office 365 as the cutover process itself will provision the mailboxes and groups in office 365 once the sync begins. you just need to ensure that none of the mailboxes or groups are hidden from GAL. If you do not want to migrate any mailbox or group to office 365 then simply hide it in GAL at on premises server.

With regards to performing dirsync with Cutover, I have performed it for few clients and it's successful. Although Microsoft does not have any official guide for it I followed below article and performed Cutover migration with dirsync

You DO NOT NEED to perform step 3 i.e implementing ADFS. Dirsync will work just fine without ADFS.

Article : http://community.office365.com/en-us/w/exchange/835.cutover-exchange-migration-and-single-sign-on.aspx

In short you will have to perform the cutover migration with dirsync in below sequence.

1) Perform Cutover migration. For public folders migrate it using export import method.
2) Convert on-premises mailboxes to mail-enabled users.
3) Activate and install the Directory Synchronization tool.

If your source server is SBS Server then do not install Dirsync tool on SBS server, instead build a new member server for dirsync and install dirsync tool on it.
0
 
lapavoniAuthor Commented:
Good link and explanation, Vasil.  Thank you.

Sudhir, I cannot find any reference to hidden mailboxes not migrating properly.  I did find a reference to hidden Contacts not being seen by Office 365 users.  Do you have any documentation about that ?

http://blogs.technet.com/b/hot/archive/2012/07/31/how-to-unhide-all-hidden-contacts-from-gal-by-using-powershell-script.aspx

Also, as I understand DirSync in this case, it is only used to keep passwords in sync between local AD accounts and their corresponding cloud Office 365 accounts, yes ?  I don't wish to maintain an on-premises Exchange server after migration. I'm OK managing e-mail users from the Office 365 management portal.  There are a few utilities that seem to synchronize passwords fairly well.  This one in particular looks good.  Any experience with these ?

http://www.messageops.com/software/office-365-tools-and-utilities/office-365-password-synchronization/


Thanks much.
-Stephen
0
Veeam Disaster Recovery in Microsoft Azure

Veeam PN for Microsoft Azure is a FREE solution designed to simplify and automate the setup of a DR site in Microsoft Azure using lightweight software-defined networking. It reduces the complexity of VPN deployments and is designed for businesses of ALL sizes.

 
Vasil Michev (MVP)Commented:
Any object that is hidden from the GAL will not be migrated, so you should indeed double-check on that. It's simply the way the cutover wizard works - it connect to your on-prem server and looks at the GAL, then goes over each object listed there.

As for dirsync, it's generally used to reduce the management overhead. If you are fine with managing the users directly from the portal and you are not planning on using password sync or AD FS, you can ignore dirsync. If you want password sync however, you can just stick with the built-in one available in the new version of Dirsync/ADSync, no need for 3rd party tools.
0
 
Sudhir BidyeCommented:
Stephen : Vasil has nicely explained the answers to the questions you asked to me :)
0
 
lapavoniAuthor Commented:
Please let me know if I understand this correctly:  In order to use DirSync, I need to maintain an on-premise Exchange server.  The on-premise "users" are the AD accounts of each user in our organization.  The reference to "mail-enabled users" adds an Office 365 attribute to the local AD accounts.  And DirSync requires a two-way synchronization to do so ?  It seems the only reason to do this is if I had two different types of mail users (local and Office 365) and wanted to maintain an on-premises Exchange server, which I don't wish to do.  There's no need to have proxy addresses copied *down* to my local AD from Office 365. I can see if I wanted to manage users with the existing Exchange 2010 management tools with DirSync and assure that proxy addresses got copied *up* to Office 365, then that would make sense.  It seems like a lot of processes and stuff to keep in place just to have passwords synced from local to the cloud, yes ?
0
 
Vasil Michev (MVP)Commented:
No local exchange server is needed to run dirsync. The information you have read probably related to the fact that removing Exchange can 'strip' any mail related attributes, or the general recommendation to keep at least one Exchange box for ease of management.

Two-way sync is used for Hybrid deployments, no need otherwise (you can refer to this article http://social.technet.microsoft.com/wiki/contents/articles/19901.dirsync-list-of-attributes-that-are-synced-by-the-azure-active-directory-sync-tool.aspx)
0
 
lapavoniAuthor Commented:
OK, two final quick questions that are somewhat related.  We have about 80 user mailboxes with a total of about 500GB of data.  We have a 40Mb/s connection (both up and down).

1. Can a create the migration batch and run it during normal business hours without impacting users too much ?
2. I have the mail server backup running every night using MS Server Backup to an external drive.  Are there any issues with migrating data while the backup is running ?

Thanks much.
-Stephen
0
 
Vasil Michev (MVP)Commented:
During normal business hours you will most likely see slow migration performance, as Exchange Online throttles the connections depending on the load. Here's an article with more details: http://technet.microsoft.com/library/dn592150(v=exchg.150).aspx

As for impacting the users, it really depends on other factors as well. The 'best case' scenario from the article above is 15GB/hour, but it's very unlikely you will be hitting anywhere near that during business hours. Still, to be on the safe side, you can opt for a smaller than the maximum of 100 concurrent migrations (http://technet.microsoft.com/en-us/library/jj874458(v=exchg.150).aspx explains how you can configure that). Or just schedule it over the weekend.

Backup will not be a problem, probably a small drop in performance when it's running, nothing else.
0
 
lapavoniAuthor Commented:
Thank you both for some very helpful information and good links.
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now