Managing PowerShell modules with multiple user accounts (for the same user) on the same computer

Short version: In the environment in which I work, we have always had standard user accounts and “elevated” accounts. Now, we have multiple elevated accounts with different levels of access. This has made the management of PowerShell modules more of a challenge. I’m looking for suggestions.


We must run different PowerShell cmdlets under different user accounts depending on the task at hand. Each account has different permissions, primarily on remote systems.

Some of these cmdlets are from PowerShell modules that we have written and continue to maintain. These constitute the scope of this issue.

I must run my IDE (Sapien’s PowerShell Studio) under different user accounts to test / debug our PowerShell modules and scripts. This is done via the “Run as administrator” option as all user accounts (that PowerShell Studio is run under) are local admins on the local computer. I never run PowerShell Studio under my standard login account as it has very little access to anything local and no access to anything remote.

The “source code” for each PowerShell module resides in a single location that is the same for all user accounts and outside any PSModulePath location, so there are never multiple copies of the “source code.” These locations are also the git repositories for each module.

PowerShell Studio will only “build” modules to the current user’s Modules folder, so I can end up with inconsistent code depending upon which user account I am using. The build process occurs automatically each time the code is run in the IDE.

Trying to keep every module under every account in sync manually is tedious and error-prone.


Keep PowerShell modules consistent across user accounts (for the same person) on a given computer.

Local code changes that have not been pushed back to GitHub should be consistent across all user accounts on the local computer.

Continue using PowerShell Studio as my IDE. I have tried others, including VS Code, but always come back to using PowerShell Studio. It just works.

I am prepared to solve this issue with code and have a few ideas in mind, but I have learned that my first instinct is not always (ok, almost never) the best solution.