PowerShell Quality of Life Improvements – PS Repository

In the last post, we were able to create a Release Pipeline that takes checked and signed Powershell code and deploys it to target servers. In some situations, it may not be desirable or viable to have every server configured as a deployment target. Or there may be a need to have an additional amount of control of the modules that a server gets. To deal with these issues, we can look at setting up a PowerShell Respoistory as an intermediatory step.

Setting Up The Respository

The Respository can be as simple as a file share on a server. At the higher end of complexity, it can be a website running NuGet Gallery. For this case, I’ve gone simple. By using a file share, we negate the need for setting up API keys and the like that a NuGet Gallery would need.

Once the PowerShell Respoistory is created, it needs to be registered on the relevant targets. This is achieved using the Register-PSRepository cmdlet, as shown below:

Register-PSRepository -Name psqol -SourceLocation "\\svr14\psrepo\" -PublishLocation "\\svr14\psrepo\" -InstallationPolicy Trusted

If the InstallationPolicy value is set to “Untrusted”, then there will be a user prompt when attempting to install modules from the Repository.

Read more

VM Server #2 Upgrade

VM Server 1 is getting a bit overloaded so I’ve decided to upgrade a 2nd PC to act as a 2nd virtualisation host.  Upgrade components will be:

  • Gigabyte GA-P55-UD3R
  • 4 x 2GB OCZ DDR3 sticks
  • Intel i3 530 CPU

This should make it roughly the same specs as VM server 1 (ie. quad cores, 8GB of RAM).

Update: Turns out at least one stick of the RAM is completely defective (can’t even install the OS when it’s in) and the system occassionally blue screens with the other 3.  So now it’s down to just 3 gigs.  Also, the RAID array’s performance is being compromised by one of the drives lacking native command queuing.