Powershell Goodies From Vexasoft

There are a number of features that make mass deployment of Mac OS X pretty easy. Some of these would be great to have in Windows. These range from systemconfiguration to networksetup and the ability to look at packages that have been installed and review their bills of material. Well, the good people at Vexasoft have built a number of Powershell libraries that, while they aren’t named as such, do a number of the features that these commands do, just for Windows clients via Powershell. And the best part is, a number of them are free. Let’s look at what some of these commands do:
  • First, there are the cmdlets used to manage the network stack (so similar to various verbs in networksetup). These include Add-NetworkAdapterDNS, Add-NetworkAdapterGateway, Add-NetworkAdapterIP, Disable-NetworkAdapter, Enable-NetworkAdapter, Get-NetworkAdapter, Remove-NetworkAdapterIP, Remove-NetworkAdapterGateway, Remove-NetworkAdapterDNS, Set-(followed by the others from the above sets) and Rename-NetworkAdapter.
  • Second, you can automate binding with Set-Domain. This is similar to dsconfigad but less awesome because it’s third party, but still more awesome than the native tools because it’s easier.
  • Third, rename the system. This is similar to scutil, hostname, sets. Just use Rename-Computer to change the name of a Windows system.
  • My favorite, having written something similar, is probably Get-RemoteDesktopConfig and Set-RemoteDesktopConfig, similar to the kickstart options in OS X.
  • And a tool similar to installer in OS X, Install-MSIProduct, which installs MSIs.
  • Sixth, there’s Set-Pagefile, because if you’re gonna’ change it, do so while imaging to save a reboot later…
  • While there are others, the final one I’d like to mention is still free: Get-RegistryKey, which gives us the ability to basically run the closest thing to defaults commands I’ve found against the Windows platform.
They install as standard Powershell modules, making them easy to drop into practically any imaging environment. Much of these can be done via WMI or Powershell already, but will require a bit more legwork to script. Having them pre-built makes it easier than ever to perform some basic tasks for other platforms en masse, on Windows.

DeployStudio: Rename a Volume with Host Name

DeployStudio has the ability to rename volumes as part of a standard workflow. These are typically set to something like “Macintosh HD” (the default) or “Computer Lab” or something like that. But what if you wanted to name the volume something unique to a given computer, which makes it easier to keep track with what you are doing across a number of servers? You could create a workflow for each computer and change the hard drive name for each to something unique; but that would be tedious and pollute your list of workflows, likely resulting in accidentally running the wrong workflow at times. Instead, you could look at a really simple script in most cases (according to how complicated your logic for assigning names would be). To rename a volume, you can use the diskutil command along with the rename option. You would then list the existing name followed by the new name that you’d like that volume to have. In the case of DeployStudio the initial name of your boot volume might be “Macintosh HD” and to change the name to something like “Computer Lab” you would then use a command like:
diskutil rename Macintosh HD Computer Lab
It might then be logical to use a host name to rename a computer. Therefore, we could replace Computer Lab with the hostname command like so:
diskutil rename Macintosh HD `hostname`
However, this ends up showing the fully qualified name. Therefore, we could replace hostname with an scutil query for the ComputerName:
diskutil rename Macintosh HD `scutil –get ComputerName`
This would result in the name without all the .local, etc. But if you ran this as part of a DeployStudio workflow, you would end up calling the hard drive for all of your machines localhost. This is because the hostname or ComputerName will be queried from the DeployStudio set that you are booted to for running the DeployStudio Runtime. Luckily, DeployStudio has a number of variables that it can use in scripts. One of them is DS_HOSTNAME, which pulls the ComputerName being applied to the system at imaging. This means that if we were to rename the hard drive of the computer from Macintosh HD to the DS_HOSTNAME, you could use the following script:
diskutil rename /Volumes/Macintosh HD $DS_HOSTNAME
Now, one might think to oneself, couldn’t I just put $DS_HOSTNAME in the field for renaming the hard drive (part of a workflow). I tried it a number of different ways and couldn’t get it to work (in parenthesis, quoted out different kinds of ways, in different types of brackets and combinations of the above). If anyone knows of a way to use a variable in a GUI field within DeployStudio, let me know (I am guessing it can be done).