https://pwsh.in/tags/module/Recent content in Module on Vibhu Bhatnagar — PowerShell & Infrastructure EngineerHugo -- gohugo.ioenThu, 23 Apr 2026 12:00:00 +0530https://pwsh.in/posts/invoke-vbascurrentuser/Thu, 23 Apr 2026 12:00:00 +0530https://pwsh.in/posts/invoke-vbascurrentuser/<p>If you have ever deployed a PowerShell script through Intune, a RMM agent, or Task Scheduler running as SYSTEM, you have hit this wall at least once: the script works perfectly when you run it interactively, but returns nothing — or the wrong thing — when deployed at scale.</p> <p>The reason is almost always the same. The script is collecting user-specific data. And SYSTEM is not the user.</p> <hr> <h2 id="the-problem-system-and-the-user-are-not-the-same-session">The Problem: SYSTEM and the User Are Not the Same Session</h2> <p>When Intune or your RMM agent executes a PowerShell script, it runs in the SYSTEM context. SYSTEM is a highly privileged account, but it is completely isolated from the interactive user session happening on the same machine at the same time.</p>https://pwsh.in/posts/printer-mapping-powershell-vb-workstationreport/Thu, 23 Apr 2026 10:00:00 +0530https://pwsh.in/posts/printer-mapping-powershell-vb-workstationreport/<p>Printer management at scale is one of those problems that looks trivial until you are staring at 200 workstations, each with multiple user profiles, each with their own mapped printers, and a print server migration starting in two days.</p> <p>Doing it manually is not an option. Doing it via Group Policy works for connected machines but breaks for laptops on VPN, offline profiles, and anyone who mapped printers manually outside GPO. What you actually need is something that understands how Windows stores printer mappings per user, can work on both online and offline profiles, and can be deployed from your RMM in a single script run.</p>