This blog will be about why it’s important to automate your Microsoft 365 deployments.
Today I was called in to investigate a weird problem. A colleague was trying to set up Intune for a new Microsoft 365 customer. In a normal situation we are doing this by launching our deployment scripts but this time a new colleague wanted to see which steps need to be taken to enroll a customer into Microsoft 365.
Everything was going fine until the enrollment restrictions part. Configuring enrollment restrictions needs to be configured to make sure no Personally owned devices can be enrolled or to block android device administrators. When you are only deploying devices with autopilot, it’s always smart to block the possibility to enroll personally owned devices.
But the option to edit the policy as I show below, was missing? I was like: Huh? Did I lose my sight?
Okay? No option to edit the existing policy, let’s try to create a new enrollment restriction policy.
As shown above, it’s greyed out? After spending a few minutes on google, I found out the MDM authority needs to be configured. When this option is not configured, there is no option to create or edit an enrollment restriction policy. Let’s see what Microsoft has to say about how this needs to be configured.
But within this tenant, no orange banner was shown. And the possibility to configure it, within the Azure Ad portal and opening Intune is obviously gone as this old Intune azure portal is depreciated.
You can guess which option we have got left: PowerShell!!! I quickly realized this configuration is part of our deployment script. So I opened our Tenant deployment script… and there it was, at step 2A: Configure Intune as MDM authority.
I fired up a PowerShell prompt and copy-pasted the script. After refreshing the enrollment restriction page the options to create or edit the restrictions were instantly available.
Changing the MDM authority to Intune will also solve the issue when you could not configure or change the ESP page because the button is also greyed out.
I guess I say this quite a lot, but automating your processes will ensure all options are configured with no human errors. Of course, you will need to make sure everyone knows what the script does, only firing up a PowerShell script with no background knowledge is stupid.