If you have already read ‘Tales from a SharePoint upgrade’ blog series part I and part II, this is part III. One of the more popular upgrade scenarios is upgrading from SharePoint on premise to the Office 365 cloud. This upgrade process can also mean a migration of email systems to Exchange Online, creation of an ADFS architecture, and more.
One of the biggest hurdles in getting users ready for the ‘cloud’ is ensuring your Active Directory user information has all the correct information — especially with large, historical deployments where AD has been in use for a long period of time. I have been using PowerShell to check AD information and alert the AD team of potential changes that need to occur in order for a user to sync to the cloud properly.
Before you get started with any migration to the cloud, it is important to understand and solidify your AD architecture. It is very likely you do not want to have your entire AD structure synced to the cloud. Take some time to determine which OUs you do (and don’t) want synced and the types of users you will need to group together. This is important as Exchange Online has the ability to create dynamic distribution lists and it is very easy to do if users are segregated into distinctive OUs. The following is a good start for OUs when preparing to sync to the cloud:
- Resources
- Employees
- Employees
- Contractors
- Other
- Employees not in O365
- Contractors not in O365
- Other not in O365
This structure gives you the ability to gradually migrate users into the cloud over time as well as prevent any unwanted users from utilizing a O365 cloud license.
The next step is creating a PowerShell script which will verify all users are ready to be synced to the cloud. Here are some key checks to perform on those users to ensure no errors occur:
NOTE: Use the PowerShell Get-ADuser to retrieve this information. An example would be:
$searchOU = “OU=Service Desk Team,OU=User Accounts,DC=corp,DC=tmfhs,DC=org”
$aduser = Get-ADUser -Filter { samaccountname -eq $userADName } -Properties targetAddress, department, samaccountname, userprincipalname, EmailAddress, Enabled, DisplayName -SearchBase $searchOU
- Is User Enabled – this may seem obvious, but it is very common to have users who are disabled in active employee containers. My suggestion would be to move them to a disabled container so they do not sync to the cloud.
- Are they in a synced OU
- Do they have the EmailAddress defined – and is it unique across all users. It is best to match this name to the UPN to keep AD clean and organized. Be sure to remove all spaces and other special characters: “.” and “_” and “-“ are OK to use.
- Do they have a unique UPN – in general this is the loginname into the cloud, Ensure there are no special characters such as apostrophes, etc. This is especially important if migrating to Exchange Online and Lync Online. I have seen issues with apostrophes in login names and users not being able to login to Lync.
- Do they have a unique SamAccountName
- Is the format of the DisplayName consistent across all users – keep this consistent so users know how to search for fellow staff members
- Ensure the minimal information about the users is populated: Description, Title, Company, Location – this is displayed in search results
- Do not put private IT information in the description and notes fields, these columns will sync to the cloud by default and will be displayed in the users profile. Many organizations do this and it isn’t good to show everyone which users have been terminated unexpectedly.
- Add proxyAddresses as appropriate for names with apostrophes (‘), nick names, and other special variations on the email addresses. Make sure the primary email address is prefaced with an SMTP:, while all others use smtp: as follows: SMTP:suzanne.george@perficient.com, smtp:suz_george@perficient.com.
- Verify targetAddress – this should match your email EmailAddress
Other optional items may include:
- If employee photos will not be used initially, consider creating a default photo. This photo is incorporated into all Office 365 products and is better than the grey man default.
- Consider creating a NickName attribute for the user and leave the official FirstName and LastName attributes the users’ official name provided by HR.
- Consider populating the Manager field so SharePoint Online workflows and Org Chart features perform optimally.
Once AD is prepped and ready to go, run a dirsync to the cloud. Here is how to check if the user is in the cloud and activated for any services?
$msoluser = get-msoluser -userprincipalname $upnstr | select-object userprincipalname, displayname, department, isLicensed, `
@{L=’YAMMER_ENTERPRISE’; E={$_.licenses[0].ServiceStatus[0].ProvisioningStatus}},`
@{L=’RMS_S_ENTERPRISE’; E={$_.licenses[0].ServiceStatus[1].ProvisioningStatus}},`
@{L=’OFFICESUBSCRIPTION’; E={$_.licenses[0].ServiceStatus[2].ProvisioningStatus}},`
@{L=’MCOSTANDARD’; E={$_.licenses[0].ServiceStatus[3].ProvisioningStatus}},`
@{L=’SHAREPOINTWAC’; E={$_.licenses[0].ServiceStatus[4].ProvisioningStatus}},`
@{L=’SHAREPOINTENTERPRISE’; E={$_.licenses[0].ServiceStatus[5].ProvisioningStatus}},`
@{L=’EXCHANGE_S_ENTERPRISE’;E={$_.licenses[0].ServiceStatus[6].ProvisioningStatus}}
$isLicensed = $msoluser.isLicensed
$isSPLicensed = $msoluser.SHAREPOINTWAC
$isExLicensed = $msoluser.EXCHANGE_S_ENTERPRISE
I hope this will give you some ideas on how to get your AD ready for a migration to the cloud. As with any project the more planning and preparation time you spend on this activity, the easier your migrations will be. However, with powershell the process becomes much easier and more manageable such that if you don’t get AD cleaned up before the migration, you can catch the errors and successfully sync users during your cloud deployment – and before users have issues connecting to the O365 service.
