Ever wondered how you can kick off a manual or automatic sync of your Intune policies from a PowerShell script?
Not long ago I ran into the need to have policies applied to new devices, a lot quicker than what a normal enrollment does.
Because I had multiple users on shared computers, and a lot of roaming going on, I needed the user enrollment process to be as snappy as possible, but most times it would fail to apply all user policies in the first go, and a reboot might have solved it, but that was unacceptable in this case.
UPDATE 29 sept. 2019
Michael Niehaus (@mniehaus) has answered my prayers for feedback, and boy does he deliver!
In his blog post “Forcing an MDM sync from a Windows 10 client“, Niehaus walks us through his investigation methods, and ends up with a one-liner that solves this whole issue completely.
I will leave the solution below as-is, because it also works from the users context without requiring extra permissions.
Though I have yet to find a good use for this, someone else might…
I would say, that even if you don’t have the need for this solution – any one that feels like they are an Microsoft IT Pro, should read the post.
The current limitations
So at the moment the only GUI methods that exist to “force” a sync of your policies, is by using the sync button from within the Intune portal, or from the client – by using the sync button in the Company Portal app or the Work and School account settings page.
And when I say “force”, I really mean that it will only look for missing or updated policies that haven’t applied – No built-in method exists to have all policies re-evaluate and re-apply.
It is possible to delete the policies and have them reapply by using PowerShell, but that’s not the subject of this article.
The path forward
Keeping in mind that I am working from a pure Intune perspective here (no ConfigMgr available), there was only one course I could see ahead of me, and that was to come up with a PowerShell solution. So this article is really just to tell you it can be done, and I have the Proof-Of-Concept running in production today with good results.
And since it’s not that complex a script, I suggest you read it through from start to end, to really understand what’s going on, as I don’t recommend implementing workarounds like this without fully understanding what it is and does.
Why you might need this workaround
Well as I said, I needed it for a shared PC scenario, but you might also just want to avoid too many reboots during first enrollment, or to further automate your deployment sequence. In any case, I thought I would share it, at least for inspiration and feedback from the community (please use GitHub for code feedback / bugs / updates).
So this script essentially does the following:
- Checks for the Microsoft.Graph.Intune PowerShell Module.
- Installs / Imports the module.
- Connects to the Intune Graph.
- Finds the Device ID based on the hostname of the device you are executing on.
- Tells Intune to start syncing policies for said device.
The prerequisites for this to have any chance of working, is that you grant admin consent by running the following bits of PowerShell on your own Windows PC, form an elevated PowerShell prompt.
Install-Module -Name Microsoft.Graph.Intune Import-Module -Name Microsoft.Graph.Intune Connect-MSGraph -AdminConsent
If you are unfamiliar with the term “Admin Consent”, I strongly suggest that you read up on it, because this will be come more prevalent in future app´s. Here is a good resource from the creators of all that is holy to us: Admin consent experience
Next thing to do, is download the script and read my suggestions for deployment if you want inspiration. I am sure you will come up with other good ways to use this, so please share those in the comments section for others to read.
Here are a few methods for deploying this, and what I ended up doing in my scenario (spoiler: it’s not very pretty).
- Deployed as a Device Configuration PowerShell script assigned to the user.
- This will run only the first time a user logs on, but might not be effective enough if you have many policies etc.
- Try throwing a DO WHILE loop into the mix that iterates through the script a few times with a few minutes of sleep time in between the iterations.
- Deployed through GPO as a logon script.
- This will run every single time a user logs on to the machine, so you might want to place a cookie somewhere on the device to stop it from running all the time.
I ended up with the GPO, since I also had some lingering Group Policies that needed to be forced onto the machine right after a refresh, so I slammed in a “gpupdate /force” and just made the script switch back and forth between the gpupdate and the Intune sync, with a minute of waiting in between.
This works like a charm on newly deployed machines, not only shared computers, and it saves me a reboot or two.
Though for newly deployed machines I just put it in as part of the initial deployment sequence.
But it is ugly as hell, and I might get throttled by Microsoft if I deploy too many machines that try to force a policy sync this often – tho it has yet to be seen.
Try it out and have fun with it.
Michael works as a Cloud Architect with APENTO in Denmark. Specializing in customer journeys from classic Infrastructure to Cloud consumption.
He has been in the IT industry for more than 20 years, and has experience from a broad range of IT projects.
When not at work, Michael enjoys the value of spending time with family and friends, and BLOG’s passionately about Enterprise Mobility whenever he has time to spare.