Friday 31 March 2017

Planning and deploying directory synchronisation for Exchange Online

I've been involved in many directory synchronisation engagements over the past two years and I thought I would put a post out to help people plan their identity strategy when you want to synchronise your on-premises identities and Exchange Online. I felt the need to write this due to the lack of any consolidated information on the topic and other less complete on the matter articles from around the web!

First and foremost, you need an on-premises Exchange Management Server, Microsoft even provide a free key to license it. If you're moving away from on-premises Exchange then this isn't such an issue, but if you're moving to Exchange Online and haven't had Exchange on-premises before this means you need to plan for the deployment of an on-premises Exchange Management Server. Why? You simply won't be able to fully manage your objects in the Exchange Administrative Center in Office 365 with directory synchronisation in place. Instead you add email addresses, or enable external access to distribution lists by making that change on-premises. Directory synchronisation via AADConnect then replicates that change. You can get around it - but you won't be supported!

So when I engage a customer what are the high level actions I check for? Here's my definitive list.

Check if directory synchronisation has been enabled in Office 365
The first is rather easy to check for, you simply check in the Office 365 Admin Centre, if it's already in place then we need to understand if it's actually being used - we can check for synchronised user and group objects, or if it's not in use, understand who's turned it on and where they may have got to. Beware that if you disable directory synchronisation it can take up to 72 hours to disable! I have verified this from disabling the feature in tenants, I have seen anything between 12-60 hours.

Gather data on Active Directory Domain Controller OS Version
So why do we need this? If we plan to utilise features like password synchronisation, and we plan to home the AADConnect agent on a Domain Controller then we need to ensure they are Windows Server 2008 OS or above. Further, it needs to be a writeable Domain Controller, and there's also pre-requisites for features like password write-back. You can see the check list here.

Gather data on Active Directory Domain and Forest functional levels
If we are planning on introducing an Exchange 2016 management server - some bearing on Forest and Domain functional levels will need to be understood.

Password write-back to on-premises only requires DFL/FFL of Windows 2003, but Windows 2008 Domain Controllers with SP2, however if you are planning on having an Exchange 2016 management server with CU3 or later, then you must have DFL/FFL of at least Windows 2008.

This means that you may find you need to upgrade your on-premises Active Directory to get the features you need. This could be as easy as upping your DFL/FFL levels, to having to actually introduce new Domain Controllers to be able to achieve this.

Gather data on Active Directory sites
I gather data on Active Directory sites to help understand the network topology. Where's the best place to house AADConnect? Which location? Where are the most users homed? Does the customer require a staging AADConnect server - if so which location would be the best to home it?

Gather data on Active Directory Unique Principal Name (UPN) utilisation
I see a lot of customers still utilising .local domains, or domains that have no bearing on their actual routable domains in Office 365. The best move forward is to have the on-premises users have the same UPN as the desired sign in for Office 365. So if the user on-premises is oliver.moazzezi@company.local and they have a cloud user account of oliver.moazzezi@company.com, there's a planning excercise here to understand what domains are in Office 365 and what UPN suffixes need to be added to Active Directory. We then plan the change to update on-premises to oliver.moazzezi@company.com

Number of Objects in Active Directory
We gather the number of objects in Active Directory not so much as an excercise for any limits in Azure AD (there's an initial 150k object limit which can be removed for Office 365 subscriptions), but for SQL licensing for AADConnect, if it's over 100,000 objects we need to be looking at using SQL Standard or above - rather than the free version SQL Express version that is auto-installed with AADConnect otherwise.

AD Replication Health
Checking the health of your AD goes without saying - you need a healthy AD without replication issues to ensure all necessary replications occur and are synchronised to Azure AD. Fix and resolve any issues you find! There's no point replicating to Azure AD if your own intersite and/or intrasite replication is broken!

Check for Deployment of Exchange
If the customer is coming from Exchange and migrating to Exchange Online, this isn't so hard to immediately check and ratify. However, what if the customer has come from Notes, Zimbra - or even a hosted exchange platform or resource forest model?

To be in a supported state you need an Exchange Management Server on-premises. Sensibilities dictate this would be an Exchange 2016 or possibly 2013 management server. This will give the customer the best possible experience in a unified UI and Powershell cmdlet experience across both on-premises Exchange and Exchange Online.

One of the things I have encountered countless times is the incorrect removal of Exchange Server from on-premises. One customer had three Exchange 2003 Servers that were simply turned off, removed from the racking and disposed of - and on-premises Exchange was classified as removed. Upon performing discovery, it became clear this needed correct removal - and further investigation showed nearly every long standing employee still logically had a mailbox!

Check Exchange Version
Following on from checking for previous Exchange deployments, it's important to understand the version of Exchange currently on-premises and the steps needed to put an Exchange 2016/2016 Management Server in-place. As well as the previously mentioned similar management experience you also do not have to worry about upgrading the management server anytime soon - where for example if you had an Exchange 2010 management server, this is going to fall out of supportability long before Exchange 2016.

Check for Mailboxes on-premises
Checking for mailboxes on-premises, when all users are known to be in Exchange Online will require clean-up of the on-premises mailboxes prior to implementing directory synchronisation. It can be done afterwards, but it will likely get forgotten about or missed.

Check for Mail Enabled Users
When planning for the Exchange management server, ultimately all your synchronised users will be Mail Enabled users - this is so they show up in the on-premises Exchange Administrative Center and you can easily modify the Exchange attributes - allowing Azure ADConnect to synchronise them to Azure AD and subsequently your EXO tenant.

Check for Mail Enabled Distribution Groups
Are you planning on synchronising your on-premises distribution lists, or will you be utilising Cloud only? Or will you decide to only synchronise certain ones for security management, and implement Office 365 Groups in your Exchange Online deployment?

Most of this comes down to what you understand, or help the customer understand, what they are ultimately trying to achieve. If the customer is already in Exchange Online and you see a completely different set of security and distribution groups on-premises to what's in Office 365 - you may recommend to the client to just synchronise users.

Check Accepted Domains in Office 365
Are all domains verified in Office 365? Is anything unnecessary or incorrect? Ratify the list here as this will have a bearing on what you assign to on-premises.

Check Accepted Domains
When deploying the Exchange management server ensure you understand the Accepted Domains in Office 365 - you'll need to add these in the on-premises deployment so you can easily additional SMTP addresses to objects.

Check if directory synchronisation has been enabled in Office 365
If Directory Synchronisation is already in place, this will allow you to plan clean-up activties or additional actions, or allow you to disable it whilst you made a more solid action plan to perform directory synchronisation for the tenant. Beware it can take up to 72 hours to disable this!

Validate recommended AADConnect server configuration
So what does the customer actually want when synchronising their on-premises identities to Office 365? Does the customer want just object synchronisation? Does the customer want password synchronisation also? You will find most customers will benefit greatly when their on-premises username AND password also accesses their Office 365 resources. A unified password is a must. However understand if your customer has any compliance or regulatory requirements - or just has cold feet about Azure AD holding the password hash for all their user accounts.

If password synchronsation utilising the password hash doesn't work for them - steer them down the route of pass through authentication. This will allow for a unified username and password experience but push the authentication of the user back to their on-premises Domain Controllers. It's a much simpler story to tell and ultimately implement than ADFS.

You can also understand your customers availability requirements, is one AADConnect implementation sufficient or would they also desire a server in 'standby' mode, ready to take over (manually I might add at this stage), if the primary server suffers downtime for an extended period of time or cannot be recovered?

Proxy Server usage
Does the customer force all server traffic through a proxy? If so you need to understand this. Does the proxy for example require authentication? If it does you will have to configure web.config files on the server that will home AADConnect to ensure a succesfull deployment.

IDFix
IDFix is a Microsoft tool that will parse user and group objects and report if they have issues that would require clean-up prior to being able to succesfully synchronise. It will pick up on the aforementioned UPN issue - but it's also good for trailing spaces, or objects with duplicate attributes - for example a UPN or proxy address.

Summary
I hope this goes some way to helping you as a consultant, IT admin or inquisitive Office 365 customer on the steps you should be going through to succesfully deploy directory synchronisation for your on-premises Active Directory and Office 365 tenant.
This should provide you the absolute best and reasoned approach to deploying it, capturing any issues in the planning stages, and providing a nice easy and best practice approach to the deployment.


Have fun!

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Friday 24 March 2017

I want to backport my Azure AD identities to an on-premises AD!

I had this come up in an Office 365 engagement I was involved with in December. The customer was a development start up; creating apps for Android and iOS devices. They had started out as 3 employees but the success of their apps on the respective market places had seen them grow to over 200 employees!
On-premises management of devices was now becoming a serious issue, as the company now saw themselves as having to control their IT.

Now there's a variety of solutions for this. The customer could have decided to keep their identities as cloud users in Azure AD, and utilised Windows Intune for device and application rollout, and Azure AD join Windows 10 devices. However that still presented them with the problem on current on-premises printers and a Linux environment they wanted to integrate into an on-premises AD. So, this presented the problem; how do we backport all identities from Azure AD to an on-premises AD?

1. First of all confirm All domains in Office 365 are set as UPN Suffixes in the on-premises AD, this isn't a problem if you only have one domain, but if your users login to Office 365 with user@domain1.com and user@domain2.com - then ensure this is their UPN in your on- premises AD you have created.


2. Make sure you have some test mailbox enabled users in the tenant – we'll use these to test the back port feature without causing issue to real users. This is performed by using OU filtering when configuring directory synchronisation.



3. Ensure you have extended the Schema for Exchange and installed an Exchange Management Server. Recommended Exchange 2013 or above and the Management Server is in place. Get a free key here: https://support.microsoft.com/en-us/kb/2939261

support.microsoft.com
How to obtain an Exchange Hybrid Edition product key for your on-premises Exchange 2007 or Exchange 2003 organization

Now we have the basics in place, an on-premises AD, users with matching UPNs, an Exchange Management Server and Azure ADConnect (albeit not currently installed), we're ready to start prepping the on-premises AD objects to ensure they get all their Azure AD counterpart attributes! Things like email addresses, general information and location etc

4. Connect to the tenants Azure AD session:

$cred = Get-Credential
$session = New-PSSession -ConfigurationName Microsoft.Exchange -Authentication Basic -ConnectionUri https://outlook.office365.com/powershell-liveid/ -AllowRedirection:$true -Credential $cred
Import-PSSession $session

5. Once connected export all Users, Groups and Contacts:

Get-User -ResultSize Unlimited | Export-Clixml C:\Users.xml
Get-Mailbox -ResultSize Unlimited | Export-Clixml C:\Mailboxes.xml
Get-Recipient -ResultSize Unlimited | Export-Clixml C:\Recipients.xml
$DGs = Get-DistributionGroup -ResultSize Unlimited
$DGs | Export-Clixml C:\DistributionGroups.xml
$DGMembers = foreach ($DG in $DGs) { Get-DistributionGroupMember -Identity $DG.Identity | Select @{Name="Group";Expression={$DG.Name}},PrimarySMTPAddress }
$DGMembers | Export-Clixml C:\DGMembers.xml


6. Now end the Session to Exchange Online by running: Get-PsSession |Remove-PsSession
7. In your Local Active Directory Ensure you have setup your desired OU structure so it is ready and waiting. Select a single OU to ease the ingestion of objects.


8. Create these variables in a local PS session:

$MigrationDomain="domain.local" (where domain.local is the main domain/primary domain they use in Office 365)
$OU="AD domain/OU" (where AD domain = for example oliver.com, and OU is the OU to ingest all objects into)
$Password = ConvertTo-SecureString "Pa$$w0rd" -AsPlainText –Force (this will give ALL users the same password – change it here if you so wish)
$Recipients = Import-CliXML C:\Recipients.xml | Where {$_.WindowsLiveID -like "*@$($MigrationDomain)"}
$Users = Import-CliXML C:\Users.xml | Where {$_.UserPrincipalName -like "*@$($MigrationDomain)"}
$Mailboxes = Import-CliXML C:\Mailboxes.xml | Where{$_.UserPrincipalName -like "*@$($MigrationDomain)"}

We then Import them as 'Mail enabled Users' (this cannot be word wrapped – single command):

$Recipients|where{$_.RecipientType -eq "UserMailbox"}|foreach{New-MailUser -Name:$_.Name -Alias:$_.Alias -SamAccountName:$_.SamAccountName -UserPrincipalName:$_.WindowsLiveID -PrimarySMTPAddress:$_.PrimarySMTPAddress -OrganizationalUnit:$OU ExternalEmailAddress:$_.PrimarySMTPAddress -Password:$Password| Set-MailUser -EmailAddresses:$_.EmailAddresses}





This won't have any good information on them like phone or office location etc. So we add this using, the below, (if there are multiple DCs or Sites wait for replication, or bind to a specific DC):



$Users|foreach{Set-User $_.UserPrincipalName -City:$_.City -Company:$_.Company -Department:$_.Department -Fax:$_.Fax -FirstName:$_.FirstName -Initials:$_.Initials -LastName:$_.LastName -MobilePhone:$_.MobilePhone -Notes:$_.Notes -Office:$_.Office -Phone:$_.Phone -PostalCode:$_.PostalCode -StateOrProvince:$_.StateOrProvince -StreetAddress:$_.StreetAddress -Title:$_.Title}

9. It should at this time have created all the users in the local AD with all relevant company information, phone numbers, details etc. With the caveat they all have the same password. You will need to manage that process yourself (users will have to change themselves - although you could configure password write-back in Office 365 and allow users to change their password either on-premises or Office 365).


10.  READ: At this point we can utilise the test users created in Step 2 to test Active Directory synchronisation. I presume the user knows how to install AADConnect and also to perform OU filtering AND ensure it doesn't sync on initial install. So this is what they will need to do.

11. Move the test users to a test OU.

12. Install AADConnect – ensuring it is not for Hybrid and it is not set to run after install.

13. Go into it and perform OU filtering, select the test OU from step 11 only with the test users in.



14. Perform a sync – see if the users tie up to the accounts in Office 365, you should see them change from 'cloud users' to 'synced with onpremises Active Directory.




15. Login to the Management Server either through Powershell or the EAC – ensure the synchronised users show as 'Mail Users', if they don't it means you missed some - convert them and check their email addresses!

16. Once you're happy perform more ingestion of real users, move the accounts to their correct OUs that you have setup in Step 7 or even earlier. Add OUs into OU filtering as you go.

And that's it! You're all done.

If you decide to synchronise your Distribution Groups (you can leave them cloud only, unless you're planning on using them for security purposes on premises, or prefer synchronisation of groups - or are looking to utilise group write-back capabilities):

1. Set some more variables:
$OU="AD domain/OU"
$DistributionGroups = Import-Clixml c:\DistributionGroups.xml
$DGMembers = Import-Clixml c:\DGMembers.xml

Then:

foreach($DG in $DistributionGroups){$ThisDGMembers=$DGMembers|Where {$_.Group -eq $DG.Name}|%{$_.PrimarySmtpAddress}| New-DistributionGroup -Name:$DG.Name -Alias:$DG.Alias -DisplayName:$DG.DisplayName -PrimarySmtpAddress:$DG.PrimarySmtpAddress -SamAccountName:$DG.SamAccountName OrganizationalUnit $OU Members $ThisDGMembers}


I hope you found this excercise interesting! I did - i'll be pushing out a new post on the pre-requisites you need to meet for directory synchronisation with Exchange Online soon - stay tuned!


Take care,

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi



Microsoft Exchange 2016 Edge on Windows Server 2016

Hey all,

Microsoft have announced they are changing their support policy for Exchange 2016 on Windows Server 2016 today - specifically the Edge role.

You can read more information on the matter here, but for now if you are planning on deploying, or indeed already have Exchange 2016 Edge Servers on Windows Server 2016, you will need to start replacing these with Windows Server 2012 R2 versions.


Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi


Monday 20 March 2017

Requiring your Office 365 data to move to UK datacentre regions

Hey all,

If you are signed up for Office 365 Message Center digests in your Office 365 tenant you should have received the following information:

-------------------------------------------------------------------------------------------------------

Information about moving your data to the United Kingdom datacenter region
MC96864
Published On : 18 March 2017
Expires On : 30 September 2017


Action required by 15 September 2017

Customers with data residency requirements who would like to have their core customer data moved to the UK datacenter region will need to request a move before 15 September 2017. Data moves will complete by 15 September 2019. We recommend that you take no action unless your organization requires core customer data to be stored at rest in the UK datacenter region. By choosing to move your data, customers limit Microsoft's possibilities to optimize the location of their core customer data at rest in either their current or the UK datacenter region.

How does this affect me?
If your organization has a requirement to store core customer data at rest within UK, you will have to request a move via the Office 365 admin center. The deadline for requesting your move is 15 September 2017. Data moves will complete by 15 September 2019. No action is required if you do not have data residency requirements or if you were previously notified of a data move completing. If you do not request to move your data, we may still move your customer data to the UK datacenter region as part of our optimization procedures. In either case, Microsoft will respect the data residency commitments made in the Microsoft Online Services Terms.
                      
What do I need to do to prepare for this change?
You can review the location of your core customer data at rest and request to move your data in the Organization Profile section of the Office 365 admin center. Please click Additional Information to learn more about the move program and instructions to request a move.
                      

Additional information
--------------------------------------------------------------------------------------------------------
Mor information is available at "Moving core data to new Office 365 datacenter regions"

However the general takeaway for this latest Message Center notification is that if you require the move, it must be requested before 15th September 2017. That's 6 months away - so make sure you start the process soon.
Take care,


Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi

Wednesday 15 March 2017

Office 365: The definitive guide!

Well we're into March already and I am happy to announce my latest e-whitepaper; Office 365 the definitive guide. You can download it here!

Head over to grab your copy.

Take care,

Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi