I am currently working on a new project involving the integration and configuration of Microsoft Intune in a hybrid environment.
Since there are always the same tasks in this scenario, I have now written a PowerShell script that processes the most important recurring tasks.
This way I can ensure that certain configurations are standardized for all customers.

In this blog article I present and explain my script:

What are the tasks that are done by the script?

  • Creates licence groups
  • Creates permission groups
  • Creates an on-premise AD user
  • Creates OU for required GPO’s
  • Creates a GPO for MDM enrollment
  • Creates a GPO for SCP
  • Creates a GPO for MDM unenrollment
  • Creates an additional REG Key in MDM enrollment for triggering second script to run the schedule task for MDM
  • Creates an additional REG Key in MDM enrollment for adding the LAN Domain to Secure Sites
  • Creates an additional REG Key in MDM enrollment for adding the Domain controller IP to secure Sites
  • Creates an additional REG Key in MDM enrollment for one time running additional script (More about it, later in this article)
  • Starts sync between on-premise AD and Azure Active Directory
  • Creates dynamic groups for devices in Azure Active Directory
  • Creates an Azure Active Directory user with Intune Administrator permission
  • Licence Assignments


  • (OPTIONAL) Installs PowerShell Module MSOL
  • (OPTIONAL) Installs PowerShell Modules Azure


What is not configured with this script?

  • Installation and configuration AAD Connect
  • Configuration AAD sync
  • Advanced AAD Connect configurations
  • Autopilot Configuration
  • Intune App configurations
  • Tenant customisations


Here the Script Documentation:

With my script, nothing has to be adapted beforehand. The script can simply be executed, all required information is requested during the execution of the script.


In the first phase, the following information is requested and must be entered manually in the script:

  • Local domain.
  • OU where the test user will be created.
  • OU where the licence groups are to be created.
  • OU where the groups for the permissions are to be created.
  • The own Onmicrosoft domain.
In this step, a directory is created. This can be found under C:\MDM. The log file of this script is also stored in this directory.
The next step is to create a password for our Local Test Account. I use this for testing configurations, autopilot, etc.
Next, the licence groups are created.
Then the authorisation groups are created.
It is important to note that the AAD synchronisation must be configured beforehand (or afterwards) so that these groups also appear in the Azure Active Directory.
Now the required OU’s and GPO’s are created.


In my experience, the Automatic MDM enrolment and SCP GPO are needed for a hybrid enrolment. However, I also create an OU with the GPO with the value unenrolled for my customer.


According to the Microsoft Technet article, the corresponding GPO can also simply be configured as an ADMX template, but in my script I have decided to configure the corresponding settings directly via registry key.

The next step checks whether the PowerShell module “ADSYNC” is available. If this is the case, a pause of 10 seconds is set first. This is so that any domain controller synchronisation can be carried out. Then an AD sync (delta) is started so that the created groups and users are synced into the Azure Active Directory.

When this command has been issued, another pause of 30 seconds is performed. This second pause gives the AAD sync enough time to sync the created objects into the Azure Active Directory.

The next step is to log on to the Microsoft 365 tenant. Here, too, we first check whether the required Powershell module is available. If this is not the case, the corresponding PowerShell module is installed.
In the next step, the script creates a cloud-only account which I need for administrative purposes for the endpoint portal. Therefore, a pop-up for the password entry for this user account also follows here.
The Cloud only user account just created is promoted to Intune Administrator.
Now a connection to the Azure AD PowerShell module is created. If this does not exist, it will be installed automatically.
The next step is to create 5 dynamic groups in the Azure Active Directory. These are configured so that the different device types can be distinguished. In this script I distinguish between:

  • Microsoft Surface
  • Lenovo
  • HP
  • Dell
  • Intel
In the next step, the licence assgnments are made. The licence groups created and synced to begin are assigned via PowerShell according to the licences.


ATTENTION: The script requires that the licences have been procured via a CSP.



The result:

When the script has run successfully, we have the following result


As we can see, in the OU’s we defined, the different groups and sub OU’s were created.
We also see that our SVC_DW_USER was created in the on-premise Active Directory.
In Group Policy Management, we see that the required GPOs have been created and linked.
The values are also set correctly in the content (here as an example the SCP GPO).
When we go into the Microsoft 365 portal, we see the on-premise user SVC_DW_USER which has already been synced to the cloud.


We also see our SVC_DW_ADMIN account in our tenant.

(By the way: I usually create my admins online and also use the onmicrosoft domain. As you can see in the print screen, the USER and ADMIN account also differ in the domain used).

If we take a closer look at our SVC_DW_ADMIN, we can see that this account has also been promoted as Intune Administrator.
If we now go further into the Azure Portal, we find that here too the groups are already synced from on-premise to the cloud.

(Please note that the Azure ADConnect must first be configured accordingly. Otherwise, of course, this sync will not work).

In addition to the groups synced from on premise, we also see that our dynamic cloud only device groups are present.
Finally, here is a more in-depth look at our licence groups. As you can see, existing licences are already assigned accordingly.

(Please note that all apps of a licence are activated by default and the users must also be assigned to the groups accordingly).


Download the Powershell Script:

You can find the PowerShell Script on my Github Page.


Further information:

The script is basically self-contained, but there is a task that automatically downloads another Powershell script from Github.
This is a small script that is to be executed on the client computer. This script checks if the schedule task “PushLaunch” is available, if not, this task will be created.
This task triggers the MDM enrolment.


This subscript is stored under the following path:


The subscript itself looks like this:

#Create Schedule Task
Get-ScheduledTask -TaskName "PushLaunch" -ErrorAction SilentlyContinue -OutVariable task

if (!$task) {
$taskname = "PushLaunch"
$taskdescription = "Initialize MDM Enrollment by Task Scheduler"
$action = New-ScheduledTaskAction -Execute 'C:\Windows\System32\DeviceEnroller.exe' -Argument '/c /AutoenrollMDM'
$trigger = New-ScheduledTaskTrigger -AtLogOn 
$settings = New-ScheduledTaskSettingsSet
$path = "\Microsoft\Windows\EnterpriseMgmt"
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName $taskname -Description $taskdescription -Settings $settings -User "System" -TaskPath $path
} else {
Write-Host "$task already exists - no further action needed!" -ForegroundColor Green


Would you like to see more?

You can have it!
I have prepared a short video where I run through the script and explain everything again.



Second (video) part

In the second part we see how the deployment of a new client computer looks like after Intune has been pre-configured with my script.
Here again the hint that a second script (as described above) is downloaded from Github. This script will be copied into the NETLOGON directory after the successful download. So that we can use this script when logging in, 2 entries are set under Internet Options. These are read out by variable and then entered. It is visible transparently in the video.


Follow up

After all configurations are prepared, the tenant has to be configured. This means that the packages have to be packaged and (depending on the area of application) the baselines have to be adapted. Furthermore, the users have to be filled into the corresponding groups created by the script and the groups have to be assigned to the respective Intune configuration.

I am currently planning a script for this as well, but it will take a while before I put it online.


I hope this helps you guys with some future deployments.