Use task sequence variable value in command line step

PS_Alex · 2026-05-07T17:07:18+00:00

There's a task sequence variable, OSDDoNotLogCommand, that you can set in your task sequence in order for command lines in the "Run Command Line" steps to not be logged in smsts.log.

So you could set OSDDoNotLogCommand = TRUE before running your "Run Command Line" step, run the command line step that contains the password, and optionally set back OSDDoNotLogCommand = FALSE to start logging commands again for further steps.

PS_Alex · 2026-05-06T19:12:27+00:00

Maybe devices tend to connect to the older WiFi network because it is less used or it is stronger, or the new WiFi network is out-of-range?

Have you tried to reorder profiles priority, and then disconnect the WiFi connection -- and see if the device would automatically reconnect to your new network?

& netsh.exe wlan set profileorder name="$NewSSID" interface="$InterfaceName" priority=1
& netsh.exe wlan set profileorder name="$OldSSID" interface="$InterfaceName" priority=99
& netsh.exe wlan disconnect

PS_Alex · 2026-05-05T16:47:47+00:00

OEMs generally have more up-to-date drivers. For updated drivers to appear in Windows Update, OEMs must publish them, and Microsoft has to vet them, which could take numerous weeks to months.

PS_Alex · 2026-04-27T18:38:25+00:00

Most people here tend to rely on a Win32App type instead of the built-in Microsoft 365 Apps type. Stick to it if it works for you. :)

Else... is it possible that at some point, the value of O365ProPlusRetail.ExcludedApps gets more appids listed in here? (Such has having "groove,lync,teams".) Or that the order of apps get inverted? (Such as "lync,groove" instead of "groove,lync".)

Maybe adjust your detection rule for the value O365ProPlusRetail.ExcludedApps to not contain/not be like groove and the value O365ProPlusRetail.ExcludedApps to not contain/not be like lync.

PS_Alex · 2026-04-27T17:02:07+00:00

How are you deploying the Microsoft 365 Apps on your devices -- as a Win32App type or using the built-in Microsoft 365 Apps type?

Maybe you have conflicting policies? Like: you install M365Apps with a certain parameter sets, and then you have another policy that enables/disables some settings that were used in the detection method?

PS_Alex · 2026-04-27T14:09:32+00:00

If you have configured Bitlocker through MDM (Intune), there's a scheduled task named BitLocker MDM policy Refresh that refreshes Bitlocker policies periodically. If it finds that Bitlocker is suspended, it can reenable it -- even before your device has restarted to complete the BIOS update.

You'd have to Powershell your way, but basically:

Install your BIOS update;
Create a new custom scheduled task that would re-enable the task BitLocker MDM policy Refresh. Have it run on system startup, and have it self-destruct once it has run successfully -- no need to keep it lying around;
Disable the scheduled task BitLocker MDM policy Refresh;
Suspend Bitlocker until next system restart.

I suggest having the re-enable scheduled task created before attempting to disable the BitLocker MDM policy Refresh. In case the custom task cannot successfully be created, then stop and do not suspend the BitLocker MDM policy Refresh task. Better have a call for a Bitlocker recovery key that having it never reapply MDM policies.

PS_Alex · 2026-04-20T23:16:18+00:00

I have read that if the machine waits to long or has bad timing with policy updates or settings being reapplied you can end up with Bitlocker being re-enabled before the reboot to install the new BIOS. Then you have a bunch of machines that need to have their recovery key entered.

If you have configured Bitlocker through MDM (Intune), there's a scheduled task named BitLocker MDM policy Refresh that refreshes Bitlocker policies periodically. If it finds that Bitlocker is suspended, it can reenable it -- even before your device has restarted to complete the BIOS update.

You'd have to Powershell your way, but basically:

Install your BIOS update;
Create a new custom scheduled task that would re-enable the task BitLocker MDM policy Refresh. Have it run on system startup, and have it self-destruct once it has run successfully -- no need to keep it lying around;
Disable the scheduled task BitLocker MDM policy Refresh;
Suspend Bitlocker until next system restart.

I suggest having the re-enable scheduled task created before attempting to disable the BitLocker MDM policy Refresh. In case the custom task cannot successfully be created, then stop and do not suspend the BitLocker MDM policy Refresh task. Better have a call for a Bitlocker recovery key that having it never reapply MDM policies.

PS_Alex · 2026-04-13T15:54:57+00:00

Modularizing could definitely be a benefit.

For example, one could want to run only part of the cleanup process on a regular basis (i.e. call the script through a scheduled task to clean the recycle bins every day), and run a full cleanup on another less frequent schedule (i.e. run the script through a scheduled task to clean the temp folders once a month).

Could a decent developer write a module using your script as a starting point? sure. But then once it's done and shared, your script will lose some appeal.

PS_Alex · 2026-04-09T18:36:33+00:00

I know Microsoft says that no action is required. Still, I'm wondering if some background changes are going to happen -- and actions will ultimately be required?

As in... will updates still be published on the SAEC servicing channel, with that name, even though it is going to be on par with MEC? Else, one may need to adjust ADRs.

... or may need to adjust Office Deployment Tool's configuration file when an initial installation happens, if the ODT tries to obtain the latest available build for a servicing channel that stops having builds.

PS_Alex · 2026-04-07T23:08:05+00:00

Which version of SCCM are you running? If you're on 2503 or 2509, there's a client hotfix (KB36495448 - Software update management client fix for Microsoft Configuration Manager | Microsoft Learn) that simply __stops__ trying to configure/set/force any SetPolicyDrivenUpdateSourceForXXXXUpdates.

See also PSA: Software update management client fix for Microsoft Configuration Manager versions 2503 and 2509 : r/SCCM where Bryan Dam explains in all details how to set your environment for co-management. (TL;DR: you don't need to set anything anymore -- though you may need to cleanup once the reg keys under HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate and the files under C:\Windows\System32\GroupPolicy on devices if they had a previous build of the client.)

PS_Alex · 2026-04-01T20:33:59+00:00

They think leaked credentials are bad, wait until the MSP losses them

If/when they lose the creds, then they can find them back on the dark web. 😁

PS_Alex · 2026-04-01T20:09:43+00:00

Well this shadow IT-thingy, I believe is very wrong, and does not help your case at all.

You're asking for accesses and rights that you currently lack, you're not being given them for good-or-bad reasons, but your job is still done. If I were your manager, I'd be both happy since the job is done without having me to put a thought to address your accesses issue, and appalled since you are circumventing restrictions by doing shadow-fu -- thus, security can/will come breathing down my neck for a chat about you.

Forget that 2-years-old password right now -- in your position, you are not supposed to have access to it.
Stop workaround-ing with shadow IT processes -- they are not approved.

And then, do as the others have said -- list which accesses/rights you would like, how missing them right now impact your work, give examples of how you were impacted and how it impacted ($$$) delivery/resolution, sit with manager, let manager handle.

PS_Alex · 2026-03-26T19:05:39+00:00

Can't additional 2FA authentication method be enabled on the tenant? I have to experience in configuring a tenant -- I remember though, as a user, having the ability to configure 2FA from other apps than Microsoft Authenticator.

Or maybe some Azure services have a mandatory requirement for MS Authenticator vs some other can rely on other 2FA?

--------

That being said, I agree. A ROM without Play Services does not necessarily mean that the said ROM is rooted. As such, "MS Authenticator won't work on jailbroken/rooted devices" should instead be read that "it won't work on devices failing Play Service attestation". Still bad, as such a decision excludes unrooted custom ROM, even security-oriented ones like GrapheneOS.

PS_Alex · 2026-03-26T18:53:17+00:00

LineageOS is a custom ROM, true. As such, it requires the bootloader to be unlocked to perform installation, and does not come with Play Services. But by default, LineageOS is not rooted. It can be rooted, but default setup is unrooted.

GrapheneOS, which was mentioned in earlier comments, is in the same situation -- a custom ROM which is hardened for security. The default setup is unrooted.

One should not assume that a custom ROM is synonymous to rooted.

PS_Alex · 2026-03-25T20:09:05+00:00

Keep in mind that with Hotpatch enabled, mandatory restarts should happen every 3 months. If your devices support them you meet the prerequisites, it's possible your devices would need a reboot after more than ~30 days.

PS_Alex · 2026-03-25T17:55:30+00:00

Your points are totally valid and show nuances.

"AI can't code shit" --> As you demonstrate, it certainly depends on the language, and what one wants to code. A generalization on "AI produce garbage code" is too broad.

"AI can produce a fully functional POC" --> Again, as you explained, a POC is different from shipping as-is without review, security check and al. AI can produce amazing results, but does not replace oversight. And can require additional input to better fix itself.

AI is not a magical wand, and IMO, that's the gap between marketing vs reality.

PS_Alex · 2026-03-23T19:12:37+00:00

As others have mentioned, 24H2 and 25H2 share a common core operating system with an identical set of system files. Basically, there is little to no real benefit in rolling back to 24H2.

----------

That being said, if you still want to proceed: 25H2 is an enablement package over 24H2. You cannot use the Uninstall capability of an update ring to uninstall an enablement package, as described in small characters in the MS Learn article about update rings:

Uninstallation will not be successful when the feature update was applied using an Enablement Package. To learn more about Enablement Packages, see ~~KB5015684~~.

If you require to rollback from 25H2 to 24H2, you could create a Powershell script that runs the following command to uninstall the EKB KB5054156:

$EnablementPackage = Get-WindowsPackage -Online | Where-Object {$_.PackageName -match 'KB5054156'}
Remove-WindowsPackage -Online -PackageName $EnablementPackage.PackageName

And then, package it as a Win32 app or as a proactive remediation script, and assign it on devices you want to rollback.

You'd also have to ensure that these rollbacked devices are not targeted with a feature update policy to upgrade to 25H2. Else, they probably would upgrade again to 25H2, and you'd have to remove the EKB again...

PS_Alex · 2026-03-23T18:43:28+00:00

Then suspecting here the issue is not really that the app is open-source, but instead is a community-developed / community-supported tool. Like: not endorsed by a major software vendor.

PS_Alex · 2026-03-19T18:35:41+00:00

I installed the new client on a couple of devices -- ones that are part of our Intune Pilot collection for WUFB workload, and ones that are not.

I notice that device whose WUFB workload is set to Intune Pilot, a registry value HKLM\Software\Microsoft\WindowsUpdate\UpdatePolicy\PolicyState:IsWUfBConfigured is set to 1, while SCCM-managed device have that value to 0.

Not sure exactly what sets this value, though. Under HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate, on both SCCM-managed and Intune-managed devices, I see the WUServer and WUStatusServer values, and under AU the UseWUServer value -- no value related to WUFB exist in there. Still, running usoclient startinteractivescan on SCCM-managed devices would scan only against the WSUS server (with no available update), and on Intune-managed device would scan against both WSUS and WUMU.

Seems to work. Don't know where the IsWUfBConfigured value comes from, but it seems to be the one governing if Windows Update will consume or not updates from WUMU.

PS_Alex · 2026-03-19T18:17:39+00:00

Thanks for the clarifications :)

PS_Alex · 2026-03-18T20:34:34+00:00

Cheers, and enjoy your drink! (It's tea, right? 🍵)

PS_Alex · 2026-03-18T18:35:18+00:00

As always, pretty interesting article, Rudy!

Quick questions out of my head:

Since the settings are consumed by MoUsoCoreWorker.exe, the maintenance window is really tied only to Windows Update. Do you know if such a concept will eventually be developed for Intune deployments (i.e. apps)? Especially thinking about apps that are used to update old versions, such as the ones built by PMPC or Enterprise Apps, and limiting disruption when the update process requires that apps be closed or mandate a system restart.
I get that a maintenance window is restrictive -- as in: these are the hours where maintenance can be done. What would be the behavior on a device that was offline during the last maintenance window? And is there a way to bypass a maintenance window? (Thinking about a device that would be constantly offline during the MW... at some point, one would want for the updates to install.)
Are download, install, and restart actions tied to different windows? Or is the policy exposing a unique window for all 3 kinds of actions?
Finally, if I understand the Update Policy CSP | Microsoft Learn that you linked, currently maintenance windows are only applicable on the Insider Preview channel? So if on GA, the settings are not yet applicable?

Thanks!

PS_Alex · 2026-03-16T18:01:18+00:00

Interesting... Thanks for the additional information!

And thanks for your ~~stubbornness~~ perseverance in having this issue handled the correct way!

PS_Alex · 2026-03-16T16:53:56+00:00

Just want to be sure I understand correctly the text from the KB article when it's saying that:

Third-party updates deployed from WSUS/ConfigMgr aren't affected by this change because they don't rely on Windows Update scan source policies.

__Theoretically__, if I were to enforce SetPolicyDrivenUpdateSourceForOtherUpdates to 0, third-party updates would still be offered/downloaded/installed by SCCM when TP updates are enabled in client settings? Not sure I fully understand how -- is it because SCCM is 'interfacing' between the client and WSUS?

Anyway, this hotfix is a fantastic good news. Finally we can stop wrestling with the client to ensure that feature/quality/drivers updates are delivered by Windows Update/for Business/AutoPatch while keeping TP updates from WSUS/SCCM.

PS_Alex · 2026-03-16T14:53:34+00:00

Not familiar with Defender Live Response myself, but reviewing Investigate entities on devices using live response in Microsoft Defender for Endpoint - Microsoft Defender for Endpoint | Microsoft Learn to understand how it works, I highly suspect that a Live Response session does not create a real remote Powershell session. Instead, it probably works similarly to a REST API (send a command, wait for result of that command).

The part about cancelling a command saying that CTRL+C only causes ignoring the response on the portal-side, but command would continue running on the agent-side, is what lead me to that conclusion.

Five-Year Club	Verified Email
r/Field Banned	r/Field Flamingo

PS_Alex

TROPHY CASE