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


Thursday, 2 February 2017

Skype for Business: "There was a problem acquiring a personal certificate required to sign in"


Hello all,

Just another quick one today. I was faced with this error this morning when arriving at my desk and thought I would share the resolution.




Multiple sign in attempts failed, even after restarting the client. After coming across this kb article https://support.microsoft.com/en-us/help/2604176/you-can-t-sign-in-to-skype-for-business-online-because-the-certificate-can-t-be-acquired-or-validated I simply selected 'Delete my sign-in info'.





I was then able to sign in succesfully.


It appears there was cached user sign in credential corruption or possibly an issue or corruption with the certificate - deleting the sign in information resolved the issue.


Take care,

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



Office 365 geo phone number tenant: Your request can't be completed right now. Please try again later.


If you have an Office 365 tenant with Skype for Business with Cloud PBX and PSTN calling you may find that you will be in a scenario where a user gets the following error message:






So what could the problem be is the user is licensed correctly, there's a number to assign to the user and you have a validated emergency location for the required locale?


Well is turns out there are three pieces to this puzzle: You need a validated address for the location, a phone number to assign to the user in the location, and further, the users license location must also match.


So this means the following information must all be aligned:

User license location/locale




Validated emergency location




- and of course a phone number in the correct location. You will find that if you have to change your users license location you may have to wait up to 24 hours before it will work and you won't get the dreaded "Your request can't be completed right now. Please try again later." message.

I have of course asked for a better error message to be displayed, and if you are sure all three of these settings match and it is still not working - raise a case to your advisor or Microsoft support, as you may find the change has not replicated out of Azure Active Directory and into the Skype for Business Forest your Skype tenant resides in. This issue actually affected a tenant I was working with and required Microsoft interaction to resolve the replication issue.


Have a great week!

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






Thursday, 22 September 2016

Validating email addresses for Exchange recipients before migrating to Exchange Online



Recently Exchange Online has added a limit to the number of proxy addresses (email addresses) an object can have (mail enabled user or mailbox for example) in Exchange Online.


This has gone from a seemingly unlimited number to "200".


This poses a problem for any migrations, Hybrid or otherwise, where an on-premises mailbox has more than 200 email addresses assigned to it.


Microsoft has published this limiting change, although buried, here.


So before migrating to Exchange Online it may be wise to check for any recipients that have more than 200 email addresses; you can then resolve the issue and have a better migration experience.




To check:


Get-Recipient | Where {($_.EmailAddresses).count -gt 200}


In the example below I have used 'Get-Mailbox', but this is only to limit the number of returns for this blog post example. The first shows the command, the second shows the command bringing back any mailboxes with email addresses of more than 10, and finally in the third I am getting the all clear as none have over 200.




If you have over 1000 objects don't forget -ResultSize!

Get-Recipient -ResultSize unlimited | Where {($_.EmailAddresses).count -gt 200}



Have a great week!

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




Friday, 9 September 2016

Taking a peek at a UK provisioned Office 365 Tenant

Microsoft announced on the 7th of September that the UK datacentres for Office 365 and Azure services were now available to a great fanfare here and here.


But if you provision a UK tenant (which is as simple as selecting your region as 'United Kingdom' when you sign up - it's not so straight forward on getting an existing tenant moved - more on that in a future blog post soon) what exactly, is in the UK?


From a previous blog post you can see how we can identify the location of the service instances for your Office 365 tenant. So let's take a look!


At first glance it doesn't look much different to a normal 'EU/EMEA' provisioned tenant. But looking further we can see both Exchange Online and SharePoint Online are clearly UK based.





That's all well and good - but services like Exchange Online Protection still show their location as EMEA? Let's dig a little deeper to see if this is true.


Grabbing the MX records for the tenant I can look up the IP addresses against the RIPE database.





Looking on RIPE I can see that in fact, Exchange Online Protection is actually UK based also.





At this time, I haven't been able to confirm the location of Skype for Business Online - i'll update the post when I have dug a little deeper - but we can see your Exchange and SharePoint services are now hosted fully within the UK.

Sorry for the lack of posts for the last two months, I've become a father again and life is a little devoid of spare time (and sleep!) right now!

Update! You can view Microsoft datacentre regions here http://o365datacentermap.azurewebsites.net and it does appears that Skype for Business Online has not made it into the UK datacentres yet. The locales are London and Durham./


Have a a great week!
Oliver Moazzezi – Office Servers and Services MVP
Twitter: @Olivermoazzezi




Thursday, 23 June 2016

Office 365 Enterprise Mobility Suite overview

I don't normally mix work on my personal blog, but here's a webinar I did on Enterprise Mobility Suite with Office 365 which has some great information on the features below.

This covers, Azure AD Premium, Azure RMS Premium, Advanced Threat Analytics and Intune.



Have a a great week!

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

Friday, 29 April 2016

Where are my Office 365 services located?

There’s been a few posts on this over the years, extracting information from Exchange Online for example and deducing the Data Centre locations and what respective rack or server you are on, but I came across this rather neat command the other day that I wanted to share that can give you an overview of all your Office 365 service locations.

Get-MsOlCompanyInformation is a standard Azure AD Powershell module command and mentioned here under MSDN, but the parameter I want doesn’t officially exist as a listed parameter when scrutinising TechNet/MSDN. It states that one of the things it does (in fact it’s the first thing on the list) that it gets “A list of the services for the company”. Interestingly it is mentioned in this Microsoft KB article “Directory Synchronisation for Office 365, Azure, or Intune can’t be activated or deactivated” – I presume so they can find the location of where the tenants service is running from, arming the caller when they phone through to Microsoft for support if there is a continuing issue with their Azure AD instance.

The parameter I am referring to is "AuthorizedServicesInstances", please take the time to read on.

So let’s first take a look at Get-MsOlCompanyInformation and see what it brings back.



You can see it doesn’t state any service location information, let’s see if we can expose anything else

 

An |FL brings back the same information, let’s try Get-MsOlCompanyInformation |select *

 

Aha lots more information that isn’t otherwise exposed by default.

So let’s take a look at those service instances using (Get-MsOlCompanyInformation).AuthorisedServiceInstances

 

You can see above it lists all the services for my tenant and brings insight into their respective locations.

Sway – North America
RMSOnline – in the EU
Yammer – North America
WindowsAzure – EMEA
Exchange Online Protection – EMEA
Microsoft Communications Online (This is Skype for Business Online) – EMEA
Microsoft Office – North America
Sharepoint – this tells us nothing to help us decipher location
Exchange Online – shows us it’s in Europe, we can further disseminate this using EXO powershell should we so wish


We then have a variety of under the hood services, some Access Control Services – all EU based like my tenant is, then BDM, SMIT, Metro and DirectoryToCosmos.


I have to admit DirectoryToCosmos really grabbed my attention, Metro is assumed to be the UI that is delivered to you to access your services, (screen shot below from this tenant). It is essentially the tiles experience and I assume still has its internal legacy name.

 



So back to Cosmos!

It makes sense that all data for an Office 365 tenant is stored somewhere, where else can we get all that good data that allows us to use products like Delve, Delve Analytics or Office 365 Reporting?

Searching the internet there’s a Microsoft Research document that relates to Cosmos, you can read it here, it’s fascinating. It’s the first result returned in Bing when searching ‘Cosmos Reporting’, I suggest searching yourself as other hits are returned.

So Microsoft creates Cosmos for Bing Data and Big Data Analytics. Makes sense right? It appears to be a ground up development for Bing, but has obviously evolved into something much much more.

The good news is that you can consume Cosmos yourself, it’s sold today in Azure as Azure Data Lake, and on that very front page mentions that it is consumed by Office 365 for Big Data and analytics, as well as serving other Microsoft platforms like Xbox Live and Skype among many others.


So what’s SMIT and BDM? No idea, answers on a postcard please, I’ll of course update the blog with any public information that’s available on them.

So want to check where you Office 365 services are located? Simply run in Azure AD Powershell once connected to your tenant (Get-MsOlCompanyInformation).AuthorisedServiceInstances


Have fun,


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