loxopa

One thing to be aware of: Shell.Application relies on an interactive user session. If Pulseway runs the task under SYSTEM (non-interactive), the eject action may silently fail or behave inconsistently. For better reliability in automation, you may want to: - Run the script in the logged-in user context where possible. - Add basic validation to confirm the device was actually ejected. - Consider using CIM Get-CimInstance) instead of Get-WmiObject since WMI is deprecated. Also worth noting—on some systems, the "Eject" verb isn’t always exposed for certain USB devices, especially if they mount differently. Overall, solid script. Just a few edge cases to keep in mind depending on how it's deployed.

This is expected behavior when running via Pulseway. Your script is writing to HKCU, which targets the currently logged-in user context. Pulseway RMM tasks typically execute under the SYSTEM account, not the interactive user. As a result, the registry changes are applied to SYSTEM’s profile, not the actual user profile—so it appears as if nothing happened. That’s why it works in PowerShell ISE locally (runs in user context) but not via RMM. Options to fix: 1. Run the script in the logged-in user context (if Pulseway supports this setting). 2. Modify the script to target user profiles explicitly by loading user hives (HKU) instead of HKCU. 3. Deploy via a logon script or GPO if this is domain-related. Quick test: check HKEY_USERS\.DEFAULT or SYSTEM hive after execution—you’ll likely see the key there. Hope that helps.