Today I released Boxstarter v2.1.0 which includes support for piping multiple machines to the Install-BoxstarterPackage command and much improved options for receiving output on both the standard output pipeline as well as the host console. This release also adds a few bug fixes and some “Fit and Finish” details for remote installs.
These features were originally intended for v2.0, but the core 2.0 remoting integration proved to be much more involved than anticipated and stood well on their own. So in the interest of getting that release out the door sooner, I held off on these rather minor additions. I think this release does provide a better experience but it is the final prerequisite for the VM integration release coming next.
Multiple Machine Installs
While this is possible in v2.0 by simply looping over a list of computer names, connection URIs or PowerShell sessions, the first class support for installing packages on multiple machines does provide some improved efficiencies and an easier way of processing the results. Boxstarter can configure the local Windows PowerShell remoting settings for all machines at once instead of setting and rolling back on each machine.
The ComputerName, ConnectionURI and Session parameters of Install-BoxstarterPackage can now be passed in an array and can also be passed in the pipeline input.
$cred=Get-Credential=MyTargetMachine\myusername Get-WebServerNames | Install-BoxstarterPackage -PackagNamee WebPackage -Credential $cred –Force
Assuming Get-WebServerNames returns an array of server names, the above command will install the WebPackage package on each. Boxstarter will ensure that all of those servers are in the local machine’s list of trusted hosts and ensures that credentials can be delegated to them as well before establishing the remote session.
Receive installation results as separate objects on the pipeline
For each machine that Boxstarter runs the package, a PSObject is returned with metadata related to the results of the install.
The properties included in the PSObject are:
- ComputerName: The name of the computer where the package was installed
- StartTime: The time that the installation began
- FinishTime: The time that Boxstarter finished the installation
- Completed: True or False indicating if Boxstarter was able to complete the installation without a terminating exception interrupting the install. Even if this value is True, it does not mean that all components installed in the package succeeded. Boxstarter will not terminate an installation if individual Chocolatey packages fail. Use the Errors property to discover errors that were raised throughout the installation.
- Errors: An array of all errors encountered during the duration of the installation.
There are probably other properties that will be added to this object in future releases. Maybe a list of all chocolatey packages successfully installed.
Adjusting host output verbosity
A lot of the output that Boxstarter would previously output to the console is now sent to the verbose stream. In other words, by default, Boxstarter tries to limit output to things that are either of immediate interest or indicate that something that might take a while is taking place. Everything else is still available, but requires the use of the –Verbose parameter to be output to the console. However, all verbose content is always written to the Boxstarter.log file in case you want to refer to this information later.
If you would like to silence everything except the standard output stream (all verbose and write-host output), you can set $Boxstarter.SuppressLogging to $True.
> $Boxstarter.SuppressLogging=$True > "win7","win2012" | Install-BoxstarterPackage -PackageName test-package -Credential $cred -Force Errors : {} ComputerName : win7 Completed : True FinishTime : 11/30/2013 9:41:58 PM StartTime : 11/30/2013 9:41:54 PM Errors : {} ComputerName : win2012 Completed : True FinishTime : 11/30/2013 9:42:11 PM StartTime : 11/30/2013 9:41:58 PM
Other fixes and improvements
In addition to these features added, there are a few additional items worthy of notice:
- Don't touch UAC or AutoLogon registry keys on remote installs.
- Improve Remote Reboot detection and suppressing reapeted connection creations while remote machine is installing windows updates.
- Fix overriding organization update servers with the public Windows Update server.
- Fix remoting configuration when client has assigned Trusted Hosts to a global wildcard.
- Improve reliability of .net 4.5 installation as Chocolatey prerequisite particularly when running on a newly installed OS.
Up Next: Boxstarter Virtualization Module
Other than possible bug fix releases, I don’t plan on any releases between now and the first version of a new Boxstarter PowerShell module that focuses on VM provisioning. This module should provide support for Hyper-V, AWS, and Azure VMs. Given a VM name, Boxstarter will enable PowerShell remoting on the VM with no user intervention. It will eliminate the need to check and manually configure remoting on target machines. It will return a ConnectionURI that Install-BoxstarterPackage can use to install packages. At least for Hyper-V, this will include the ability to reset the VM to a specified checkpoint as well.
So stay tuned…