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

The Author – Blogabout.Cloud

Delivering your applications to Windows 10 Clients using Azure Blob Storage and Intune

Delivering your applications to Windows 10 Clients using Azure Blob Storage and Intune

Delivering your corporate applications can be a nightmare if you dont have a enterprise delivery solution like System Center or 3rd party mechanism.

So let’s see how Azure Blob Storage and Microsoft Intune can address this issue by using a storage location and PowerShell script.

Azure Storage Account

One of the requirements for this solution is an Azure Storage Account within your Azure subscription, this account will be used for storing the applications which you would like to roll out to your Windows 10 desktops that are managed using Microsoft Intune.

Storage Account

Specify the required settings within the Basic tab for creating a Storage Account.

Basic Properties

Using the default settings as shown below

Advanced Properties

Click Review and Create
Click Create

Configuring Storage Account with required Applications

Click Container
Specify the Name
Select Conditioner (anonymous read access for containers and blobs) under Public Access Level

Blob – Container

Select your container
Select Upload
Select the files you want to upload
Modify the block size if it’s less than the size of the files you are uploading
Select Upload

Once the files are upload they all have a unique url which is used to identify the file as shown below.

The PowerShell Script!!!

I have created a PowerShell script that is available on GitHub and should be self-explanatory.

Step 1 – Download all the required files into C:\_Build
Step 2 – Run installer files
Step 3 – Run additional Powershell scripts (Optional)
Step 4 – Remove C:\_Build
Step 5 – Create RegKeys (Optional)


Publish script via Intune

If you are having issues with script not executing, please visit this URL to ensure you met all the Microsoft pre-requisites.


The Author – Blogabout.Cloud

Preventing unauthorized external access from home to your Microsoft Cloud applications with Conditional Access

Preventing unauthorized external access from home to your Microsoft Cloud applications with Conditional Access

Did you know that you could prevent unauthorized access to your Microsoft Cloud applications with Conditional Access? When speaking with a customer recently I had been asked is it possible to prevent external access to their Cloud apps and the answer to that is yes. The customer didn’t want their staff accessing corporate data from their home laptops/desktops so in order to action this we will now switch over to the Microsoft Endpoint Manager Admin Portal.


Click Endpoint security –> Conditional access
New Policy
Provide name to the Conditional Access Policy
Select All Users
Excluding the Global Admins to the tenant security group, we dont want to chop off our legs now
Select All cloud apps
Conditions –> Client apps –> Browser
Grant –> Block access

Now enable the policy 🙂 and as you can see from below you users is now prevented from login into the Office portal from an internet browser.

The Author – Blogabout.Cloud

Understanding Hybrid Azure AD Join for Windows 10 devices

Understanding Hybrid Azure AD Join for Windows 10 devices

In recent times I have started to become a bit of an “expert, well I will use that word loosely” for Windows 10. Hybrid Azure AD Join is becoming a very popular option for a lot of the clients that I am currently working with and pops up all the time in discussions about “Modern Management” of Windows 10. I have experienced a few highs and lows when implementing Hybrid Azure AD Join and want to share that knowledge I have gain over the past 6 months.

What is Hybrid Azure AD Join?

Hybrid Azure AD Join is where your Windows 10 device is connected to your local Active Directory Domain and synchronized using Azure Active Directory Connect (AADC) to Azure AD.

Why would you do this?

This enables you to manage your Windows 10 devices from Microsoft Intune and leverage the offers from the cloud. Most organizations today have the required Microsoft subscriptions to implement Microsoft Intune but are unaware of how to start their journey.

What do I need for Hybrid Azure AD Join in a Managed Domain?

  • Azure Active Directory Connect version 1.1.819 or greater
  • Devices must be able to connect to the following URLs
    • https://enterpriseregisteration.windows.net
    • https://login.microsoftonline.com
    • https://device.login.microsoftonline.com
    • https://autologon.microsoftazuread-sso.com
  • All Computer Objects from your on-premises Active Directory must be within the sync scope
  • Service Connection point (SCP) is created for device registration (Completed via running AADC)

Implementing Hybrid Join for your organization

We are now going to run through the steps required to gear up your environment for Hybrid Join, first of all we are going to create the SCP using AADC. When you launch AADC you see “Configure device options”, select this option and proceed

Configure device options

In this section you will receive the following Overview of what can be configured and in this case, we are looking at Hybrid Azure AD Join only.

Hybrid Azure AD Join enables devices in your Active Directory forest to register with Azure AD for access management. Computers in your organization will automatically discover Azure AD using a service connection point (SCP) object that is created in your Active Directory Forest.

Device writeback is a prerequisite for enabling on-premises conditional access using AD FS and Windows Hello for Business. Device writeback synchronizes all devices registered in Azure AD back to on-premises. The device are synchronized to a device container that is created in your Active Directory forest.

Important Note

Device writeback requires the Active Directory Schema version to be Windows 2012 R2 (level 69) or higher
Connect to Azure AD
Configure Hybrid Azure AD Join and proceed
Tick “Windows 10 or later domain-joined devices.” It is worth remembering that your Windows 10 devices need to be synchronized and Proceed
Tick your Forest
Select Azure Active Directory
Click Add
Enter your Enterprise Admin Credentials
Configure and this completes this task

You can confirm that the SCP has been created by launching ADSI Edit and browse to the location displayed below.

Now we have configured Active Directory we need to create a new GPO that configures the Windows 10 device to AutoEnroll into Azure AD. First of all we need the correct GPO templates installed in your SYSVOL, these templates can be download by the below URL.


Once you have installed the required GPOs to your primary domain controller you’ll be able to “Enable automatic MBM enrollment using default Azure AD”

Computer Configuration –> Policies –> Administrative Templates –> Windows Components –> MDM
Enable Policy and select Device Credential, User Credential is a legacy option but its recommended to use Device.

Once this policy enabled and linked to the OU where your computers are located, they will become Hybrid Azure AD Joined.

Gotchas !!!

This Microsoft link is your friend if you encounter any issues with Windows Enrollment Errors

You can also follow the official Microsoft documentation

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 will use the properties userPrincipalName and proxyAddresses to match existing users.


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

$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


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

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

The Author – Blogabout.Cloud

Using Azure Blob Storage for your Intune applied Lock Screen and Desktop Backgound

Using Azure Blob Storage for your Intune applied Lock Screen and Desktop Backgound

Leveraging your Azure subscription for Microsoft Intune massively reduces the requirements for on-premises infrastructure. In this post I will show you how to use Azure Blob Storage to provide the Lock Screen and Desktop background all with the power of the Microsoft Cloud.

First up you will need to create a storage account within your Azure subscription.

Create Storage Account

Specify the following;
– Resource Group
– Storage Account Name
– Location (Europe) UK South

Specify settings

Once the storage account has successful created, you will need to go to the resource

Go to resource

Go to “Containers”
Create new “Container”
Specify the name of the Container
Specify the Public Access level as “Blob”
Then click ok

Specify settings

Click on your new “Container”

Created Container

Click Upload
You will need to upload your required .jpg file

Click on the uploaded file and you will be provided a URL which can be used

Provide the URL into your required destination for example Lock Screen as shown below

As you can see from below my Lockscreen and Desktop backgrounds are what I have specifed.

Image for Lockscreen
Image for Desktop

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.

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

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<br>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”

The Author – Blogabout.Cloud

Windows 10 Azure AD – Something went wrong

Windows 10 Azure AD – Something went wrong

So I have been recently cleaning up my test lab Azure Active Directory and accidentally removed a device which I was still actively using within my tenant. I received the following error;

“Your organization has deleted this device. To fix this, contact your system administrator and provide error code 700003”

When trying to access organizational resources

In order to resolve this issue, you need to complete the following steps

– Remove the Work account from the Windows 10 device under your account –> Access Work or School and remove the account
– Open command line or PowerShell windows with Admin rights
– Enter the following command;
dsregcmd /leave

dsregcmd /leave

Enter command: “dsregcmd /status” to check if the system is now left the Azure AD

dsregcmd /status

You will now been able to register your device and access your organisation once again.

The Author – Blogabout.Cloud

Managing your on-premises device with Azure Update Manager

Managing your on-premises device with Azure Update Manager

Azure Update Manager allows customers manage their Azure VM and on-premises devices using an agent called (MMA) Microsoft Monitoring Agent. The client will by default check if its compliant every 12 hours and the agent initiates a scan to check for update compliance within 15 minutes of the agent being restarted, before an installation and after update installation.

Azure Update Manager only supports the following OS for patch cycles

Supported Client Types

Operating SystemNotes
Windows Server 2008, Windows Server 2008 R2 RTMSupports only update assessments.
Windows 2008 R2 SP1 and later (including Windows Server 2012 and 2016).Net Framework 4.5.1 or later is required
Windows Powershell 4.0 or later is required
Windows PowerShell 5.1 is recommended for increased reliability.
CentOS 6 (x86/x64) and 7 (x64)Linux agents must have access to an update repository. Classification-based patching requires ‘yum’ to return security data which CentOS doesn’t have out of the box. For more information on classification-based patching on CentOS
Red Hat Enterprise 6 (x86/x64) and 7 (x64) Linux agents must have access to an update repository.
SUSE Linux Enterprise Server 11 (x86/x64) and 12 (x64) Linux agents must have access to an update repository.
Ubuntu 14.04 LTS, 16.04 LTS, and 18.04 (x86/x64) Linux agents must have access to an update repository.

Unsupported Client Type

Operating SystemNotes
Windows ClientClient operating systems (such was Windows 7 and Windows 10 arent supported.
Windows Server 2016 Nano ServerqNot Supported

However, the Windows Client arent supported for patch management. The MMA agent can be installed if you just require update reporting using Azure Monitor.

Where do I start in configuring Azure Update Management?

The first thing we need is an Azure Automation Account

You will need to provide details as specified below

Please Note:

Log Analytics Workspace is required later in this process and its only currently available in the following locations;

Australia Southeast
Canada Central
Central India
East US
Japan East
Southeast Asia
UK South
West Central US
West Europe
West US 2

If you want to check where functionality located, please visit this url https://azure.microsoft.com/en-us/global-infrastructure/services/?products=monitor&regions=us-east,us-east-2,us-central,us-north-central,us-south-central,us-west-central,us-west,us-west-2,canada-east,canada-central,united-kingdom-south,united-kingdom-west,non-regional,south-africa-north,south-africa-west

Once the account has been created, select the newly account and go to Update Management Section and Update Management. This will show the Location you specified, Log Analytics Workspace subscription and you can now create the Log Analytics Workspace.

Configure Automation Account for Update Management

Once you press Enable, you’ll receive a message that “The installation of the Update Management solution is in progress.”

Enable Update Management with Log Analytics Workspace

Now we have successful created the Log Analytics Workspace you will be able to build the “Schedule Update Deployment” as shown below

Update Management – Schedule Update Deployment

Now we can get down with the nit and gritty of configuring deployment schedules based on your own requirement. This section will be configured down to personal preference for my Test Lab Machine.

Please Note:

The following information will only reference Windows Operating System, Linux is also available but will not be discussed.

Groups to update

In this section, you can filter the machines you would like to manage using Azure Update Management. This also includes the Non-Azure machines feature which is currently In Preview at the time of this post.

Azure Machines

If you select preview for your Azure Machines and unable to detect an clients. You may need onboard your Azure VM https://docs.microsoft.com/en-us/azure/automation/automation-onboard-solutions-from-vm

Non-Aure Machines

Machines to update

In this sectrion, depending how you are providing your client machines into the Azure Portal, you can use one of the three Types to select your machines

  • Saved Searches
  • Imported groups (AD,WSUS,SCCM)
  • Machines
Machines to update

Update classifications

In this section, you can select 8 individual classifications based on your requirements.

  • Critical updates
  • Security updates
  • Update rollups
  • Feature packs
  • Service packs
  • Definition updates
  • Tools
  • Updates

Select the type of update classifications you would like to apply to your client machines.

Include/Exclude updates

In this section you can Include or Exclude particular Microsoft update using the KB number without the KB prefix.

Schedule settings

In this section, you can specify the require schedule whether its run once or needs to recurrence cycle.

Pre-scripts + Post-scripts

In this section, Pre-scripts and Post-scripts are tasks that can be automatically executed before or after an update deployment run. You can configure up to one Pre-script and Post-script per deployment.

Finishing touches

Maintenance Window – To set the maintenance window, the duration must be a minimum of 30 minutes and less than 6 hours.
The last 20 minutes of the maintenance window is dedicated for machine restart and any remaining updates will not be started once this interval is reached. In-progress updates will finish being applied

Reboot options – There are currently 4 reboot options available

  • Reboot if required
  • Never reboot
  • Always reboot
  • Only reboot – will not install updates

The Author – Blogabout.Cloud

What is Global VNet Peering?

What is Global VNet Peering?

Global VNet Peering? This function has recently come to my attention while working with an international customer who is in the process of integrating into their new owners Azure Active Directory. Global VNet peering enables resources in your virtual network to communicate across Azure regions privately through the Microsoft backbone. Resources communicate directly, without gateways, extra hops, or transit over the public internet. This allows a high-bandwidth, low-latency connection across peered virtual networks in different regions.

Example of Vnet Peering between Regions

You can use Global VNet Peering to share resources within a global, private network. You can then easily replicate data across regions for redundancy and disaster recovery.

In my case I was integrating the Active Directory Domains and using Azure Active Directory Connector located in primary region to synchronize the AD Objects from one domain into the other. This approach provided a quick and simply migration without really complexity.

Global Vnet Peering is only currently supported for the following regions.

  • Americas: West Central US (Wyoming), West US 2 (Washington), Central US (Iowa), US East 2 (Virginia), Canada Central (Toronto), Canada East (Quebec City)
  • Asia Pacific: Southeast Asia (Singapore) Korea South (Buscan), South India (Chennai), Central India (Pune), West India (Mumbai)
  • Europe: UK South (London), UK West (Cardiff), West Europe (Netherlands)

Cost of VNET Peering within the same region

Inbound data transfer $0.01 per GB
Outbound data transfer $0.01 per GB

Cost of Global VNET Peering

Zone 1Zone 2Zone 3US Gov
Inbound data transfer $0.035 per GB $0.09 per GB $0.16 per GB $0.044 per GB
Outbound data transfer $0.035 per GB $0.09 per GB $0.16 per GB $0.044 per GB

Virtual Network TAP preview

Virtual Network TAP is a feature that allows customers to enable mirroring of their virtual machine network traffic to a packet collector.

GlobalUS Gov
VTAP $0.0125 per hour $0.0125 per hour

IP addresses

Public IP addresses, and reserved IP addresses can be used in services running inside a virtual network. They carry a nominal charge as outlined here

VPN Gateways

A virtual network can have one or more VPN gateways to connect back to on-premises network or other virtual networks in Azure. The VPN Gateway is charged as detailed here

The Author – Blogabout.Cloud