I recently had to break co-management of SCCM & Intune Co-Management Hybrid and migrate to Intune for mobile devices that were managed by SCCM\Intune.

I followed Gerry Hampson’s blog POST on how to do this. Gerry is a Microsoft MVP in Enterprise Client Management.

I faced a problem. How do I translate an SCCM device collection that has no information on users, to a security group that I can assign an Intune Application Protection Policy to. In my particular instance there was only two policies required.

1. Intune_Exec_AppProtection_Policy
2. All users except the Exec users

Azure Active Directory has the ability to create complex dynamic user or device security groups. So in my instance I created two Intune Application Protection Policies that are listed above.

I created one on-premise synced AD Security group that contained the Exec users, this group would be assigned to Intune Application Protection Policy 1. I then wanted to create a security group that I could assign to all non exec users and any new users. So I created an Azure dynamic user security group that queried Azure AD for any user that has an Intune license. The query for the Azure dynamic security group is listed below.

user.assignedPlans -any (assignedPlan.servicePlanId -eq “c1ec4a95-1f05-45b3-a911-aa3fa01094f5” -and assignedPlan.capabilityStatus -eq “Enabled”)

This type of dynamic security group can be applied to any Microsoft cloud service. The list of all Microsoft servicePlanId’s is available HERE

I have worked recently on a lot of Office365 tenant to tenant migrations and the biggest challenge in all of these migrations is where the same domain name eg. contoso.com cannot exist in two tenants at once.

I always use the Migration Wiz Bundle which can migrate primary mailbox, archive mailbox , ODFB sites and Deployment Pro which manages the Outlook Profile transition to the new tenant.

Migration Wiz have an interesting co-existence solution which you can review HERE

If using a migration tool like Migration Wiz and all data has been migrated a really quick way of removing all traces from contoso.com from the legacy tenant is to run through the following process

WARNING ALL DATA MUST BE MIGRATED BEFORE ATTEMPTING TO USE THIS PROCESS. This process does not delete any data. It removes all references to the public domain that is required in the target tenant in this example that domain name is CONTOSO.COM. If users still need to access data in a Sharepoint Site in the legacy tenant the user me informed on what their new UPN is.

1. Connect to Azure AD Connect server
2. Disable-ADSyncExportDeletionThreshold  and then enter Office365 Global Admin Credentials
3. Next steps are to de-select all the OUs that were previously in scope for synchronization
4. Then run this command on the Start-ADSyncSyncCycle -PolicyType Initial
   (Run the command twice)
5. This will place all objects that were synced to Office365 in the recycle bin.
6. Change UPN for any cloud identity objects that remain
   Get-MsolUser -All | ? {$_.UserPrincipalName -match “contoso.com” -and $_.UserPrincipalName -notmatch “admin”} | % {Set-MsolUserPrincipalName -ObjectId $_.objectId -NewUserPrincipalName ($_.UserPrincipalName.Split(“@”)[0] + “@contoso.onmicrosoft.com”); $dataout += “$($_.UserPrincipalName)” ; $_.UserPrincipalName };$dataout | out-file “CSV FILE NAME AND PATH”}}
7. Set the primary smtp address for all remaining mail enabled objects to contoso.onmicrosoft.com
   $AllMailboxes = Get-Mailbox -ResultSize Unlimited
   Foreach ($Mailbox in $AllMailboxes){
   # Creating NEW E-mail address that concatenate in the following way: Take the existing recipient Alias name + use the NEW Domain name as a domain suffix + “Bind” the Alias name + the NEW Domain name suffix.$NewAddress = $Mailbox.Alias + “@contoso.onmicrosoft.com”Set-Mailbox -Identity $Mailbox.Alias -WindowsEmailAddress $NewAddress 
   }
8. Remove all contoso.com aliases
   $Records = Get-mailbox -ResultSize Unlimited| where {$_.emailaddresses -like “smtp:*@contoso.com”} | Select-Object DisplayName,@{Name=“EmailAddresses”;Expression={$_.EmailAddresses |Where-Object {$_ -like “smtp:*contos.com”}}}foreach ($record in $Records){    write-host “Removing Alias” $record.EmailAddresses “for” $record.DisplayName

       Set-Mailbox $record.DisplayName -EmailAddresses @{Remove=$record.EmailAddresses}

   }

9. Remove Contoso.com from any groups
   Get-Msolgroup -All | where {$_.emailaddress -match “contoso.com”} | Remove-MsolGroup –Force
10. Change the default domain in the Admin.Microsoft.com portal to contoso.onmicrosoft.com
11. Remove Contoso.com
    Remove-MsolDomain -DomainName “contoso.com” –Force
12. Next we can add Contoso.com into the new Office365 tenant and update the mx records for Contoso.com
13. Last but not least , We modify AD Connect configuration and re-enable the sync of all the objects that were previously synced and are now in the Office365 recycle bin ,they will all be restored and have the ability to access their data via a contoso.onmicrosoft.com UPN.

We forgot to mention Public Folders. Migration Wiz have a separate tool for public folder migrations which is very simple to use. I always prefer to convert public folders into resource mailboxes.

Credit: The domain removal powershell migration scripts are publicly available in Migration  Wiz Knowledge Base articles.

I have wrote many articles  about the Exchange Hybrid process. There are lots of excellent articles on line about this process. This blog post is aimed it simplifying the whole process and ensuring 2010 clients can still connect when using Exchange 2016 servers for autodiscover.

The Exchange Online Hybrid wizard has greatly improved over the years and the Exchange Hybrid Modern Agent is an amazing step forward and provides a mechanism to quickly migrate mailboxes to Exchange Online.

Exchange 2010  support will Expire in October 2020. I have recently been performing a lot of Hybrid migrations using Exchange 2010 and Exchange 2016 as the hybrid server

I always use this powershell SCRIPT to install the pre-requisites for each new Exchange server.

Autodiscover services are typically  transferred from the Exchange 2010 servers to Exchange 2016 servers.

Simply updating the autodiscover.consto.com A record to point at the new Hybrid server and expecting clients to connect without any issues is a big mistake.

If the Exchange 2010 organisation has a load balanced virtual ip , this IP cannot be simply reused for the Exchange 2016 server. The main reason for this is that,mapi has transitioned to mapi over http from Exchange 2013 versions and higher.

Exchange 2016 has different virtual directories and also has health check urls per Exchange virtual directory.

• Kemp – Kemp have templates for Exchange 2016
• F5 – Have templates for Exchange 2016
• Netscaler – Follow this article to load balance Exchange 2016 via Netscaler HERE

When the Exchange Hybrid has been installed and configured , Run this SCRIPT
And set all of the virtual directories to your corporate domain eg. autodiscover.contoso.com

On the Exchange 2010 server , get an inventory of databases hosted on the Exchange 2010 servers. And then run this command to set the rpc client access server per Exchange 2010 database,

Set-MailboxDatabase –Identity “<Database Name>” –RPCClientAccessServer “exch2010-01.contoso.local”

This is the most important task, Exchange 2016 receives autodiscover requests and proxies them to the Exchange 2010 client access servers for mailboxes that are still hosted on Exchange 2010.

Now is the time to update the two DNS records autodiscover.contoso.com and mail.contoso.com to point to the new Hybrid server.

Exchange Online users that have been migrated and are working outside of their company offices will query the public autodiscover.contoso.com record which will point to the hybrid server, the hybrid server will respond with the correct autodiscover xml via http redirect to Exchange Online.

Microsoft previously submitted all the urls  and ip ranges for the Office365 platform on docs.microsoft.com. Now there is a new Office365 IP Web Service , HERE 

It would be great if this dynamic ip services covered all services in Office365  that can be updated in firewalls and proxies. Unfortunately it does not.

Intune is an amazing service from Microsoft but if you do not white-list the endpoints listed HERE

Features like Bitlocker, x86 custom app deployments, Windows 10 Security Baselines will fail.

Even I get confused when it comes to all the different options available with Microsoft cloud services.Some of my global customers have engaged with business analyst to perform the task of user profiling to try and establish what licenses end user really need per division.

One of my customers refused to buy AD premium for all users because they could lock down access by IP-range with ADFS and don’t need to license 23k users for AD premium. This is a very valid use case when you do the numbers and saves a lot of money.

Some of my customers want conditional access but do not have a compatible version of Office or OS and when the cost associated with bringing the desktop to a suitable level for conditional access for 10, 20k user sites, they are most often binned.

For global roll outs of Office365 , I aways recommend the use of a business analyst for user profiling to get the best value for your client or customer.

Microsoft always get their money!!!