Managing modules with multiple user accounts on the same computer

Ask your PowerShell-related questions, including questions on cmdlet development!
Forum rules
Do not post any licensing information in this forum.

Any code longer than three lines should be added as code using the 'Select Code' dropdown menu or attached as a file.
This topic is 2 years and 5 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked
User avatar
HONDAAL
Posts: 15
Last visit: Wed Dec 22, 2021 10:02 am
Has voted: 1 time

Managing modules with multiple user accounts on the same computer

Post by HONDAAL »

Product, version and build: PowerShell Studio 2021 v5.8.191
Operating system: Windows 10 1909
PowerShell version(s): 5.1 and 7.1


This is a follow-up to the Changing the PowerShell module export path topic. Until a change (or no change) is made to PowerShell Studio, I am looking for solutions to address this growing problem. Any suggestions / feedback is welcome. Thanks.

Challenge:

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 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.


Goals:

PowerShell modules are consistent across user accounts 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. :)
User avatar
brittneyr
Site Admin
Posts: 1654
Last visit: Wed Mar 27, 2024 1:54 pm
Answers: 39
Been upvoted: 30 times

Re: Managing modules with multiple user accounts on the same computer

Post by brittneyr »

[Topic moved by moderator]
Brittney
SAPIEN Technologies, Inc.
jvierra
Posts: 15439
Last visit: Tue Nov 21, 2023 6:37 pm
Answers: 30
Has voted: 4 times
Been upvoted: 33 times

Re: Managing modules with multiple user accounts on the same computer

Post by jvierra »

Your issue seems to be a bit confusing. We build in a development account and "deploy" to users. There should be no reason to run PowerShell studio on every user account.

My first guess is that you do not truly understand how to use PowerShell in a large network or how to deploy modules to a network location that is common.

Maintain code in one dev account and deploy after all testing is done.

It is also possible that you are just overcomplicating the issue. Unfortunately, there is no way to decode what you have written. Start by asking one question and make teh question clear. As posted, there is no clear question and your statements are very hard to understand.

-
User avatar
HONDAAL
Posts: 15
Last visit: Wed Dec 22, 2021 10:02 am
Has voted: 1 time

Re: Managing modules with multiple user accounts on the same computer

Post by HONDAAL »

Sorry for the confusion, but without a complete picture, it would be easy to go down the wrong path. Let me explain the accounts a different way.

As an administrator, I have multiple domain accounts. Each account provides access to different parts of the corporate environment, based on the principal of least privilege. The account I use to log into my computer is a very low-privileged account, so PowerShell Studio (PSS) is always run under one of the higher privileged accounts. In order to test/debug modules across every part of the environment, it is necessary to run PSS under each of the privileged accounts.

Since PSS will only ‘build’ PS modules in the user’s Modules directory (rather than a central location on my computer like Program Files), I can end up with different code bases in different user Modules directories when local testing is done.

Once complete, the only way to get all user folders back in sync is to close PSS, re-open it under all accounts, open the module that has been modified, and run the build step to update the Modules folder for that user. Optionally, I could, of course, simply copy the module directory from the updated folder to the other folders. Whatever method is used, it is a manual step I would like to eliminate. If it is not done, then running a cmdlet from the PowerShell window opened under one of the other accounts could result in running an older version of the module.

Joe's computer running PSS under his 3 different accounts as needed.png
Joe's computer running PSS under his 3 different accounts as needed.png (69.4 KiB) Viewed 5540 times
In this example, “Joe” is one person with multiple AD accounts.
User avatar
Alexander Riedel
Posts: 8478
Last visit: Tue Mar 26, 2024 8:52 am
Answers: 19
Been upvoted: 37 times

Re: Managing modules with multiple user accounts on the same computer

Post by Alexander Riedel »

I am gonna jump in here and give you some opinion on this. Please take it as what it is, its your environment. Just providing perspective.
It sounds like a system that is way too complex. If you log in as a completely unprivileged user but run everything then as a different user, it seems useless to have that low level user.
Likewise, if you would want PowerShell Studio to publish to "Program Files", which is a protected folder, you would need to run it at all times as elevated admin to be allowed to write there.
You should NEVER do that. If you ask me, you user permission model is far too complex. See if you can simplify it. If each of your users needs to have three different logins to accomplish admin tasks, it sounds like everyone has passwords taped to the screen. I of course don't know that, but that has been my experience.

Generally though, you develop and debug on one machine. Under a user than can do the things that need to get done.
If you cannot trust that developer to have the privileges to do that work, find someone else. :D That would by my stance on that.
Once development and debugging have completed to create a new version of a modules, you would publish it. To a repository, network location etc. Preferably, I would create an MSI for it to ensure proper installation and versioning on the target machines. As you point out, having multiple versions of one module on a machine is not a good thing.
Then the target machines, either automated or by remote command would be installing the updated module when an update is available.
Depending on the size of your network, how fractured it is and how many machines there are, some mechanisms would work better than others.

But generally, the cycle is Develop - Debug - Test - Publish. You never want your environment to automatically publish to a production location. This should always be a manual step with safeguards to prevent accidental publishing of code that is under development and untested.
Alexander Riedel
SAPIEN Technologies, Inc.
This topic is 2 years and 5 months old and has exceeded the time allowed for comments. Please begin a new topic or use the search feature to find a similar but newer topic.
Locked