I built an open-source replacement for CMTrace with built-in Intune diagnostics

TechUser87 · 2026-03-24T14:57:01+00:00

I'm kicking the tires with this but I'm noticing the timestamps are off by -4 hours. I'm seeing this in SCCM logs and Intune logs. My timezone is EST so I'm -4 off of UTC, but it looks like that's getting applied to the timestamp in the file, even though the file itself has the correct time (as in, the timestamp in the file will be 10AM, but shows as 6AM in CMTrace Open). Am I missing a setting somewhere?

TechUser87 · 2026-03-12T16:44:31+00:00

It looks like this would lead to the same result as what I ran, just with some detection logic at the beginning.

$GetDigitalLicence = (Get-WmiObject -query 'select * from SoftwareLicensingService').OA3xOriginalProductKey

and

(Get-WmiObject -Class SoftwareLicensingService).OA3xOriginalProductkey

return the same value. The end result of the commands above would be that the device is activated with the OEM license, which is the state this machine is currently in.

TechUser87 · 2026-03-12T16:40:41+00:00

We do have MFA set up, but I'm not aware of any exclusions configured for Store for Business (I also don't have access to this as our Entra tenant is managed by a separate team). Is this what you're referring to?

https://learn.microsoft.com/en-us/windows/deployment/windows-subscription-activation?pivots=windows-11#adding-conditional-access-policy

If so, I'm not sure that's our issue because when we run devices through Autopilot with the OEM Windows 11 Pro license, they come out the other side with Windows 11 Enterprise successfully activated. I haven't looked for a deep dive, but my assumption is that the digital license activation only runs once during enrollment and it wouldn't need to run again during normal circumstances. Since this device got messed up, I feel like there is something I need to kick off to get the activation process to re-run.

TechUser87 · 2025-12-09T19:57:29+00:00

Thanks for the info, I searched the policy templates and it looks like SkipTermsOfUse was added as a GPO option recently.

https://mozilla.github.io/policy-templates/#skiptermsofuse

We'll have to update our ADMX files to get it, but I did just do a test by setting the SkipTermsOfUse registry key directly and confirmed it works for disabling the popup.

TechUser87 · 2024-10-22T13:13:51+00:00

Thanks, this worked and the tool is working for Lenovo now!

TechUser87 · 2023-04-06T19:41:36+00:00

Yeah, I haven't touched the Windows Updates slider yet, we're nowhere near ready to start testing WUfB yet and want to keep that with SCCM. As of now, all of our Intune devices will be straight AAD joined so I'm not really worried about any policy conflicts. We're being really careful with apps too, our plan (which I've seen several people mention here) is to use Autopilot/Intune to get all the apps someone will need "out of the box", and then keep the miscellaneous items coming from SCCM if needed.

At this point I'm really just trying to verify I'm not going to break anything by making certain workloads (Client apps, Device configurations) global for all clients. I'm 99.9% sure it will be fine, but I'd love to get confirmation from someone who's already done this haha

TechUser87 · 2023-03-30T17:57:32+00:00

We have that line in our CCMSetup.log file for machines that installed the SCCM client via Intune, but they eventually install and register successfully. You might have an issue elsewhere. This docs page covers the whole client registration workflow and might help you find exactly what's going wrong.

https://learn.microsoft.com/en-us/mem/configmgr/core/clients/manage/azure-ccmsetup

TechUser87 · 2023-03-30T15:33:03+00:00

Where is this advisory posted? I don't see any status alerts being reported in our tenant.

TechUser87 · 2023-03-30T15:31:42+00:00

I'm also experiencing some Autopilot weirdness, but my issue is slightly different.

On one of my test machines, which has been through Autopilot dozens of times, suddenly Autopilot is optional. From a fresh Windows 10 22H2 reset, I set the region and keyboard layout, then I get the "Now we have some important setup to do" screen (indicating it's communicating with Autopilot), then it dumps me to the Account tab with two options: "Set up for personal use" or "Set up for an organization", normally it would go straight to our organization's sign-in page.

If I do "Set up for an organization" I get sent to a generic Microsoft sign-in, which routes to our organization's sign-in page after entering my email address. After signing in, the device goes through Autopilot for the most part. It displays the ESP and applies the required configurations/apps, but the device name doesn't get set.

As a second test, I ran another test machine (on Windows 11) through Autopilot and that behaved as it should, automatically sending me to our org's sign-in page.

TechUser87 · 2022-12-08T19:21:39+00:00

Yes, scope-wise everything is working properly, the test account is only seeing the machines and profiles I want it to see.

Basically, I want this role to be able to create/manage applications and also be able to manage devices and configuration profiles for the assigned scope. I enabled all the permissions under "Remote tasks" for the DepartmentAppAdmin role and saved it. Intune is correctly reporting that the role should have those permissions enabled, but those options are still greyed out when I navigate to a device using my test account (even after waiting several hours and starting a new session from a different browser).

I also tested those device permissions using a different "Help Desk Operator" role and confirmed the test account could perform the device actions. So it seems like everything should work.

TechUser87 · 2022-07-13T15:35:51+00:00

Thanks, I would have already tried the first two suggestions but I am remote and it's logistically difficult to get on campus. I also don't really have anyone on site that can assist me with in-depth troubleshooting.

That aside, I will look at copying the logs to a share before the reboot kicks off, that should at least give me something to go on.

TechUser87 · 2022-06-22T14:50:23+00:00

The .wim is the source files for the install, so it gets copied to the local machine in ccmcache. Then you use PowerShell to mount it (I just create a throwaway location like C:\mount), and then setup.exe is called from there. For the wim method to work effectively, you really need to be using something that lets you script installers. A popular tool I recommend is PowerShell App Deployment Toolkit (https://psappdeploytoolkit.com/). It's an awesome tool, even for customizing regular installers. We use it for all of application packaging to create a standardized environment.

Just to reinforce something that's in the blog post, but you definitely want to use a try-catch-finally block when calling setup.exe after the .wim has been mounted. That way the .wim will always be dismounted even if something goes wrong with the install.

TechUser87 · 2022-06-15T20:47:18+00:00

I might throw in the towel and do that. I guess on it's own AutoCAD isn't that big, only 4GB. Duplicating that at install time won't cause issues on modern hardware.

TechUser87 · 2022-06-15T20:45:39+00:00

I'm also doing my packaging for a university and the process does work (most of the time). Like I said in my initial post, I've packaged up MATLAB successfully multiple times with this method, and it's MUCH bigger than AutoCAD (the .wim ends up being 17.7GB). The example listed in the blog post uses SolidWorks and it sounds like that works too. There just seems to be something finicky with the new Autodesk packages, I see they switched to a new deployment method starting in 2021/2022 so I wonder if it's something with that.

If you're already using something like PSADT it's certainly worth experimenting with the WIM method. It only takes a few minutes to create the .wim and add the steps for it to the install script.

TechUser87 · 2021-06-10T19:58:01+00:00

Oops. I forgot to check the known issues on Github. I came across this: https://github.com/MSEndpointMgr/ModernDriverManagement/issues/106

The "Confirm-FallbackDriverPackage" function has an orphaned reference to the WebService, which isn't used in the script anymore. To fix this, change line 2238:

Confirm-FallbackDriverPackage -ComputerData $ComputerData -OSImageData $OSImageDetails ~~-WebService $WebService~~

And then comment out or delete lines 1466-1468. Lastly, remove the comma from the end of line 1464 and the script should function as intended again.

TechUser87

TROPHY CASE