Forum Discussion
Is it really impossible to force an Intune sync from the command line?
Is it really not possible to force an Intune sync on a client computer from the command line? It seems like such a simple thing to do. Rather than make me dig 3 subpages deep to click a button, just let me fire off a DOS command and get on with my day.
I'm familiar with the MS-Graph method, but honestly, clicking a "Sync" button should never be as complicated as that.
I'm also familiar with Michael Neihaus' method...
Get-ScheduledTask | ? {$_.TaskName -eq 'PushLaunch'} | Start-ScheduledTask
That has never worked, but don't tell anyone because there are a lot of admins out there who think it does, and I'd hate to spoil their day.
Am I just too dim to figure this out or is there really no way to sync from a CLI?
Thanks,
- Thanks for the replies. It's much appreciated. The situation is that I have a population of emergency-use computers that stay asleep most of the time. To get updates, I need to wake them and manually trigger the updates myself. I can do this easily enough sending DOS and PowerShell commands through my RMM's backend. Or at least, I can do everything but force an Intune sync. For that, I have to remote in, enter a password, navigate the GUI, etc. It just doesn't seem like it should be that hard.
As I said before, the MS Graph method is more work than remoting in, so not worth the bother.
With regard to restarting the Service, that doesn't work. If you dig into Settings and click the Sync button, you will see the "Host process for OMA-DM client" pop up in the Task Manager. Restarting the service (or using the Niehaus method) does not get that process to fire. Until it does, the changes I need never happen.
The only way I've found reliably to get the Host process to fire is to click the Sync button, or reboot the computer. Both require me to remote in and deal with the GUI. Is there really no way to avoid that? It seems like a monumental oversight.I found out a way to do it. Triggering the ‘PushLaunch’ scheduled task doesn’t seem to actually perform a MDM sync like when the user selects ‘Sync’ in Company Portal settings or the ‘Access Work or School’ page in settings, as you’ve said. At least not when the user is only a standard user (ie, not an admin).
After some digging, I found that performing the command found in the actions part of the ‘Schedule #3’ Intune scheduled task. This seemed to be the only way I could get a proper MDM sync to work in a way that can be run as an administrator (ie, via PDQ or RMM) with the signed in and licenced user being a standard user.
Because the enrollment ID is different per machine, I added a one-liner to pull the ID from the Scheduled Task path on the machine and then use it in the deviceenroller.exe command.
The script:
$EnrollmentID = Get-ScheduledTask | Where-Object { $_.TaskPath -like "*Microsoft*Windows*EnterpriseMgmt\*" } | Select-Object -ExpandProperty TaskPath -Unique | Where-Object { $_ -like "*-*-*" } | Split-Path -Leaf Start-Process -FilePath "C:\Windows\system32\deviceenroller.exe" -Wait -ArgumentList "/o $EnrollmentID /c /b"I hope it helps someone else out.
To confirm this, run the script against a machine with task manager open and you can see the omadmclient.exe process running, just as it does when using the ‘Sync’ GUI button. This doesn’t happen when restarting IME or triggering the ‘PushLaunch’ task (not when the user is a standard user anyway).
- This worked perfect as far as I can tell. Much simpler than the suggestion below you. Kind of ridiculous that there isn't some built-in command to do this but I suppose it is Microsoft we're dealing with.
- To launch that task, you need to have permissions to access it of course... besides launching the task itself you could always just restart the IME service or trigger the ime to sync the device?
$Shell = New-Object -ComObject Shell.Application
$Shell.open("intunemanagementextension://syncapp")- Thanks, Rudy. I've tried running that as both the User and the Admin. While it does launch a few processes, the OMA-DM process is not one of them. Is it working differently in your environment?
- our machines are no longer on the domain, but personally I think with the machines being in sleep mode depending on how often, lets assume hotdesk users logon to them every so often based on their shifts, there's obviously a risk the machine goes out of compliance if its not been on for 8 hours or so, so maybe just send a sync via PowerShell on schedule every 30 minutes or less. unless ur saying some machines are not switched back on by end users for a long time say 1 week to 3 weeks or more even, in that case might have to look into remote powerup
- i guess you could restart the intune service from command line instead? its the same as doing a "device sync status" sync, under work or school settings
MANAGING INTUNE WITH POWERSHELL - TFTD I've used his cmdlets in powershell and it works
I think I'm going to tackle this a different way. Since the only reliable method to force an Intune sync is with a reboot, I'll just make that part of my process now. It's easy to force a reboot in the CLI (shutdown /r, or Restart-Computer). The problem comes with logging back in. That still requires the GUI. However, you can leverage the Windows Logon Options section of local Group Policy to automatically log in and lock a computer following a reboot or power-on event. There isn't a way to modify local Group Policy settings via Intune or even PowerShell (that I've yet found) for cloud-only shops, so this is a one-by-one modification using the GUI. Of course, every log in after a reboot is a one-by-one affair using the GUI as well, so this change is well worth the frustration. I'll test out my hypothesis on some devices and see how it goes.
Thanks everyone.
- Yeah, that didn't work. I think I have an Intune policy blocking the change. I just need to figure out which policy it is. So still working on this.
I think I figured it out. For future Bing searchers, the feature is called Windows Automatic Restart Sign On (ARSO). It works as you might expect. Make your Intune policy changes, then fire off a restart command to the endpoint(s) using your RMM, PowerShell or whatever CLI you use. After the login screen comes up, the computer quietly logs in, behind the scenes, using the last logged-in user's credentials. Intune policies sync, Windows Updates finish, Teams launches, startup apps load, etc. The user comes in the next morning and logs in instantaneously to a fully loaded Windows desktop, as if the computer had been locked all along.
ARSO is set by either a Local Group Policy, a Domain Group Policy or a registry hack. All can be accomplished via Intune. There is a mix of various requirements that need to be met before it will truly work, however. These include Bitlocker and/or TPM 2.0.
This link explains ARSO, its requirements, and how to set it up: Winlogon automatic restart sign-on (ARSO) | Microsoft Learn. It excludes any discussion of ARSO via Intune, however.
This link shows how to enable ARSO via Intune (kinda): Winlogon automatic restart sign-on (ARSO) | Microsoft Learn. The link actually shows how to disable ARSO, but you can use the same policy to enable it. The policy changes a Local Group Policy setting on each device that enables ARSO if the other requirements (Bitlocker, TPM 2.0, etc.) are met. (I was wrong about not being able to set Local Group Policy via Intune. This link shows where in Intune those settings are hiding. Yay!)
So the answer is that you CAN force an Intune sync exclusively via CLI, if you stand back a few paces, squint your eyes and fiddle around some.
Hope that helps someone.
- **CMD Commands:**
- (Stop and Start Intune Service using CMD commands: **`sc stop IntuneManagementExtension`** and **`sc start IntuneManagementExtension`**) - **PowerShell Commands (Manual Both):**
- (Stop and Start Intune Service using PowerShell commands: **`Stop-Service -Name IntuneManagementExtension`** and **`Start-Service -Name IntuneManagementExtension`**)
- (Simply Restart the service “**`IntuneManagementExtension`**” or PowerShell **`restart-Service -Name IntuneManagementExtension`**
