DEV Community: Anthony Buhnerkemper

Automating Configuration Manager (SCCM) client actions with PowerShell

Anthony Buhnerkemper — Sat, 10 Oct 2026 23:09:11 +0000

If you've supported Configuration Manager for any length of time, you know the routine: someone deploys something, a user can't see it in Software Center, and the first answer is "run Machine Policy Retrieval and wait a few minutes." Doing that by remoting into each machine and clicking through the Configuration Manager control panel applet doesn't scale past a handful of devices.

Every one of those buttons is just a WMI method call, so PowerShell can do it for one machine or five thousand. The scripts in this post are in my open-source configmgr-powershell-toolkit on GitHub, also available as a module on the PowerShell Gallery:

Install-Module ConfigMgrAdminToolkit -Scope CurrentUser

How client actions work

Each action in the client's Actions tab maps to a schedule ID, a GUID. You fire it with the static TriggerSchedule method on the SMS_Client class in the client's root\ccm namespace:

Invoke-CimMethod -ComputerName PC01 -Namespace root\ccm -ClassName SMS_Client `
    -MethodName TriggerSchedule -Arguments @{ sScheduleID = '{00000000-0000-0000-0000-000000000021}' }

That's the whole trick. The rest is knowing the IDs and handling many machines safely.

The schedule IDs worth memorizing

Action	Schedule ID
Hardware Inventory	`{00000000-0000-0000-0000-000000000001}`
Software Inventory	`{00000000-0000-0000-0000-000000000002}`
Discovery Data Record (heartbeat)	`{00000000-0000-0000-0000-000000000003}`
Machine Policy Retrieval	`{00000000-0000-0000-0000-000000000021}`
Machine Policy Evaluation	`{00000000-0000-0000-0000-000000000022}`
Software Updates Assignments Evaluation	`{00000000-0000-0000-0000-000000000108}`
State Message Refresh	`{00000000-0000-0000-0000-000000000111}`
Software Update Scan	`{00000000-0000-0000-0000-000000000113}`
Software Update Deployment Evaluation	`{00000000-0000-0000-0000-000000000114}`
Application Deployment Evaluation	`{00000000-0000-0000-0000-000000000121}`

A few gotchas:

User policy (...026 / ...027) is tied to the logged-on user's SID. Triggering it remotely as an admin refreshes your policy, not the user's, so I generally skip it.
Full hardware inventory requires deleting the InventoryActionStatus instance for ...001 in root\ccm\invagt first. Do it sparingly; full inventories from a lot of machines at once can flood the site.
Configuration baselines aren't schedule IDs. Those use TriggerEvaluation on SMS_DesiredConfiguration in root\ccm\dcm.

Friendly names instead of GUIDs: `Invoke-CMClientAction`

Nobody wants to type GUIDs, so Invoke-CMClientAction maps friendly names to IDs, takes pipeline input, and supports -WhatIf:

Invoke-CMClientAction -ComputerName PC01, PC02 -Action MachinePolicyRetrieval, MachinePolicyEvaluation -WhatIf

# Raw ID still works for anything not in the list
Invoke-CMClientAction -ComputerName PC01 -ScheduleId '{00000000-0000-0000-0000-000000000113}'

# Pipeline from a file
Get-Content .\pcs.txt | Invoke-CMClientAction -Action ApplicationDeploymentEvaluation

It uses a CIM session over WSMan by default. Add -Protocol Dcom for older machines where WinRM isn't enabled. You need local admin on the target either way.

Check before you trigger: `Test-CMClientConnectivity`

Half the "it didn't work" reports I get are machines that are off, unreachable, or have a broken client. Before a big run I check:

Get-Content .\pcs.txt | Test-CMClientConnectivity | Format-Table

It tests ping, WinRM, the CcmExec service state, and the client version. Two PowerShell 7 differences shaped how it's written:

Get-Service -ComputerName was removed in PowerShell 7, so the script queries Win32_Service over CIM, which works in both editions.
Test-Connection uses -TargetName in 7 (with -ComputerName kept as an alias) and returns different objects.

Also remember that "Active" in the console's client activity view only means the client did something within the activity threshold (seven days by default). It doesn't mean the machine is online right now. That's why site-side health (Get-CMClientHealthReport) and live connectivity are separate tools in the kit.

Scaling to a collection: `Invoke-CMClientPolicyRefreshBulk`

For a whole collection, I use Invoke-CMClientPolicyRefreshBulk. It accepts names, a text file, or a collection ID resolved through the SMS Provider, and it has two modes:

# Direct: CIM TriggerSchedule on each client, run in parallel on PowerShell 7
Invoke-CMClientPolicyRefreshBulk -SiteCode HOU -ProviderMachineName cm01 -CollectionId HOU00042 -Mode Direct -ThrottleLimit 32 -WhatIf

# Notification: ask the site to push it over the client notification channel
Invoke-CMClientPolicyRefreshBulk -SiteCode HOU -ProviderMachineName cm01 -CollectionId HOU00042 -Mode Notification

Direct mode is immediate and gives a per-machine result, but needs remoting and local admin on every endpoint. On PowerShell 7 it fans out with ForEach-Object -Parallel. On 5.1, Invoke-Command against a list or an array of CIM sessions gets you similar parallelism.

Notification mode uses the site's own cmdlet:

Invoke-CMClientNotification -DeviceCollectionId 'HOU00042' -ActionType DownloadComputerPolicy
Invoke-CMClientNotification -DeviceName 'PC01' -ActionType RequestScanForUpdate

This goes over the client notification channel through the management point, so you don't need firewall rules for remote management to every endpoint, and the site throttles the work. For large batches, this is what I reach for first. The available -ActionType values depend on your version; check Get-Help Invoke-CMClientNotification -Parameter ActionType. The older Invoke-CMClientAction site cmdlet is deprecated in favor of it (not to be confused with my script of the same name, which talks to clients directly).

Related client-side actions

The same pattern of calling a client WMI class works for a few other jobs I automate:

Install an app from Software Center remotely. Invoke-CMAppInstallOnClient -ComputerName PC01 -ApplicationName '7-Zip 24.08 x64' -WhatIf calls CCM_Application in root\ccm\ClientSDK, exactly like clicking Install. The app must already be deployed to the device.
Pending reboot report. Get-CMPendingRebootReport -ComputerName PC01, PC02 calls CCM_ClientUtilities.DetermineIfRebootPending and checks the usual Windows registry indicators. Point it at a collection with -SiteCode / -ProviderMachineName / -CollectionId and it reads the client state from the site instead of contacting each machine.
Client repair. Repair-CMClient escalates from the least invasive option (SMS_Client.RepairClient) to restarting CcmExec to a full ccmsetup reinstall. Every method is gated by ShouldProcess with high confirm impact.

Safe practice

Client actions feel harmless, and a single policy refresh is. But a full inventory, a software update evaluation, or an app install across a large collection can put real load on your management points, distribution points, and network. The rules I follow:

-WhatIf first, and count your targets before anything else.
Pilot collections first, then broader rings.
Never target All Systems on a whim. Build a collection that means what you intend.
Prefer client notification for large batches, so the site throttles for you.
Check the logs on the client (C:\Windows\CCM\Logs). PolicyAgent.log and PolicyEvaluator.log show whether policy actually arrived, and AppDiscovery.log / AppEnforce.log cover apps.

Get the code

Everything here is MIT-licensed, with a longer guide in the repo covering the ConfigurationManager module, SMS Provider queries, applications vs. packages, content distribution, software updates, Run Scripts, CMPivot and RBAC:

GitHub: https://github.com/anthonybuhnerkemper/configmgr-powershell-toolkit
PowerShell Gallery: https://www.powershellgallery.com/packages/ConfigMgrAdminToolkit

Managing Citrix Virtual Apps and Desktops with PowerShell: a practical guide

Anthony Buhnerkemper — Sat, 10 Oct 2026 23:02:58 +0000

Citrix Studio is a client of the Citrix PowerShell SDK. Everything you click in Studio turns into SDK calls you could run yourself. Older Studio versions even showed you the PowerShell they ran. So anything Studio can do, PowerShell can do too, plus a lot that Studio can't: bulk changes, scheduled reporting, and changes you can audit and repeat.

This is a condensed version of a longer guide I keep alongside my open-source toolkit. The full guide and all the scripts referenced here are in citrix-powershell-toolkit on GitHub, and the scripts are also packaged as a module on the PowerShell Gallery.

Cmdlet names come from the published SDK, but properties and parameters change between releases. Always check Get-Help <cmdlet> -Full on your own controller and test in a lab.

What the SDK actually talks to

A Citrix Virtual Apps and Desktops (CVAD) site is a set of services on each Delivery Controller, and each service has its own cmdlet prefix:

Service	Prefix	Examples
Broker	`Broker`	`Get-BrokerMachine`, `Get-BrokerSession`, `Get-BrokerDesktopGroup`
Machine Creation	`Prov`	`Get-ProvScheme`, `Get-ProvTask`, `Publish-ProvMasterVMImage`
Host	`Hyp` / `XDHyp:` drive	`Get-ChildItem XDHyp:\Connections`
Configuration Logging	`Log`	`Get-LogHighLevelOperation`
Delegated Admin	`Admin`	`Get-AdminAdministrator`, `Get-AdminRole`

The cmdlets never touch the site database directly. They make remote calls to a controller, which is why every cmdlet takes -AdminAddress and why you can run the SDK from any domain-joined admin box that has it installed. Licensing is separate: the License Server has its own module (Citrix.Licensing.Admin.V1).

Loading the SDK: snap-ins vs. modules

For years every Citrix service shipped as a Windows PowerShell snap-in, so community scripts are full of:

Add-PSSnapin Citrix*

Snap-ins only work in Windows PowerShell 5.1. From the 2203 release on, the SDK also ships as modules (Citrix.Broker.Admin.V2 and friends), so Import-Module and auto-loading work. Whether PowerShell 7 is supported depends on your release, so test it before you rely on it. In practice, a lot of Citrix automation still runs in 5.1.

My scripts load the SDK defensively, so the same code runs on old and new controllers:

function Import-CitrixSdk {
    if (Get-Command Get-BrokerSite -ErrorAction SilentlyContinue) { return }
    $mod = Get-Module -ListAvailable Citrix.Broker.Admin.V2 | Select-Object -First 1
    if ($mod) { Import-Module $mod -ErrorAction Stop; return }
    if (Get-Command Add-PSSnapin -ErrorAction SilentlyContinue) { Add-PSSnapin Citrix* -ErrorAction SilentlyContinue }
    if (-not (Get-Command Get-BrokerSite -ErrorAction SilentlyContinue)) { throw 'Citrix SDK not found.' }
}

Read Get-Help about_Broker_Filtering at least once. It documents the filter language every Get-Broker* cmdlet shares.

Citrix DaaS: the Remote PowerShell SDK

With Citrix DaaS, Citrix runs the controllers, so you install the Remote PowerShell SDK on a machine you control. The cmdlet names are the same, and the calls go through Citrix Cloud. For automation, create a secure (API) client in the Citrix Cloud console and register it:

Set-XDCredentials -CustomerId 'yourCustomerId' `
                  -SecureClientFile 'C:\Secure\secureclient.csv' `
                  -ProfileType CloudApi -StoreAs 'DaaSAutomation'

# Later sessions
Get-XDCredentials -ProfileName 'DaaSAutomation' | Out-Null
Get-XDAuthentication -ProfileName 'DaaSAutomation'

Treat that secure client file like a password. On DaaS you don't pass -AdminAddress, which is one reason I splat it (see below).

Always say which controller

On-premises, pass -AdminAddress explicitly in scripts. It makes the target obvious and lets the script run from a jump host. I splat it so the same code works with DaaS, where it's omitted:

$ap = @{}
if ($AdminAddress) { $ap.AdminAddress = $AdminAddress }
Get-BrokerDesktopGroup @ap

For scheduled jobs, pick the first healthy controller from a list:

$ddc = 'ddc01','ddc02' | Where-Object {
    try { (Get-BrokerServiceStatus -AdminAddress $_ -ErrorAction Stop).ServiceStatus -eq 'OK' } catch { $false }
} | Select-Object -First 1

Three conventions that bite everyone

1. The 250-record trap. Get-Broker* cmdlets return at most 250 records by default. When there are more, you get a warning and quietly truncated data. This is the most common bug in Citrix reporting scripts. Always set it:

Get-BrokerSession -MaxRecordCount 100000

2. Filter on the server. Typed parameters and -Filter are evaluated by the Broker, so much less data crosses the wire than with Where-Object:

Get-BrokerMachine -RegistrationState Unregistered -InMaintenanceMode $false -MaxRecordCount 5000
Get-BrokerSession -Filter { SessionState -eq 'Disconnected' -and DesktopGroupName -like 'Finance*' } -MaxRecordCount 5000

Save Where-Object for computed values like "disconnected for more than four hours".

3. Names vs. Uids, and three kinds of machine name. Relationships are often exposed as integer Uids (AssociatedDesktopGroupUids on applications), so build a lookup hashtable once instead of querying in a loop. For machines, MachineName is DOMAIN\HOST, DNSName is the FQDN, and HostedMachineName is the hypervisor VM name. Use the right one when you join data.

And the pipeline caution: Set cmdlets accept Get output, which is powerful and easy to over-apply. Run the Get half alone and count the results before adding | Set-BrokerMachine.

The cmdlets I use most

Machines â€” Get-BrokerMachine gives you RegistrationState, PowerState, InMaintenanceMode, SessionCount, FaultState, LastDeregistrationReason, AgentVersion and Tags. Maintenance mode (Set-BrokerMachine -InMaintenanceMode $true) blocks new connections; existing sessions continue.
Sessions â€” Get-BrokerSession with SessionState and SessionStateChangeTime reliably gives you "disconnected since". Stop-BrokerSession logs off, Disconnect-BrokerSession disconnects, and Send-BrokerSessionMessage warns users before maintenance.
Delivery groups â€” Get-BrokerDesktopGroup exposes DesktopsAvailable, DesktopsInUse, DesktopsUnregistered and more, which is enough for a quick capacity dashboard.
Power â€” don't call the hypervisor yourself. Queue New-BrokerHostingPowerAction -Action Restart and let the hosting connection's throttling protect your storage from boot storms.
MCS â€” Get-ProvScheme, Get-ProvTask, and Publish-ProvMasterVMImage for image updates.
Configuration Logging â€” Get-LogHighLevelOperation tells you who changed what and when, whether from Studio or the SDK.

Tags (Add-BrokerTag) deserve special mention. They're the cleanest way to define patch rings or reboot waves without restructuring delivery groups.

Workflows I automate

These map to scripts in the toolkit. Every script that changes something supports -WhatIf and -Confirm.

Morning health check. Get-CitrixMachineHealth (registration, maintenance, power), Get-CitrixDeliveryGroupSummary (capacity), and Get-CitrixSessionReport. Unregistered machines that aren't in maintenance mode are almost always the first thing worth looking at.

Drain a server for patching.

Set-CitrixMaintenanceMode -MachineName ... -Enable $true -WhatIf, then for real.
Optionally warn users with Send-BrokerSessionMessage.
Wait for sessions to drain.
Patch and restart.
Confirm RegistrationState -eq 'Registered', then turn maintenance mode off.

Clean up stale disconnected sessions. Report first with Get-CitrixDisconnectedSessions -MinimumMinutes 480, then act with Invoke-CitrixLogoffIdleSessions -DisconnectedMinutes 480 -WhatIf. Long term, set session-limit timers through policy, so the script handles exceptions rather than doing the work policy should do.

Staggered reboots by tag. Restart-CitrixMachinesByTag skips machines with sessions by default and queues restarts in batches with a delay. For multi-session groups, consider the built-in reboot schedules too.

MCS image update. Update and seal the master, snapshot it, Publish-ProvMasterVMImage, watch Get-ProvTask, then roll machines onto the new image with a staged reboot.

Documentation and audit. Export-CitrixSiteDocumentation writes a point-in-time HTML/CSV snapshot of the site. Get-CitrixConfigLogReport pulls Configuration Logging entries. Get-CitrixCatalogReport, Get-CitrixApplicationInventory and Get-CitrixLicenseUsage round out the inventory.

A note on reporting output

Every report in the toolkit emits objects first and files second. That sounds minor, but it means you can pipe a report into Where-Object, Group-Object or Export-Csv the same way you would any other cmdlet, and only write HTML or CSV when you actually want an artifact. For example, a quick count of unregistered machines per delivery group:

Get-CitrixMachineHealth -AdminAddress ddc01 |
    Where-Object RegistrationState -ne 'Registered' |
    Group-Object DesktopGroupName | Sort-Object Count -Descending

Objects also make it easy to diff today's run against yesterday's, which is often where the useful signal is.

Safe change practice

The habits that have saved me the most pain:

-WhatIf first, every time. If a script that changes state doesn't support ShouldProcess, don't schedule it.
Get, count, then Set. (Get-BrokerMachine -Tag 'Wave1' -MaxRecordCount 5000).Count before you pipe anything.
Small batches. Pilot on one machine, then one delivery group, then everything.
Leave a trail. SDK changes appear in Configuration Logging; add your own transcript or log file for scheduled jobs.

Scheduling and least privilege

For scheduled tasks, run under a dedicated service account with a custom Citrix delegated administration role scoped to only what the job needs. A read-only reporting job should never run as Full Administrator. On DaaS, use an API client per automation, so you can rotate or revoke one without breaking the others. Run Windows PowerShell 5.1 unless you've confirmed your SDK release supports 7.

Troubleshooting quick hits

"The term Get-BrokerMachine is not recognized" â€” SDK not installed or not loaded. Check Get-Module -ListAvailable Citrix* and Get-PSSnapin -Registered Citrix*.
Exactly 250 results â€” you forgot -MaxRecordCount.
Access denied on some objects â€” your delegated admin scope doesn't cover them.
New property missing â€” your SDK is older than your controllers. Upgrade the SDK on the admin box.

Get the code

Everything here, plus the full long-form guide, is MIT-licensed:

GitHub: https://github.com/anthonybuhnerkemper/citrix-powershell-toolkit
PowerShell Gallery: https://www.powershellgallery.com/packages/CitrixAdminToolkit (Install-Module CitrixAdminToolkit)

If you find a property that changed in your release, open an issue. Version drift is the hardest part of keeping Citrix automation accurate.

Three read-only PowerShell reports every Microsoft 365 admin should run

Anthony Buhnerkemper — Sat, 10 Oct 2026 23:02:45 +0000

When I pick up a Microsoft 365 tenant, whether it's new to me or one I haven't looked at closely in a while, I don't start by changing anything. I start by asking it questions. Three questions in particular have given me the most value for the least risk:

Where are the licenses going?
Which accounts nobody is using anymore?
Is any mail quietly leaving the organization?

I packaged the scripts I use for these into a small open-source toolkit: m365-powershell-toolkit on GitHub, also available as a module on the PowerShell Gallery. All three are read-only. They report, they don't change anything, and they ask for the least-privileged scopes I could get away with.

Getting set up

Install-Module Microsoft.Graph -Scope CurrentUser
Install-Module ExchangeOnlineManagement -Scope CurrentUser

# Either clone the repo and run the .ps1 files, or install the module:
Install-Module M365AdminToolkit -Scope CurrentUser

PowerShell 7.2+ is what I use day to day, but Windows PowerShell 5.1 works for most of it. An account with Global Reader or Reports Reader is enough; you don't need Global Admin to run any of these. Every function has comment-based help, so Get-Help Get-StaleEntraUsers -Full is the fastest way to see the options.

1. License usage: `Get-M365LicenseReport`

Licenses are usually the biggest line item a tenant has, and the admin center makes it surprisingly awkward to answer "who has what?" across every SKU at once.

Get-M365LicenseReport -OutputPath .\reports

It connects to Microsoft Graph with just Organization.Read.All and User.Read.All, then produces two CSVs:

A SKU summary: enabled, consumed and available units for each subscribed SKU, so you can spot both shelfware and SKUs that are about to run out.
Per-user assignments: one row per user per assigned SKU, with the SKU part number resolved from its GUID.

What I look for:

SKUs with a large gap between purchased and consumed (money on the table at renewal).
Disabled accounts still holding paid licenses. Sort the per-user CSV by AccountEnabled and this jumps out immediately.
Users with overlapping SKUs (for example a standalone add-on that's already included in a suite they have).

2. Stale accounts: `Get-StaleEntraUsers`

Every tenant collects dead accounts: people who left, test accounts, "temporary" vendor logins. Each one is an attack surface and often a license too.

Get-StaleEntraUsers -DaysInactive 90 -IncludeNeverSignedIn

This uses the signInActivity property on the user object, which carries both the last interactive and last non-interactive sign-in. The script treats a user as stale only when both are older than the threshold. That matters: a mailbox used only by a sync client or a service can look dormant if you only check interactive sign-ins.

A few practical notes:

signInActivity needs Entra ID P1 or P2 and the AuditLog.Read.All scope in addition to User.Read.All.
By default only Member accounts are evaluated. Add -IncludeGuests to include B2B guests, which is often where the real clutter is.
-IncludeNeverSignedIn adds accounts with no recorded sign-in that were created before the cutoff. Those are frequently provisioning leftovers.

I hand the CSV to whoever owns access reviews rather than disabling accounts from the script. Keeping the report and the action separate means nobody gets locked out by a bad assumption.

3. External forwarding: `Get-MailboxForwardingAudit`

This one has caught real problems for me. Auto-forwarding to an outside address is a classic sign of a compromised mailbox, and it's also how well-meaning users leak data to personal accounts.

Get-MailboxForwardingAudit -InternalDomains contoso.com, contoso.onmicrosoft.com

It connects to Exchange Online and checks two places forwarding can hide (use -SkipInboxRules for a faster mailbox-only pass on large tenants):

Mailbox-level forwarding (ForwardingAddress / ForwardingSmtpAddress), which admins or users can set.
Inbox rules that forward, redirect, or forward-as-attachment, which is where attackers prefer to put it, since users rarely look.

Anything that targets a domain not in -InternalDomains gets flagged. Pass every accepted domain you own, or you'll get noise from internal forwards.

When it finds something, I check the account's sign-in logs before touching the rule. If the forwarding was set by an attacker, the evidence matters more than a quick cleanup. Separately, it's worth confirming that your outbound spam policy blocks automatic external forwarding by default and only allows it by exception.

Why read-only first

None of these scripts will fix anything for you, and that's on purpose. Reports are safe to schedule, safe to hand to a junior admin, and safe to run in a tenant you don't fully understand yet. They turn "I think we have a lot of stale accounts" into a CSV you can put in front of the people who decide.

Run them on a regular cadence and compare each run against the last one. The changes are often more interesting than the totals.

The code is MIT-licensed. Issues and pull requests are welcome:

GitHub: https://github.com/anthonybuhnerkemper/m365-powershell-toolkit
PowerShell Gallery: https://www.powershellgallery.com/packages/M365AdminToolkit

DEV Community: Anthony Buhnerkemper

Automating Configuration Manager (SCCM) client actions with PowerShell

How client actions work

The schedule IDs worth memorizing

Friendly names instead of GUIDs: Invoke-CMClientAction

Check before you trigger: Test-CMClientConnectivity

Scaling to a collection: Invoke-CMClientPolicyRefreshBulk

Related client-side actions

Safe practice

Get the code

Managing Citrix Virtual Apps and Desktops with PowerShell: a practical guide

What the SDK actually talks to

Loading the SDK: snap-ins vs. modules

Citrix DaaS: the Remote PowerShell SDK

Always say which controller

Three conventions that bite everyone

The cmdlets I use most

Workflows I automate

A note on reporting output

Safe change practice

Scheduling and least privilege

Troubleshooting quick hits

Get the code

Three read-only PowerShell reports every Microsoft 365 admin should run

Getting set up

1. License usage: Get-M365LicenseReport

2. Stale accounts: Get-StaleEntraUsers

3. External forwarding: Get-MailboxForwardingAudit

Why read-only first

Friendly names instead of GUIDs: `Invoke-CMClientAction`

Check before you trigger: `Test-CMClientConnectivity`

Scaling to a collection: `Invoke-CMClientPolicyRefreshBulk`

1. License usage: `Get-M365LicenseReport`

2. Stale accounts: `Get-StaleEntraUsers`

3. External forwarding: `Get-MailboxForwardingAudit`