Ezine 177 – PowerShell Things Guy Has Forgotten to Tell You
♣
This Week’s Secret
The lunatics have taken over the asylum!
Everyone has their favourites, and also everyone has their Achilles’ heels. This week Guy is away and ‘Barking’ Eddie is going to tell you about stuff that Guy has forgotten to mention about PowerShell. Yes, I really do come from Barking, which is in Essex, England.
This Week’s Missions
- PowerShell’s Tab Completion
- -WhatIf and -Confirm
- Profiles and Add-PSSnapin
- Creating Your Own Cmdlets for Use in PowerShell
- Remoting
- .Net Framework
Save time typing out the full PowerShell command and use Tab Completion instead. The principle is that once you have typed enough of a command to make it unique, press tab and PowerShell’s intelligence reads your mind and completes the command. Recently I discovered that Tab Completion also works with -parameters; the extra twist is that tab cycles through available options -handy.
Example:
At the PowerShell prompt type just these 6 characters get-ch and then press tab. You should see the full command get-ChildItem. Next, view the parameters, once get-ChildItem appears type just the minus sign – then press tab. (No space after -)
Because that rogue Guy so rarely issues disclaimers, you really should get into the habit of appending -WhatIf to see if the script is going do what you thought it would. This technique is especially important when you use verbs such as ‘Set’, or ‘Remove’. To digress, you could list such verbs with: get-command -verb delete (or -verb set).
Once you feel confident with the basics of PowerShell, then it’s worth researching how to create a profile, because these settings will enhance your PowerShell working environment. One of the jobs for a well managed profile is to add snapins, such as those supplied by QAD. In a nutshell, snapins add cmdlets that third parties have cleverly crafted to make PowerShell easier to use in areas such as Active Directory.
In other ways Profiles are like a ‘Startup’ folder, or the Autoexec.bat that we old-timers used to have fun configuring. Your PowerShell profile will work, provided you focus on the singular word profile, never create anything with the plural of this noun. See detailed instructions here
Guy Recommends: The Free IP Address Tracker (IPAT) 
Calculating IP Address ranges is a black art, which many network managers solve by creating custom Excel spreadsheets. IPAT cracks this problem of allocating IP addresses in networks in two ways:
For Mr Organized there is a nifty subnet calculator, you enter the network address and the subnet mask, then IPAT works out the usable addresses and their ranges.
For Mr Lazy IPAT discovers and then displays the IP addresses of existing computers. Download the Free IP Address Tracker
Creating Your Own Cmdlets for Use in PowerShell
This is a fiddly technique, which could cause frustration for beginners. Long term it is best to store each set of PowerShell commands in a text files with .ps1 extension, these scripts are called cmdlets. The one piece of essential information that you need to know before you can actually run these cmdlets, is that you have to adjust the script ExecutionPolicy. My favoured way of doing that is to issue PowerShell’s own command: set-ExecutionPolicy remotesigned. Check your setting with get-ExecutionPolicy. To be fair to Guy, he has created a page on creating cmdlets.
The reason for this one-off configuration change is security. By default PowerShell protects the operating system from rogue scripts. To digress, VBScript malware is so effective because all that the bad people have to do is lure you to double click on a .vbs and thus fire off a virus that they wrote. PowerShell takes security seriously this is why you cannot double-click a .ps1 file and expect it to execute. Instead the technique is to create a store of .ps1 files then run them from the PowerShell command line with ./file.ps1. Actually, it’s not essential to add the .ps1 extension when you run the cmdlet, dot slash filename is all you need.
The killer weakness of PowerShell v 1.0 is ‘Remoting’. You have to rely on WMI work-arounds to run scripts on another machine. People always say that ‘This feature will be fixed in the next version’, in the case of PowerShell v 2. it’s true, you can see ‘Remoting’ in version 2 CTP (Community Technical Preview). The only reason that Guy has been reticent in extolling the benefits of PowerShell v 2.0 simply because you should NOT use it in a production environment.
Do nothing! Although PowerShell requires .Net Framework. You don’t need to study, or learn one thing about .Net to use PowerShell. Another example of how PowerShell ‘takes care of business’.
Guy Recommends: Tools4ever’s UMRA
Tired of writing scripts? The User Management Resource Administrator solution by Tools4ever offers an alternative to time-consuming manual processes.
It features 100% auto provisioning, Helpdesk Delegation, Connectors to more than 130 systems/applications, Workflow Management, Self Service and many other benefits. Click on the link for more information onUMRA.
If you like this page then please share it with your friends
See More Microsoft PowerShell WMI Examples:
• Home • PowerShell Get-WmiObject • Windows PowerShell • PowerShell 3.0 Network
• Win32_pingstatus • WMI Win32_NetworkAdapter • Win32_NetworkAdapterConfig
• Disable NIC • PowerShell -Filter • PowerShell -Query • PowerShell Select • Free WMI Monitor
Please email me if you have any example scripts. Also please report any factual mistakes, grammatical errors or broken links, I will be happy to correct the fault.
