Windows Admin Center can open a PowerShell session on a managed server, which makes it useful for checking currently attached USB storage and collecting the identifiers needed for a targeted block. The difficult parts are interpreting historical registry entries, enabling logs before the next insertion, and choosing the correct hardware ID instead of blocking an entire USB class accidentally.
This workflow is designed for authorized administration. It records what was observed, applies policy through a supported control, and keeps input devices and remote management available.
Understand what Windows Admin Center is running
Windows Admin Center is a browser-based management gateway, but many actions are performed through PowerShell and Windows management APIs on the target. Microsoft documents how to view the PowerShell scripts used by Windows Admin Center, which is useful when you need to reproduce or audit an interface action.
Commands run from the WAC PowerShell tool execute in the context and remoting path provided by that connection. Confirm the target hostname and elevation before querying or changing device policy.
List USB storage that is present now
Start with disk objects whose bus type is USB:
Get-Disk |
Where-Object BusType -eq 'USB' |
Select-Object Number, FriendlyName, SerialNumber, OperationalStatus,
PartitionStyle, Size
This is better than listing the entire USB controller class when the goal is removable storage. A mouse, keyboard, smart-card reader, and USB hub are USB devices but not USB disks.
Correlate the disks with Plug and Play instances:
Get-PnpDevice -Class DiskDrive -PresentOnly |
Where-Object InstanceId -Like 'USBSTOR\*' |
Select-Object Status, FriendlyName, InstanceId
Do not publish the output without sanitizing it. Storage serial numbers and device instance IDs can identify a specific asset or user.
Historical registry entries need careful interpretation
Windows commonly retains enumerated USB mass-storage instances under:
HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR
The first level describes a device model, and child keys represent instances. A read-only inventory can enumerate both levels:
$usbStor = 'HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR'
Get-ChildItem -Path $usbStor -ErrorAction Stop | ForEach-Object {
Get-ChildItem -Path $_.PSPath -ErrorAction SilentlyContinue | ForEach-Object {
$item = Get-ItemProperty -Path $_.PSPath
[pscustomobject]@{
FriendlyName = $item.FriendlyName
InstanceKey = $_.PSChildName
RegistryPath = $_.Name
}
}
}
An entry means Windows enumerated that instance at some point. It does not prove who inserted it, what files were accessed, or that the device is present now. Registry retention and cleanup also mean this is not a complete forensic ledger.
Preserve timestamps and event data when an incident requires attribution. Do not treat a friendly name alone as unique: many devices of the same model share it.
Why an event query can return no results
Get-WinEvent can return “No events were found” for several different reasons:
- the channel is disabled;
- the channel does not exist on that Windows build;
- it is enabled but has no matching events in its retained window;
- the text filter does not match localized or differently formatted messages;
- the relevant event is recorded in another provider or channel.
Discover available channels before enabling a hard-coded list:
Get-WinEvent -ListLog *USB* -ErrorAction SilentlyContinue |
Select-Object LogName, IsEnabled, RecordCount
Get-WinEvent -ListLog *Partition* -ErrorAction SilentlyContinue |
Select-Object LogName, IsEnabled, RecordCount
Inspect one channel’s configuration with wevtutil gl before changing it. Enabling an operational or analytic channel normally affects future events; it does not reconstruct insertions that occurred while logging was disabled.
After enabling an approved channel, insert a test device and query a narrow time range. Filter structured event fields where possible rather than relying only on the localized message string.
Extract the identifier needed for policy
The PSChildName shown under USBSTOR is not automatically the correct value for a Device Installation Restrictions policy. Microsoft distinguishes instance IDs, hardware IDs, and compatible IDs. The USB storage driver generates identifiers based on device descriptors and storage inquiry data, as described in Microsoft’s USBSTOR identifier documentation.
For a connected target device, capture both the instance and its hardware IDs:
$device = Get-PnpDevice -Class DiskDrive -PresentOnly |
Where-Object FriendlyName -Like '*Flash Drive*' |
Select-Object -First 1
$device | Select-Object Status, FriendlyName, InstanceId
Get-PnpDeviceProperty -InstanceId $device.InstanceId `
-KeyName 'DEVPKEY_Device_HardwareIds' |
Select-Object -ExpandProperty Data
Do not use a broad friendly-name match in an enforcement script. Identify the exact device interactively, record the expected serial or instance, and verify the returned hardware IDs before building policy.
Block a specific device through Group Policy
Microsoft’s current device-installation Group Policy guide provides a scenario for blocking a specific USB thumb drive.
The policy path is:
Computer Configuration
Administrative Templates
System
Device Installation
Device Installation Restrictions
Enable Prevent installation of devices that match any of these device IDs, open Show, and add the reviewed hardware ID. If the policy must affect a device already installed, evaluate the option to apply the restriction to matching devices that are already installed.
Test on a noncritical system first. Device relationships form a Plug and Play tree; blocking a parent can also block children. Microsoft explicitly warns that an overly broad policy can block Human Interface Devices and prevent a user from accessing the machine.
Maintain a remote administrative path that does not depend on the USB hardware being changed. Document how to remove or correct the policy if the identifier matches more devices than intended.
Blocking installation is not the same as disabling a device once
Disable-PnpDevice can disable a currently enumerated instance, but a one-time command is not a durable enterprise policy. The device can be re-enumerated, the instance can change, or another user can reverse the state with sufficient rights.
Use the command for a controlled containment action only when its impact is understood. Use Group Policy, mobile-device management, or an endpoint security control for maintained enforcement, reporting, and exceptions.
Also distinguish these requirements:
- block one exact storage device;
- allow only an approved device list;
- block all removable storage;
- prevent writes while permitting reads;
- prevent device installation but retain already installed devices;
- alert on insertion without blocking.
They require different controls and have different operational consequences.
Do not turn silent copying into an ungoverned collection mechanism
Automatically copying every inserted USB drive to a hidden background folder creates serious security and privacy risks. It can ingest malware, copy personal or regulated data without authorization, consume the system volume, preserve deleted or restricted material, and expose the organization to an undocumented surveillance process.
If an approved business process requires USB ingestion or backup, design it as a visible, governed service:
- allowlist authorized devices and file types;
- write to a dedicated volume with quotas;
- scan content before further use;
- log source device, time, result, and errors;
- preserve access controls and retention policy;
- handle partial copies and removal during transfer;
- notify the device owner and obtain the required authorization;
- test recovery rather than assuming a copy is a valid backup.
“Silent” should mean unattended operation with reliable logging, not operation hidden from users and administrators.
Verification after policy deployment
After applying the targeted policy:
- Run
gpupdate /forceor wait for normal policy refresh as appropriate. - Restart only if the selected policy and test plan require it.
- Insert the blocked test device and confirm it is not usable.
- Review the Device Installation Restrictions result and related events.
- Test an approved USB storage device.
- Test keyboards, pointing devices, smart-card readers, and the remote management path.
- Confirm the policy is centrally recorded and can be rolled back.
The reliable sequence is inventory, identify, policy, and verification. A registry key or friendly name can start the investigation, but the exact Plug and Play hardware ID and a narrowly scoped Group Policy should make the final enforcement decision.
