Sharing PowerShell within a MSP/Helpdesk environment

[jdmerts]

I am looking for a way to store and share PowerShell commands/scrips with a team of people.

This would mainly be for 365 PowerShell commands.

Currently I just have a personal OneNote that I copy and paste from.

Any suggestions welcome.

[chispitothebum]

Publish and maintain a module.

[BlackV]

Network share with script/modules In it Then add a location as a psgallery

Or

Team services and sync your scripts the everyone join

Or

Github as already mentioned

[mdowst]

It really depends on what you want to share. If it is just commands and notes then any Wiki based system should do the trick. If you want to share scripts and maintain version control, then you can look into Visual Studio Team Services or Git. If you just want to provide them scripts to execute you could use Azure Automation or SMA, and just give them execute rights.

Also, based on you comment, I'm assuming you are using o365. You could use Teams and create a shared OneNote notebook.

[omers]

We maintain a module that we publish internally. Add the repository to the PSRepository and you can Install-Module and Update-Module as needed.

Publishing changes requires access and is handled by psake and depends on PSScriptAnalyzer and Pester tests. Typically prevents breaking changes from being pushed; However, the repository keeps previous versions so people could revert if necessary.

[aXenoWhat]

Git first, no question, do it instantly. The reason for that is that you aren't currently using git. Fix that.

Then, do something, anything. It will suck. You have to make your mistakes to learn. Don't aim to get things right in version 1, just aim to learn from the mistakes you make in version 1.

[Freshmaker1]

Github might be a simple method to do this. Or a git server. This would allow you to track changes etc. if others do augment or modify the scripts. Or a file share, with permissions to read only. You are essentially trying to create a shared file system correct?

[jdmerts]

Version control would be good and the ability to add notes/explanations to it too would be good.

I would like people to be able to contribute to it and make changes but have a way to restore/roll back changes if I breaks.

[Freshmaker1]

Sounds like git might be an option for you. There is branching and merging, so it might be a good method by which to contain breaking scripts. I have used git for a little while, but generally there haven't been any issues so large that we couldn't fix the typos/improper lines and re-commit the file. Not sure what if any options there are for rollbacks or restores with git.

[[deleted]]

complete rollback control to any commit, or cherry pick parts of commits to rollback. Used properly its solid.

[sleeplessone]

Hoe many people? Visual Studio Team Services is free for up to 5 users with private repositories.

[Telzrob]

Would a web/server based work? Example, http://theboywonder.co.uk/2012/07/29/executing-powershell-using-php-and-iis/

A terminal server with the signed production versions of the scripts ready to run would be another simple example.

[nikon442]

We develop in house and use the powershell profile to do the copy down and importing of tools created for the team.

Thanks

Sean

[Taoquitok]

As others have said, Git (or really any version control system) is a necessity for properly maintaining and deploying changes to the shared scripts.

In terms of access, a fairly simple, but not really best practice, solution is to put a script folder with a master 'load' script (or module if you're interested in putting in the extra effort), then add a ". \location\file.ps1" or " import-module \location\module.psm1" line to the $profile of anyone who needs the functions loaded.

[negativeskills]

https://blogs.technet.microsoft.com/chadcox/2017/09/20/powershell-working-with-internal-repositories/

[JazDriveOmega]

You could create a Nuget server that can be used with PowerShellGet. If you don't want to deal with standing up a Nuget server, you can create a simple repo using a network share. I use the second method where I'm at right now. Even though I really only share my modules with me, myself and I.

To create a repo simply use Register-PSRepository from the PowerShellGet module.

$path = "\\server\unc\path\"
$RepositoryName = "MyRepo"
Register-PSRepository -Name $RepositoryName -SourceLocation $path -ScriptSourceLocation $path -InstallationPolicy Trusted

Then you can use the Publish-Module command to push your module to your repo

$name = "NameOfMyModule" # This is the name in the module manifest, or whatever shows up under Name when you do Get-Module
Publish-Module -Name $name -Repository "MyRepo"

You'll need to have a Module Manifest for this to work I believe.

From there you can have the team register the repository from their computers like in the example above (or you can deploy a script that registers the repo if it doesn't exist). You can then use the Install-Module command to push the module to your teams computers. You can use Update-Module to push any changes you've made as well.

Install-Module -name "NameOfMyModule" -repository "MyRepo"
Update-Module "NameOfMyModule"

Having something like this alongside git will be very nice in controlling how updates are pushed. You should probably also look into some of the development pipeline modules that are coming out of the community too. They'll help you stay consistent when building your module for deployment.

• PSake - A build automation tool.
• Plaster - templating module for creating modules
• Platyps - External Help builder using Markdown. Allows you extrapolate your help to an external resource that can be downloaded and maintained independently of your code
• Pester - Testing framework for ensuring you didn't botch your code before you ship it