I’m still on my quest to automate the installation of a pretty complex environment and I’m writing down what I learnt in case I need it again one day or even better someone else will find it useful and save them some time.
Updating environment variables
There doesn’t seem to be a built in way to set environment variables in PowerShell but you can use the Environment class from .NET to retrieve the current value:
[Environment]::GetEnvironmentVariable("Path","Machine")
and to set the new value:
[Environment]::SetEnvironmentVariable("Path", "New Path Value.", "Machine")
I also saw another method editing the registry key that contains the Path variable but the problem is it doesn’t update it for the current PowerShell session, you have to restart PowerShell first. From my testing, using the Environment class immediately updates it for the current session and broadcasts the change so new sessions will pick it up without restarting.
The InstallShield interactive user problem
One of the 3rd party components I was installing via PowerShell worked perfectly well when you run the script from the command prompt but failed with permission denied errors when running the script from Octopus deploy or any other remote method. All the methods used the same account and it had admin rights on the box. It took a while and some googling to finally get to the bottom of it. It turned out to be the InstallShield Script Engine (ISScript) and in this environment specifically version 10.50. If you look at the DCOM configuration for that version you will see it is set to run as the interactive user which won’t work when you are running it from a non interactive session, it should actually be the launching user.
The other versions I encountered didn’t have this problem, they are all set to the launching user by default.
The installer needed this specific ISSsript version, if it is not present, the Setup.exe will install it. To get past this problem you have to explicitly install ISScript instead of leaving it up to the Setup.exe then change the DCOM config to use the launching user and then install the software using the MSI not the Setup.exe. If you use Setup.exe it will change your DCOM config back to the default before running the MSI installer. If you want to change the DCOM config from a script you can delete the RunAs registry key, make sure you have to correct AppID for the version of ISScript in this case {223D861E-5C27-4344-A263-0C046C2BE233} for 10.50.
Config file encoding
I had a component failing with invalid configuration error messages even though the file looked fine and was even identical to the config file from a working system when doing a text compare. In retrospect I should have done a hex compare as well. Turns out the encoding of the file was UCS-2 LE BOM instead of UTF-8 and this happened because I was reading the file contents, making changes and then writing the file out from a collection of strings in PowersShell.
To fix it you have to specify the encoding when writing out the file in PowerShell.
Add-Content -Encoding UTF8 -Path C:\File.txt -Value ValuesToWrite
Capture PowerShell output to file
When you are creating automated deployments it is not uncommon for scripts to work when you run them manually but fail during the deployment from a build server or other deployment automation tool. If you want to debug what is happening you can add your own Write-Output statements all over to trace where you are but this gets tedious very quickly. A better way I find is to use the PowerShell Transcript cmdlets.
Start-Transcript -path YourLogFile
and
Stop-Transcript
The filename is optional and if you omit it PowerShell does have some smarts built-in around overwriting and naming the file, you read more here.
