Office 365 Transition
Migrating from GroupWise or Notes to Office 365 is similar to on-premises migrations. However, there are some planning, configuration and procedural differences. These include:
Permission and Access
Migration access to Office 365 must be set at the mailbox level through Remote PowerShell. In order to do so, you must first establish a Remote PowerShell session:
1. Open up a PowerShell 2.0 command prompt.
2. Get your Office 365 credentials
$Credential = Get-Credential
3. Create the remote PowerShell session
$Session = New-PSSession -Credential $Credential -AllowRedirection -ConnectionUri https://ps.outlook.com/PowerShell -Authentication Basic -ConfigurationName Microsoft.Exchange
4. Import your PowerShell session
Import-PSSession $Session
NOTE: You may receive an error that says it can't execute a script, if you haven't ever set your ExcecutionPolicy. If this occurs, you may also need to change your execution policy to RemoteSigned.
Set-ExecutionPolicy RemoteSigned
After establishing the session, you can issue commands to Office 365. For example, to establish permissions for the migration admin account(s) to facilitate data migration:
Add-MailboxPermission -User -AccessRights FullAccess
Where is replaced with each migrating user and is replaced with one of the accounts used for migration in the particular environment (see "Throttling and Throughput" for additional information). This command must be run against all migrating mailboxes, so scripting the operation may be beneficial for larger migrations.
Throttling and Throughput
Office 365 introduced new throttling, which impacts migration performance. The throttling is a “per user” limitation that reduces capabilities after more than 2 connections by a single user (including the user).
With previous versions of Exchange Online, migration throughput of 3-5GB/hr/machine or more was common. However, the throttling internal to Office 365 reduces typically throughput to 500MB/hr/machine.
As a result, most Office 365 projects require additional migration machines (or virtual machines) to achieve the desired throughput. In addition, each migration machine should be configured with fewer threads (2-4) and use a separate account. Each machine must have a unique account to bypass the Office 365 throttling and achieve the desired throughput results.
Quest is working directly with the Office 365 team to develop alternates to speed the transition and will provide updates as they become available. However, planning for additional migration machines and accounts is advisable until future notice.
Provisioning and Mailbox Creation
Notes Migrator for Exchange(NME) and GroupWise Migrator for Exchange(GME) will soon include integrated, automated provisioning options for Office 365 (This functionality is included in NME 4.5 scheduled to release in October 2011).
For now, if local Active Directory and Microsoft’s sync tool are not utilized in the environment; the target objects, groups, and mailboxes can be created through PowerShell or the Office 365 portal.
If local Active Directory and Microsoft’s sync tool are present, NME & GME can automate object and group provisioning to the local Active Directory. Then the Microsoft sync tool can provision objects in Office 365 and the mailboxes can be created prior to the migration (via PowerShell or the Office 365 portal).
WinRM ports are 5985/5986 which need to be firewall/proxy-enabled
WinRM must set up to receive requests on NME machine. To manage that:
Office 365 service account username is username@domain.onmicrosoft.com NOT username@targetdomain.com>
You may find more information above by checking this article at Office-365-transition-tidbits
© ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center