PowerShell Tip: Obtaining the ImmutableID from your Active Directory Objects on-prem and in the cloud

PowerShell Tip: Obtaining the ImmutableID from your Active Directory Objects on-prem and in the cloud

When working with Azure Active Directory Connect you may experience issues with account duplicating due to the ImmutableID not matching. If it does happen its is a pain to resolve as you have to;

Desynchronize the affected accounts
Delete from the Deleted Users OU in Azure Active Directory
Obtain the on-premises ImmutableID
Obtain the cloud ImmutableID
Compare the IDs
Set the cloud ID with the on-premises ID

Now wouldnt it be easier if someone had a bunch of PowerShell commands to help you get the ImmutableID. This is where I come in

Obtaining ImmutableID from on-premises Active Directory Object

The following PowerShell script extracts all the ImmutableID’s from every single Active Directory User Object and store in a CSV file on your desktop.

$reportoutput=@()
$users = Get-ADUser -Filter * -Properties *
$users | Foreach-Object {

    $user = $_
    $immutableid = "[System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())"
    $userid = $user | select @{Name='Access Rights';Expression={[string]::join(', ', $immutableid)}}

    $report = New-Object -TypeName PSObject
    $report | Add-Member -MemberType NoteProperty -Name 'UserPrincipalName' -Value $user.UserPrincipalName
    $report | Add-Member -MemberType NoteProperty -Name 'SamAccountName' -Value $user.samaccountname
    $report | Add-Member -MemberType NoteProperty -Name 'ImmutableID' -Value $immutableid
    $reportoutput += $report
}
 # Report
$reportoutput | Export-Csv -Path $env:USERPROFILE\desktop\ImmutableID4AD.csv -NoTypeInformation -Encoding UTF8 }

Obtaining ImmutableID from Azure Active Directory Object

The following PowerShell script extracts all the ImmutableID’s from every single Azure Active Directory User Object and store in a CSV file on your desktop.

$reportoutput=@()
$users = Get-AzureADUser -All $true
$users | Foreach-Object {

    $user = $_

    $report = New-Object -TypeName PSObject
    $report | Add-Member -MemberType NoteProperty -Name 'UserPrincipalName' -Value $user.UserPrincipalName
    $report | Add-Member -MemberType NoteProperty -Name 'SamAccountName' -Value $user.samaccountname
    $report | Add-Member -MemberType NoteProperty -Name 'ImmutableID' -Value $user.immutableid
    $report | Add-Member -MemberType NoteProperty -Name 'DisplayName' -Value $user.displayname
    $reportoutput += $report
}
 # Report
$reportoutput | Export-Csv -Path $env:USERPROFILE\onedrive\desktop\ImmutableID4AAD.csv -NoTypeInformation -Encoding UTF8 }

Recommendation

When I have had to compare the two exports at scale for an entire environment, it can be a complete nightmare but the ImportExcel module was brilliant in getting the data merged into a single sheet.

https://www.powershellgallery.com/packages/ImportExcel/7.1.1

Regards
The Author – Blogabout.Cloud

Where is the Service Connection Point (SCP) set for Microsoft Exchange Server?

Where is the Service Connection Point (SCP) set for Microsoft Exchange Server?

Every IT Administrator will have heard the term “Service Connection Point” or SCP when autodiscover is mentioned especially if you are still running Exchange Server On-Premises.

What is SCP?
Where can I find it?
What is it used for?

Whenever a Client Access Server is installed into a Greenfield or exisiting Exchange organisation. Exchange automatically creates at installation the virtual directory

1
autodiscover
in IIS, the frontend Client Access services web site that clients connect to. This allows Outlook to discover the Exchange mailbox settings so that users don’t have to deal with manually configuring advanced settings.

Autodiscover functional process

The SCP object is also created in Active Directory at the same time as the Autodiscover service virtual directory. The SCP stores and provides authoritative URLs of the Autodiscover service for domain-joined computers.

Where can I find SCP?

You can view the SCP object using Active Directory Sites and Services, after you have enabled the “View Services Node” option from the “View” tab.

You will have a list of SCPs if you have more than one CAS server in your environment. If you right click and take the properties of the SCP object (Attribute Editor tab), it contains two two pieces of information which is of interest;

  • “serviceBindingInformation” attribute
  • keywords” attribute.

The “serviceBindingInformation” attribute has the Fully Qualified Domain Name (FQDN) of the Client Access server in the form of https://ex02.officec2r.com/autodiscover/autodiscover.xml, where ex02.officec2r.com is the FQDN of the CAS server.

This url is mostly changed to one that is covered by the SAN/UCC certificate. It is this url which internal Outlook client uses to connect to the mailbox and other Exchange features published using autodiscover.

The “keywords” attribute specifies the Active Directory sites to which this SCP record is associated. By default, this attribute specifies the Active Directory site to which the Client Access server belongs.

What is it used for?

When using a domain joined client, Outlook client authenticates to Active Directory and tries to locate the SCP objects by using the user’s credentials. After the client obtains and enumerates the instances of the Autodiscover service, it connects to the first Client Access server in the enumerated list and obtains the profile information in the form of XML data that is needed to connect to the user’s mailbox and available Exchange features.

If you require to remove the ServiceBindingInformation at any point this can be completed by;


1
Set-ClientAccessServer -AutoDiscoverServiceInternalUri $Null

Once Active Directory replication has completed, the SCP object will be updated with the Null Value and if you need to reinstate the AutoDiscoverServiceInternalUri run the same command again but with the require value


1
Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://ex02.officec2r.com/autodiscover/autodiscover.xml

Regards
The Author – Blogabout.Cloud

Configuring Office 365 Service Communications API within your own Azure Active Directory.

Configuring Office 365 Service Communications API within your own Azure Active Directory.

Office 365 Service Communications API enables an organization to gather data about the Microsoft 365 tenancy and in this post we will be looking at Service Health.

Prerequisites

  • Relevant Azure Active Directory Permissions to create an app
    • Global Administrator,
    • Application Administrator
    • Cloud Application administrator
  • Licensed for Power Automate either;
    • Per-user plan
    • Per-user plan with attended RPA
    • Per Flow plan

Configuring Azure Active Directory

Login into the Azure Portal via http://portal.azure.com and browser to Azure Azure Directory then select App Registrations –> New Registration

Now enter a Name for the application i.e. Office 365 Service Communications API, select Accounts in this organizational directory only

The Redirect URI can be ignored as it no longer necessary and then click Register.

The registered app you just created will now be displayed – click on API permissions on the left hand menu. Click on the Add a permission button in the Configured permissions section. Select Office 365 Management API in the Request API permissions section.

Select Application permissions as the type of permissions your application requires. Then Select ServiceHealth.Read as the permissions required and then select the Add permissions button.

Granting Tenant Admin Consent

The application is now configured with the permissions it needs to use the Office 365 Management APIs but first it needs an admin to grant these permissions. A Global Administrator, Application Administrator or Cloud Application administrator must explicitly grant your application these permissions. This is granting the app permissions to use the APIs to access your tenant’s data. 



If you do not have the necessary role please advise the admin to follow this link and provide them with the name of your App Registration to review and approve.

If you have the necessary Global Administrator, Application Administrator or Cloud Application administrator role click on the Grant admin consent to <tenant name> button.

Generate a new key / client secret for your application

Navigate to the main page for the App Registration you just created, now make a note of the Application (client) ID and Directory (tenant) ID as you will need these later to access the Office 365 Management API using the app just created. Now Client secret needs to be generated to be used for authentication to the APIs – click on Certificates & Secrets on the left hand menu.

IMPORTANT: Now make a note of the Client Secret created i.e. BlahBlah-BlahBlah. It is important that this is done now as once this window is closed the Client secret will no longer be visible.

This completes the process for configuring Office 365 Service Communications API. The next step will be using either PowerShell or Power Automate to present the data.

If you would to utilize Power Automate check out this blog post I created.

Regards
The Author – Blogabout.Cloud

Understanding Azure Active Directory Connector soft matching

Understanding Azure Active Directory Connector soft matching

It is has become very common across most organizations that they set up an Office 365 tenancy or Azure tenancy without configuring integration with their own on-premises Active Directory or another scenario an organization has been brought by another company. The end-users are then given cloud-only accounts until such a time where they can be fully integrated. In going down this road it can potentially cause a number of issues that need to be resolved by either soft matching or hard matching the on-premises AD User with the Cloud Account.

How do I soft match?

Soft matching is driven by the SMTP Address of the user account and usually, the UPN matches the SMTP Address. So in the diagram below that, I have created you can see I have captured the two scenarios organizations move their on-premises identities to Azure Active Directory. What I have also done is put a deliberate mistake into the images, can you spot what it is?

So User D and Cloud D are the same users but the UPN is different, why have I done this? This is to explain the behavior that will happen if the account cannot be correct identified with its cloud account. User A to C will all synchronize successfully and correctly however, User D will not succesfully be synchronized as the UPN that doesn’t match Cloud D. While this isn’t a bad issue for this scenario but if you were actioning at scale, I hope you are ready for a host of complaints from users.

Its is important to ensure that the SMTP Addresses on-premises vs. the cloud but please be aware there are limitations like in any Microsoft product

SMTP matching limitations

The SMTP matching process has the following technical limitations:

  • SMTP matching can be run on user accounts that have a Microsoft Exchange Online email address. For mail-enabled groups and contacts, SMTP matching (Soft match) is supported based on proxy addresses. For detailed information, refer to the “Hard-match vs Soft-match” section of the following Microsoft Azure article: 

    Azure AD Connect: When you have an existent tenant

    Note This doesn’t mean the user must be licensed for Exchange Online. This means that a mailbox that has a primary email address must exist in Exchange Online for SMTP matching to work correctly.
  • SMTP matching can be used only one time for user accounts that were originally authored by using Office 365 management tools. After that, the Office 365 user account is bound to the on-premises user by an immutable identity value instead of a primary SMTP address.
  • The cloud user’s primary SMTP address can’t be updated during the SMTP matching process because the primary SMTP address is the value that is used to link the on-premises user to the cloud user.
  • SMTP addresses are considered unique values. Make sure that no two users have the same SMTP address. Otherwise, the sync will fail and you may receive an error message that resembles the following: Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:john@contoso.com;]. Correct or remove the duplicate values in your local directory.

Hard-match works in a simalar way but uses the ImmutableID of the user accounts. This is unique value that each account has, so to hard match the on-premises ImmutableID to the cloud account would mean that you modify every single Cloud account with the correct on-premises account value. I know this from experience as I had to do just that for one of my customers and created a powershell script to enable the change.

Regards
The Author – Blogabout.Cloud

Going Passwordless with YubiKey by Yubico

Going Passwordless with YubiKey by Yubico

This has been on my To-Do list for such a long time and because of Covid-19 I have finally found the hours required to get this done. A while back I received two Yubico and never got around to testing them 🙁 naughty I know. So let’s look at Yubico;

Microsoft and Yubico have been created a path for a passwordless future for organizations of all shapes and sizes. With a technology standard called FIDO2 and U2F which Yubico co-authored with, Microsoft and Google. Yubico became a founding member of the FIDO Alliance.

How does it all work, I hear you

The Yubikey supports multiple methods for authentication, enabling and the same key to be used across services and applications. With an out of the box native integration for the Microsoft environment provides a rapid deployment.

Diagram that outlines the steps involved for user sign-in with a FIDO2 security key
  1. The user plugs the FIDO2 security key into their computer.
  2. Windows detects the FIDO2 security key.
  3. Windows sends an authentication request.
  4. Azure AD sends back a nonce.
  5. The user completes their gesture to unlock the private key stored in the FIDO2 security key’s secure enclave.
  6. The FIDO2 security key signs the nonce with the private key.
  7. The primary refresh token (PRT) token request with signed nonce is sent to Azure AD.
  8. Azure AD verifies the signed nonce using the FIDO2 public key.
  9. Azure AD returns PRT to enable access to on-premises resources.

Enabling support for Yubikey

Time to log into your Azure Active Directory via http://portal.azure.com

Select Security
Select Authentication methods
Select FIDO2 Security Key and Enable for your environment

Now thats the easy bit completed, the next step is educating the users.

NOOooooo That's impossible!!!!! - Luke Skywalker - quickmeme

Configuring Yubikey

Each user will need to visit the following your https://myprofile.microsoft.com/

Select Security Info
Click Add Method
Select Security Key –> Add
Select USB device
Press Next
Insert your Security Key into one of your USB ports.
Specify a security key PIN
Touch the button on the security key
Provide a name to identity the security key
All Done!!

Hows does the sign-in work?

Well, really simple. Check out the video below

Regards
The Author – Blogabout.Cloud

Enforcing Cloud Password Policy for Password Synced Users

Enforcing Cloud Password Policy for Password Synced Users

Did you know that Enforce Cloud Password Policy for Password Synced Users exists? and that it is also disabled by default. This means that any user that you sync using Azure Active Directory Connect will not have an expiration timer set against their account. This can be a nightmare for an organization that has strict password policies.

So let’s switch it on and get all your synced users applied

First of all, you will need to run the following command after you have ran Connect-MsolService

PowerShell Command

Set-MsolDirSyncFeature -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers -Enable $true

You can verify all your users by running the following commands

PowerShell Command

# Output all users to PowerShell console
Get-AzureADUser | Select-Object DisplayName,DirSyncEnabled, PasswordPolicies, AccountEnabled

# Output all users where DirSyncEnabled equal True
Get-AzureADUser | Select-Object DisplayName,DirSyncEnabled, PasswordPolicies, AccountEnabled | Where-Object {$_.DirSyncEnabled -eq $true}

Now let’s apply the following script to ensure that the Password Policy is not disabling password expiration.

PowerShell Command

Get-AzureADUser -All $true | Where-Object { $_.DirSyncEnabled -eq $true -and $_.PasswordPolicies -eq ‘DisablePasswordExpiration’ } | ForEach-Object {
Set-AzureADUser -ObjectId $_.ObjectID -PasswordPolicies None
}

Regards
The Author – Blogabout.Cloud

Obtaining your ImmutabeID the easy way because hard matching is a nightmare

Obtaining your ImmutabeID the easy way because hard matching is a nightmare

Imagine, your company has just been brought by another organization. The acquiring company what you using Office 365 services as quick as possible so they create you a Cloud Only Account to leverage their existing tenant. Now imagine, you are 12 months into the acquisition and you want to have a single sign-on experience for your end-users.

Now you have a dilemma on your hands, as your primary user principle name on-premises is different from your UPN in the Azure Tenant.

WHAT DO YOU DO!!!

Image result for captain picard head in hand
What did I do??

You engage your Windows PowerShell Console in Administrator Mode and teleport in the Get-ImmutableID.ps1 PowerShell script

Image result for captain picard
Engage!!!
New Features coming soon!!

With this script, you are able to download all the ImmutableIDs from your local Active Directory into a single CSV file to your desktop.

Please Note:

If there are additional fields you would like to see in this script, please submit an update via Github or email alerts@blogabout.cloud

You will need some manual intervention matching your on-premises AD Users and AAD Users but once this is complete you will be able to run the following script to set the ImmutableID in your Azure Active Directory.

PowerShell Script


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
region File Path
 $Filepath1 = Get-Filename -initialdirectory "$env:USERNAME\desktop"
 $csv1 = Import-Csv -Path $filepath1
 endregion
 
Start-Transcript "env:userprofile\desktop\SetAllUserAADtest.txt"

 ForEach($user in $csv1){
 Try  
{ Get-AzureADUSer -ObjectId $user.primarysmtpaddress -ErrorAction Ignore Write-Host "Success:",$user.PrimarySMTPAddress,"was found and set with",$user.ImmutableID -BackgroundColor DarkGreen
Set-AzureADUser -ObjectID $user.PrimarySMTPAddress -ImmutableID $user.ImmutableID }
catch
{ Write-Host "ERROR:",$user.PrimarySMTPAddress,"could not be found" -BackgroundColor DarkRed }

Stop-Transcript

While this is a tried and tested in my own deployments, I am unable to take responsibility for any potential issues you may encounter. Keep safe with responsible scripting, always test in a lab environment first.

Regards
The Author – Blogabout.Cloud

Do you have Device Writeback enabled on Azure Active Directory Connect? Do you know how to check if a device has been written back?

Do you have Device Writeback enabled on Azure Active Directory Connect? Do you know how to check if a device has been written back?

I have been recently working with a customer and errors within AAD look which pointed to an issue with Device Writeback not being enabled on Azure Active Directory Connect.

But how do you check if the device is writing back? Well, I’m glad you asked. First of all, we need the Device ID which is obtain running a cmd via command prompt.

dsregcmd /status

Once you have this information you will need to run the following command using PowerShell on one of your domain controllers.

$deviceid = “Enter ID here”
Get-ADObject -LDAPFilter “(cn=$deviceid)” -SearchBase = “CN=RegisteredDevices,DC=OfficeC2R,DC=com,”

If you are returned an error i.e Directory Object Not Found. It is safe to say the device hasnt been registered yet.

And its as simple as that

Regards
The Author – Blogabout.Cloud

Merging on-premise AD User Objects with existing Azure AD user Objects.

Merging on-premise AD User Objects with existing Azure AD user Objects.

This post will explain how to merge an on-premise AD user objects with an already existing Azure AD user using hard-match with the sourceAnchor/immutableID property. I have recently experience this issue with a customer who was merging their contoso.com addresses to their fabikam.com Azure AD account.

As you can imagine this isnt a simple process but with the power of PowerShell and good old fashion “I can” attitude, this merger was a complete success.

Before we continue I would like to state that there are two methods that Azure AD Connect will use to match existing users;
– Soft-Match
– Hard-Match

When you install Azure AD Connect and you start synchronizing, the Azure AD sync service (in Azure AD) does a check on every new object and try to find an existing object to match. There are three attributes used for this process: userPrincipalName, proxyAddresses, and sourceAnchor/immutableID.

Soft-Match

Soft-Match will use the properties userPrincipalName and proxyAddresses to match existing users.

Hard-Match

Hard-Match will use the property sourceAnchor/immutableID. You can only select which property is used as sourceAnchor during the installation of Azure AD Connect as described in their documentation.

If the selected sourceAnchor is not of type string, then Azure AD Connect Base64Encode the attribute value to ensure no special characters appear.

Important Note

By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute. ObjectGUID is system-generated.

So we only have to set the immutableID property of the existing user in our Azure AD to the Base64 encoded string of the ObjectId of the user in our on-premise AD. If you already synchronized your Active Directory then you probably have two users with the same name in your Azure AD. Just follow the following steps to finally merge these users:

You have to execute the following PowerShell commands on the machine with your on-premise AD and the Azure PowerShell commands via the Azure Cloud Shell.

In my scenario, I had a customer that the Email Address on the Active Directory Account didn’t match the PrimarySMTPAddress in Azure AD, however, the PrimarySMTPAddress in Exchange was correct. So I need to match both objects using the PrimarySMTPAddress from Exchange And Azure to set the ImmutableID. I create a PowerShell to gather PrimarySMTPAddress from Exchange along with the required information from Active Directory

1. Get ObjectId from All AD Users

$reportoutput=@()
$users = Get-ADUser -Filter * -Properties *
$users | Foreach-Object {

    $user = $_
    $exchange = Get-Mailbox $user.Name
    $immutableid = [System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())

    $report = New-Object -TypeName PSObject
    $report | Add-Member -MemberType NoteProperty -Name 'DisplayName' -Value $user.DisplayName
    $report | Add-Member -MemberType NoteProperty -Name 'PrimarySMTPAddress' -Value $exchange.PrimarySMTPAddress
    $report | Add-Member -MemberType NoteProperty -Name 'UserPrincipalName' -Value $user.UserPrincipalName
    $report | Add-Member -MemberType NoteProperty -Name 'ImmutableID' -Value $immutableid
    Write-Host ('INFO: The following user {0} has the Immutable of {1}' -f $user.name,$immutableid)
    $reportoutput += $report
}
 # Report
$reportoutput | Export-Csv -Path $env:USERPROFILE\desktop\immutableid.csv -NoTypeInformation -Encoding UTF8

2. Remove duplicated Azure AD User

If you have synced users and have duplicate accounts you will need to remove these before looking at continuing. A simple way of doing this changing the OU you have synced which has caused the duplicate or you can use the Azure Portal

Deleted Users

But if you love PowerShell the following command is also possible as well.

Remove-AzureADUser -ObjectId <objectid>

3. Get Azure AD User ObjectID

One of the key requirements for this post is that we require the ObjectID of the Azure Active Directory account we are looking to match against. The following PowerShell command prints a list of all users with their ObjectId and exports to your desktop.

Get-AzureADUser | export-csv $env:userprofiles\desktop\AzureADUser.csv

4. Matching my CSV Files

So I ended up with two CSV files

– Export of AD with PrimarySMTPAddress from Exchange
– Export of Azure AD with ObjectID and PrimarySMTPAddress.

A few months ago I came across a little gem in the PowerShell world called ImportExcel which is a PowerShell module I have discussed in the past.

Once you have a single pane of glass with your ObjectID and ImmutableID matched within a csv, you will now be able to set all the ImmutableID for all your Azure AD Objects.

5. Set immutableId for Azure AD User in Bulk

Run the following script against Azure AD using PowerShell.

$Filepath1 = $env:USERNAME\desktop\immutableid.csv
$csv1 = Import-Csv -Path $filepath1

#endregion 

Start-Transcript $env:USERPROFILE\desktop\PilotUser.csv

foreach($user in $csv1){

    Set-AzureADUser -ObjectID $user.ObjectId -ImmutableID $user.ImmutableID
    Write-Host $user.PrimarySMTPAddress,"with ObjectID"$user.ObjectId," has been set with ImmutableID",$user.ImmutableID
}
Stop-Transcript


6. Start AD Sync

You can now resync the OUs which had all the user accounts and hard matching will be completed using the newly set ImmutableID.

Start-ADSyncSyncCycle -PolicyType Delta

Regards
The Author – Blogabout.Cloud

Convert Synced User into In-Cloud only User

Convert Synced User into In-Cloud only User

In this example I have local Active Directory with AAD Connect installed one of the Azure Region, which sync users and password hash to Office 365. I have now decided to migrate the authentication from local Active Directory to Office 365 and decommission on-premises Active Directory.

Azure Active Directory Connect Diagram

In order to transition from on-premises “Synced Identity” to “In Cloud Identity”, we will need to complete the following process.

IMPORTANT NOTE!!!!!

When deactivating Directory Sync it may take up to 72 hours before it can reenable depending on the size of your production network. All users will keep their current password but all synchronized objects are removed from Azure AD, please keep this in mind.

To check if you can reenable Directory Sync you will need to run Get-MSLCompanyInformation. This will show you the detailed information. and the last four fields are the most important in this scenario as this will indicate if Directory Sync can be reenabled as the status is False.
DirectorySynchronizationEnabled
LastDirSyncTime
LastPasswordSyncTime
PasswordSynchronizationEnabled

In my scenario, Directory Sync was able to be reactivated after 8 hours. The customer I was working with accepted the potential risk in order to complete this work.

Sign into the AAD Connect Server and Sync the Delta

The following command performs a sync of all AD Objects before attempting to convert into Cloud Only.

 Start-ADSyncSyncCycle Delta 

Turn off AAD Connect Sync

The following command turns off Azure Active Directory Connector while we perform all the following tasks. In this post I have outlined all steps which can be taken to convert AD Users account into Cloud Only.

 Set-MsolDirSyncEnabled -EnableDirSync $false 

Convert Single User to Cloud Only

The following command converts a single user into a Cloud Only account

 Get-MsolUser -UserPrincipalName thewatchernode@blogabout.cloud | Set-MsolUser -ImmutableId $null 

Remove Immutable ID of all users

The following command removes the Immutable ID for all users

 Get-MsolUser | Set-MsolUser -ImmutableId $null 

Remove Immutable ID for Bulk users

The following scripts allows you to modify users at bulk

$Filepath = $env:userprofile\desktop\file.csv
$csv = Import-Csv -Path $filepath
$immutableID=$null 

Foreach($user in $csv)
{
Set-MsolUser -UserPrincipalName $user.UserPrincipalName -ImmutableID $immutableID
}

Turn on Azure Active Directory Connect Sync

Once you have completed all the required conversions of AD accounts to Cloud. Head back to your local Active Directory, move user(s) to an OU that isn’t synchronized using AADC.

This helps you as an IT Pro understand who has been converted at a quick glance now not worry about using PowerShell to discovery who is or isn’t.

The following command turns on Azure Active Directory Connector now that we have converted the users accounts to Cloud Only

 Set-MsolDirSyncEnabled -EnableDirSync $true 

Enable Force Sync if the Sync didn’t work

  Start-ADSyncSyncCycle -PolicyType Initial 

If you are using an ADFS Server there is an additional step providing you have moved all your users to the Cloud. You will need to change the Federated Domain to Standard Domain

Convert-MsolDomainToStandard -DomainName blogabout.cloud -WhatIf
Convert-MsolDomainToStandard -DomainName  blogabout.cloud -Confirm

All that is left now is to log in as one of the converted users to prove Single Sign-On is working and logon as a Global Admin into Office 365 to check the sync status of the users has a pretty cloud for “In-Cloud”

https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/36479119-allow-conversion-of-ad-synced-accounts-to-in-clou

Regards
The Author – Blogabout.Cloud