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, I know you have HQ.something.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