Team use of PowerShell

[dcwhitworth]

I've written some useful PowerShell script that I want my team to use for domain and O365 work, but I'm struggling to get anything to work for anyone else. There just seem to be too many hurdles to overcome, modules to load, logins, execution policies, not liking programs on network drives, certificates not working. I get it all working on my PC but then something different won't work on someone else's.

 

Has anyone got any hints on sharing PowerShell scripts around a team ? How do you lessen the pain without (preferably) totally throwing away security ?

[Steve21]

Honestly I ended up stopping using it for similar reasons, and just wrapping stuff in exe's, but in regards to your questions.

 

Set policy to signed, Sign script with a domain CA Cert which you can deploy via GPO. Deploy the modules via GPO/SCCM etc to the modules path, then no need to import them manually. Network drive wise link direct to the UNC assuming they have access in the first place.

 

Steve

[ChrisMiles]

I've written some useful PowerShell script that I want my team to use for domain and O365 work, but I'm struggling to get anything to work for anyone else. There just seem to be too many hurdles to overcome, modules to load, logins, execution policies, not liking programs on network drives, certificates not working. I get it all working on my PC but then something different won't work on someone else's.

 

Has anyone got any hints on sharing PowerShell scripts around a team ? How do you lessen the pain without (preferably) totally throwing away security ?

 

I sign scripts using a code-signing certificate issued from our internal CA so it works for everyone automatically. We've had no problems at all with powershell portability. You can check for and import modules as part of your scripts if its a problem. Execution policies should all be set centrally by group policy anyway, not sure what you mean about network drives, powershell has no issues with UNC paths that I know about.

[Arthur]

powershell has no issues with UNC paths that I know about.

 

PowerShell Gotcha: UNC paths and Providers

 

PowerShell's behavior can be a little bit funny when you pass a UNC path to certain cmdlets. PowerShell doesn't recognize these paths as "rooted" because they're not on a PSDrive; as such, whatever provider is associated with PowerShell's current location will attempt to handle them. For example:

 

Set-Location C:
Get-ChildItem -Path \\$env:COMPUTERNAME\c$

Set-Location HKLM:
Get-ChildItem -Path \\$env:COMPUTERNAME\c$

 

The first command works fine (assuming you have a c$ share enabled and are able to access it), and the second command gives a "Cannot find path" error, because the Registry provider tried to work with the UNC path instead of the FileSystem provider. You can get around this problem by prefixing the UNC path with "FileSystem::", which will make PowerShell use that provider regardless of your current location.

 

Get-ChildItem -Path [color="#FF0000"]FileSystem::[/color]\\$env:COMPUTERNAME\c$

[danbuntu]

One of the things we did was to connect remotely to a machine with the modules on via PSsession.

So for example connect to a hyperv scvm server and load the management modules from there. This stops you having to install them locally. Although the downside is that are then slower to run:

 

 

# #make the credentionals
       $this.passwordSecure = $this.password|ConvertTo-SecureString -AsPlainText -Force
       $cred2 = New-Object System.Management.Automation.PsCredential($this.username, $this.passwordSecure)

       # # connect to the remove scvm server
       $this.session = New-PSSession -ComputerName $this.hypervHost -Credential  $cred2

       ## Load the scvm modules from the remote server
       Invoke-Command -Session $this.session {Import-Module -Name VirtualMachineManager}
       Import-PSSession -Session $this.session -Module VirtualMachineManager