I mentioned I was doing some PowerShell work to manage configuration on the R2 versions of Windows Server 2008 Core and Hyper-V server (which now support PowerShell), and somebody in Redmond asked me if I knew there were tools out there to do this job. …
I was thinking about how we find stuff, and I was something I wrote about Taxonomy came to mind.
Store data in the data, not in the field name. Do not create a long list of properties with yes/no answers. Not only is this awkward for users, but the sequence “Relates to product A, Relates to product B” stores Yes and No as the data. A multi select box “Relates to products…” stores the information where you can search it. (This was dealing with document properties in the first release of Sharepoint Portal Server.)
What has this got to with command lines ? It’s about thinking where the meaning is. I would say that it is true and self evident that the commands we enter should reflect the task being carried out. But (pre-PowerShell at least) it doesn’t happen. For example: suppose you want to configure Automatic Updates on Server 2008. If you run the full version of Server, the option is on the front page of Server Manager. But if, instead, you run the Core version, then what do you type at the command prompt ? (HELP won’t give you the command). You can trawl through all the .EXEs .BATs, .CMDs, VBSs, .WSFs and so on but you won’t find anything with a name like AUCONFIG. If you’re lucky you’ve got the core guide from the Windows Server 2008 step-by-step Guides page. That will tell you that you need to run
cscript scregedit.wsf /AU 4
The part which identifies the task (set updates to automatic) isn’t the script name (SC Reg Edit) but the switches /AU and 4 if the task was to set updates to disabled the switches would be /AU and 1. Traditional command line tools have a name which reflect what they ARE –the Server Core Registry Editor ScRegEdit in this case. These tools are overloaded carrying out different tasks based on their switches ( if you want a worse case, look at the Network Settings Shell – NetSh).
At the command prompt there is no way to discover the tasks you can carry out and their Command+Switch or Command+Switch+Value combinations ; you have to resort to product documentation, training or a helpful expert who already knows that /AC tells SCRegEdit you want to Allow Connections (via terminal services) but /AU sets Auto Updates (where else does 1 mean disabled ? ). By contrast PowerShell would have multiple commands for the different tasks – with names which reflect what they DO “Get-UpdateConfig” , “Set-UpdateConfig”, “Get-RemoteDesktopConfig” , “Set-RemoteConfig”. The commands are easily discoverable: and having found you have Set-UpdateConfig the tab key helps you to discover switches like –Disabled –InstallConfirmation –DownloadConfirmation and -Automatic instead of 1,2,3 and 4 used by ScRegEdit /au
It’s easy to see how the command line tools that we have grew up: and SC Reg Edit edits the registry on Server Core (hence the name) /AU sets the registry entries for auto Update and so on. But understanding it doesn’t remove the desire for PowerShell naming and discoverability. V2 introduces ReName-Computer and Add-Computer – (if you ask Add Computer to what the help will tell you it is a to a domain or workgroup). These tasks were previously done by the NetDom program, with its switches My aim is to add commands like Get-UpdateConfig” , “Set-UpdateConfig”, “Get-RemoteDesktopConfig” , “Set-RemoteConfig” “Get-IPConfig” and “Set-IPconfig” (and a few more) at their simplest these can be wrappers for SCRegEdit , Netdom, NetSh, Net, and the others, but the ideal is to go straight to management objects instead.
So next I’ll look at a couple of the simpler ones.