close

Migration

Migration

Migrating Azure AD Connect to a New Server

download

For organizations that are using synchronized identities for Office 365, the directory synchronization tool of choice these days is Azure AD Connect. To keep AAD Connect running you may eventually have the need to move it to another server. There are a variety of scenarios where this need arises, for example migrating to a new server provides the opportunity to safely upgrade to a newer underlying operating system without the risk of a lengthy outage.

For this demonstration, I’ll be migrating Azure AD Connect from a Windows Server 2012 R2 server to a newly installed Windows Server 2016 server. The new server has been configured with an IP address on the network, joined to the domain, updated from Windows Update, and is ready to go. Although it is supported to migrate between AAD Connect instances that are not the exact same build, it is recommended to use the same build on both servers so that the same features and options are available on both instances. In my case, the latest available build is already running on the source server.

The steps to migrate Azure AD Connect to a new server are:

  1. Review the configuration of the existing Azure AD Connect instance
  2. Install the new Azure AD Connect instance in staging mode
  3. Compare configurations of the old and new servers
  4. Swtich-over synchronization to the new server
  5. Decommission the old server

Reviewing the Configuration of the Existing AAD Connect Instance

Ideally you will already have a documented configuration for your AAD Connect instance. If you don’t, then you can use the AADConnectConfigDocumenter tool from MIcrosoft to create a HTML document of your existing configuration. Download their latest release and follow the instructions to generate the report.

If you prefer something simpler to look at, open Azure Active Directory Connect on your existing server, and from the Tasks list select View current configuration. This won’t tell you absolutely everything about the server configuration, but it’s a start. You can also choose Customize synchronization options from the Tasks list to see things like the OU filtering that is configured.

Personally, I prefer the HTML report as it contains everything, it’s just a little harder to read.

Install the New AAD Connect Instance in Staging Mode

On the new server that will be hosting the AADConnect instance, download the latest build of the AADConnect installer and launch it to begin the installation process.

At the Express Settings dialog, choose Customize so that you can fully customize the AADConnect install.

As you step through the custom setup you’ll be able to choose the same configuration options as your existing AADConnect instance. At the final stage, check the box to enable staging mode.

Compare Configurations of the Old and New Servers

The AADConnectConfigDocumenter script can compare configuration information from two different AADConnect instances so that you can find any differences and correct them. The documentation explains how to do it, which I’ll briefly summarize here as well.

First, on the old server I run Get-ADSyncServerConfiguration to export the server’s configuration. I’m placing the export files in the \Data\ESPNET\S1DC1 folder (ESPNET is the NETBIOS name of my domain, and S1DC1 is the old server’s name).

Next, I copy the files to the new server, which is named AAD01, and run Get-ADSyncServerConfiguration again, this time placing the export files in the \Data\ESPNET\AAD01 folder.

Next, I edit the AzureADConnectSyncDocumenter.cmd file that is provided with the script, and supply the folder names of the two configurations that I want to compare.

Save the changes and run the file. It takes a few moments to analyze the data.

After the script has finished running, you’ll find the HTML report in the \Report folder. Open the report in a web browser and review it for any differences between the two configurations, which will be highlighted like the examples below.

Correct any configuration differences (other than obvious ones like staging mode being enabled/disabled), then you’ll be ready to switch-over synchronization duties to the new AADConnect instance.

Switch-Over Synchronization to the New AADConnect Server

Currently the demonstration environment has the following servers installed with AADConnect:

  • S1DC1 (old server) – Synchronization enabled, staging mode disabled
  • AAD01 (new server) – Synchronization enabled, staging mode enabled

While the two servers are in this state, the new server AAD01 will stay up to date with the latest changes in the on-premises Active Directory and Azure AD. However, it will not export any changes to the directories until staging mode is disabled. Before taking the new server out of staging mode, we first need to place the old server into staging mode so that we don’t have two servers trying to export changes to the directories.

During the switch-over, which is a pretty quick process, there’ll be no synchronization of changes between directories. This might mean a delay in the synchronization of a recent change that one of your administrators made (e.g. a group’s membership) or synchronization of a changed password. Keep in mind though that most changes have a synchronization delay anyway, since the sync schedule runs every 30 minutes. Password changes sync nearly instantaneous though, so that’s got a slightly higher risk of being impacted. To reduce the likelihood of the switch-over impacting someone or something important, you might prefer to schedule the change to occur during a period of low usage in your environment, such as an evening or weekend.

On the old server, launch Azure AD Connect and choose Configure, then from the Tasks list choose Configure staging mode. Click Next, and follow the wizard to authenticate and configure staging mode to be enabled. At the final step you can decide whether to keep synchronization enabled or not, depending on whether you think you might need to switch back to this server again (e.g. if the switch-over is only for DR, testing or site maintenance purposes).

On the new server, launch Azure AD Connect and choose Configure, and again from the Tasks list choose Configure staging mode. Follow the same wizard as before to disable staging mode on the new server, and make sure to start the synchronization process.

Decommission the Old AADConnect Server

When you’re satisfied that the new AADConnect instance is successfully synchronizing your directories, you can decommission the old instance of AADConnect if you no longer have a need for it. The uninstall process can be initiated from the Control Panel in Programs and Features.

When you start the uninstall of Microsoft Azure AD Connect you’ll be prompted to also remove the additional components that were installed on the server for AADConnect, such as SQL instance and the Microsoft Online Services Sign-In Assistant. You can remove them if you no longer have a need for them (e.g. the sign-on assistant is still needed by some PowerShell modules, so if you’re going to keep using the server for admin tasks or scripts, either leave that component alone or reinstall it afterwards).

After the uninstall has finished you can go ahead with any server decommission tasks you need to complete for your environment.

read more
Migration

Migrate Home Drives to OneDrive for Business

download

Click edit button to change this text. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

One of the wins for Office 365 customers who have OneDrive for Business included in their licensing is to migrate users’ personal files to OneDrive.

For files that are stored in home drives on traditional file servers, the reduction in server and storage costs is a benefit. For other personal files stored on local computers, moving the files to OneDrive so that they are safely stored in the cloud is also a benefit.

Generally speaking, OneDrive for Business works well for:

  • “My documents” scenarios
  • Simple sharing of documents between small groups of collaborators
  • Storing data in the cloud where compliance and security can be enforced
  • Syncing files to mobile computers and devices for working offline or remotely

The OneDrive sync client can also synchronize files from SharePoint libraries for offline access to team files. So having it configure and ready to go is useful to end users who travel or work in places with poor connectivity.

In this article I’m going to demonstrate a simple migration scenario for migrating home drives to OneDrive for Business. For the purposes of this demonstration the environment consists of:

  • Office 365 E3 licensed users.
  • Office 2016 (via Office 365 ProPlus) client installations on Windows 10 computers.
  • The “Next Gen Sync Client” (NGSC), also generally referred to as OneDrive.exe, as opposed to the old Groove.exe sync client that has fewer features, slower performance, and less reliability.
  • User home drives located on a file server
  • Folder redirection for Documents and other well known folders to the home drives
Update, June 2018: Known folder moves for OneDrive are now available, starting with Targeted Release customers and rolling out to all customers over the coming months. This capability allows you to move known folders (Documents, Desktop, Pictures, etc)  from users’ computers to OneDrive without using the method demonstrated below.

Reviewing Home Drive Data

OneDrive for Business has some limitations for synchronizing files, which includes things like:

  • Invalid characters in file names (e.g. *, :, ?)
  • Specific strings of characters in file names (e.g. COM1)
  • Specific strings in folder names
  • Maximum of number of documents per library
  • 15GB file size limit
  • Files names or paths with more than 400 characters

Those limitations may change over time, so my list above could be out of date. You should always review the latest information on Microsoft’s support site. There’s a variety of other limits and user experience caveats to be aware of as well.

But for the file limitations, an analysis of the data your planning to migrate would be advisable. This could be as simple as a PowerShell script that recursively scans the file server to look for the issues above. If you qualify for FastTrack support from Microsoft, that service includes analysis and remediation as part of the process (and you can use them for the entire migration, so you don’t need to read this article at all if you don’t want to).

Reviewing OneDrive for Business Admin Settings

The OneDrive for Business Admin portal allows you to control a variety of settings for OneDrive users, such as whether they are able to share content external to the organization, sync with non-domain joined computers, how files can be used from mobile devices, DLP policies, and more. Before you proceed with your OneDrive migration, it’s worth reviewing the settings to make sure they align with your expectations and security policies.

For example, you might consider it necessary to disable sharing of SharePoint and OneDrive content with external users, or limit syncing of files to domain-joined computers only.

Configuring a Group Policy

OneDrive has a Group Policy template available from Microsoft. At one time the GPO template could be downloaded from Microsoft, but right now it is only available by navigating to the %localappdata%\Microsoft\OneDrive\BuildNumber\adm\ folder on a computer that has OneDrive installed. An up to date Windows 10 PC should be sufficient. It’s a bit awkward not being able to simply download the latest GPO directly from Microsoft. Perhaps in future they will add it back to the download center.

The OneDrive GPO can be used to set the default location for the OneDrive folder, among other useful settings. That particular setting, in combination with a standard folder redirection policy, is how I’ll be handling the migration in this environment.

The objective of the Group Policy is to:

  • Create an environment variable representing the OneDrive sync location, so that the variable can be used in the Group Policy folder redirection settings. I’ve used Microsoft’s guidance here. The variable in this example is set to “%userprofile%\OneDrive – Exchange Server Pro”, matching the default path that OneDrive will sync to on the local PC.
  • Create a new folder in the %OneDriveSync% location. This can be achieved with a Group Policy preference.
  • Preventing users from choosing a different OneDrive location on the user’s computer. In previous versions of the GPO template this requires editing the Group Policy template (ADMX file) in the Central Store with your tenant ID. Now the setting can be configured through the Group Policy Management console instead.
  • Apply a new folder redirection policy that directs Documents and other folders to the %OneDriveSync% location instead of the home drive on the file server (the policy will move existing files as well).

When you create a policy and look at the OneDrive settings, nothing is configured by default.

To prevent users from changing the location of their OneDrive, you need to know the tenant ID for your Office 365 tenant. To retrieve your tenant ID, connect to Azure AD with PowerShell and run the Get-AzureADTenantDetail cmdlet.

Once you have the tenant ID you can configure the GPO to prevent users changing the OneDrive sync location on their local PC. Add one or more tenant IDs, and set the value to 1 to prevent the sync location from being changed.

For this environment I’ve placed the OneDrive GPO as a higher priority than the existing folder redirection GPO. I’ve also scoped the OneDrive GPO only to members of the “OneDrive for Business Users” security group, and denied the “Apply” permission for the previous folder redirection GPO for the “OneDrive for Business Users” group. Note that after removing Authenticated Users from the scope of the new policy, you then need to go to the Delegation tab and delegate the “Read” permission for the GPO to Authenticated Users, or you may find it does not process at all.

So in effect this all means I can roll out OneDrive to users by adding them to that security group. There is also some end user communication involved in the whole process. You’ll want to make sure your users are expecting the change so there’s no surprises or confusion.

Something to be aware of is that the folder redirection will overwrite any existing data in the destination location that has the same file name and path. If any of your users have already begun using OneDrive and storing files, you should manually deal with those to avoid conflicts. You can find active OneDrive users in the usage reports in the Office 365 admin portal.

Configuring the OneDrive for Business Sync Client

After the GPO has applied, when the user signs in to OneDrive, it will begin syncing that existing data in the local path to the cloud. For environments without any SCCM or other systems in place to initiate a program running in the context of the user, a workaround is to email the user a link to odopen://, which will trigger the OneDrive client to launch. Since you likely want to send them some login instructions and other general adoption advice for OneDrive, you can simply bundle all that up into a single email.

When the user opens OneDrive they’ll be able to walk through the setup process. You should ensure that the instructions you provide are clear about what they should do at each step of the initial configuration wizard.

Monitoring the Deployment

The initial synchronization of files to OneDrive may have a detrimental impact on your network performance. Monitor your network utilization so that you don’t roll out too many users simultaneously.

You can continue to use the OneDrive usage reports in the Office 365 admin portal to track the adoption of OneDrive by your users.

It’s also possible to quickly pull a report of OneDrive usage by using PowerShell.

 

Completing the Migration

Once you’re satisfied that user home drives have been migrated to OneDrive for Business, you can do a scan of your file server to confirm that the home drives for users are empty, and then start decommissioning those shares so that the storage can be reclaimed. For any users who have not logged on and completed their migration you can manually assist them, or back up their home drive files elsewhere, or even upload the files to their OneDrive in the cloud yourself so that they’re waiting for initial sync to the client.

read more
Migration

PowerShell One-Liner: Summary of Mailbox Move Request Status

download

When you’ve got a lot of mailbox move requests running during an Exchange migration, it’s useful to be able to pull a quick summary of how they’re all going. You can achieve this by piping the Get-MoveRequest cmdlet to the Group-Object cmdlet.

read more
Migration

Methods for Migrating to Office 365

Figure-3-1-Deciding-what-migration-method-to-use

This article is an excerpt from the book “Office 365 for Exchange Professionals”.

Office 365 supports a variety of migration methods that customers can use. The choice of migration method can be influenced by a wide range of factors such as the number of objects involved in the migration, the amount of data to be moved to Office 365, the version of Exchange Server (if any) running on-premises, long-term migration or co-existence requirements, whether the organization uses non-Exchange email servers, and even the budget available to spend on the migration project.

The migration methods that are available are:

  • Cutover migration
  • Staged migration
  • Hybrid configuration
  • IMAP migration
  • Third party migration tools

The best place to start is with the business requirements of the migration project. The business requirements should include factors such as the need to complete the migration by a particular date, whether a back-out option for the migration needs to be included, or whether some email resources will remain on-premises. As you will see when you read through this chapter, each migration method has different benefits and constraints, and they may not all suit the business requirements of the project.

The next items to consider are the technical requirements, as they will often quickly eliminate some of the migration methods and allow the organization to zero in on the approaches that are actually possible for them to use. The diagram below provides an example of the decision making process you can work through based on your technical requirements to understand the available migration methods for your scenario.

Figure 3-1 Deciding what migration method to use

The decision making process begins by asking whether the on-premises environment runs Exchange Server 2003 or 2007. For those environments the next decision point is whether there are more than 2000 mailboxes. Organizations with fewer than 2000 mailboxes are supported for cutover, staged and hybrid migrations, whereas more than 2000 mailboxes are only supported for staged or hybrid migrations.

Real World: Although 2000 mailboxes is the threshold specified by Microsoft in terms of support for cutover migrations, it doesn’t mean that organizations with up to 2000 mailboxes should only consider a cutover migration. The logistics involved in handling an outage for a large number of users, as well as the desk-side support needed to assist with reconfiguring Outlook profiles and mobile devices after the cutover, may simply make a cutover migration too risky and complex for the organization. In fact, many experienced Office 365 consultants consider the practical limits of both the cutover and staged migration methods to be more like 150 mailboxes. Organizations larger than 150 mailboxes should give strong consideration to using a hybrid migration instead of a cutover or staged migration.

The 2000 mailbox limit doesn’t mean that organizations with less than 2000 mailboxes should automatically choose a cutover migration. For example, if the organization wants to migrate their users in smaller batches instead of one big batch then a cutover migration would not be suitable.

When cutover is either not possible or not desirable for an Exchange Server 2003/2007 organization the remaining options are staged and hybrid migrations. For an Exchange Server 2003 environment a migration to Exchange Server 2010 needs to be completed first. For an Exchange Server 2007 environment at least one Exchange Server 2010 or 2013 server must be installed in the organization to provide the hybrid functionality. Both options require directory synchronization to be implemented. Without directory synchronization, your migration options are limited to third party tools.

An organization running Exchange 2007 or higher can choose to take advantage of the free “Hybrid Edition” license available from Microsoft. This allows an Exchange Server 2013 or Exchange Server 2010 SP3 server to be deployed in the organization to host a hybrid connection with Office 365. The Hybrid Edition license can’t be used for a server that hosts mailboxes, but the server can be used during the migration to Office 365 and retained afterwards for managing the Exchange attributes of the on-premises Active Directory objects, and can also be used as an SMTP relay server for applications or devices on the corporate network.

If the implementation of a Hybrid Edition server is not possible, for example due to server capacity constraints, then a staged migration is the way forward.

The staged migration method is not available for organizations that run Exchange Server 2010 or 2013. The same 2000 mailbox support limit exists for cutover migrations, so smaller Exchange Server 2010/2013 environments can still choose to perform a cutover migration. However as we’ve already discussed, large cutover migration projects can be logistically very difficult to perform.

Given that Exchange Server 2010 and 2013 are both capable of hybrid configuration with Office 365 you should give strong consideration to hybrid instead of staged or cutover. Although this is the most complex of all of the migration options, it also delivers the best user experience. Hybrid configurations allow the on-premises Exchange organization and Office 365 to function as though they are the same environment with seamless mail flow, a shared address book and calendar free/busy federation. In fact, most users would not even be aware that they are working in a hybrid configuration with mailboxes deployed in both on-premises and Office 365. A hybrid configuration is also the only option that allows mailboxes to be off-boarded from Office 365 to Exchange on-premises without using third party migration tools.

Hybrid configurations rely on directory synchronization. If for some reason the organization can’t implement directory synchronization then the choices are limited to third party migration tools.

Finally, businesses using non-Exchange email platforms can’t use the cutover, staged or hybrid options. For those businesses Microsoft provides an IMAP migration option for moving mailboxes to Office 365, or alternatively a third party migration tool can be used.

As you can see, the decision making process requires careful consideration even just for the technical requirements. Beyond that there are also other factors such as whether the migration project will be handled in-house or by an external consultant, whether extra training is required for IT staff to understand new features such as hybrid configurations, and whether funding is available to pay for third party migration tools if native migration options can’t be used.

Note: Before you finalise your decision on which migration method to use it is strongly recommended that you read through the example migrations in this book from start to finish so that you can learn about any risks or timing issues that you need to be prepared for. Do not start a migration before you have read through the process from start to finish at least once. You should also consider creating a test environment and signing up for a separate Office 365 trial tenant so that you can perform a hands-on test run of your chosen migration method.

read more