Quick Hit – PowerCLI as a Module and Loading it up

PowerCLI is a great tool, has been since about day one of Powershell. As Powershell has progressed and PSSnapins where replaced with Modules, PowerCLI took a long time to make the jump to modules. While stiff functional it was a point of question. So with version 6 it is mostly modules which is great, however now I have to tweak my Powershell profiles. Much like other customized shells (Operations Manager, SharePoint, etc …), I hate the single purpose shells so I had to customize my profiles. So what I have put together is real simple, and gets me started loading it up:

(get-module -Name vm* -ListAvailable).Foreach{Import-Module $_.Name}

Having fun with remote Registry

So I have not been able to really work with Powershell much in my new job.  A recent project had me involved with getting Windows 2008 R2 domain controllers into our infrastructure.  All of that was pretty standard.  There is one little setting that seems to get our security guys into interrogation mode.  That little icon on Windows 2008R2 and Windows 7 that shows if you have internet connectivity or not… It can be turned off via Group Policy easy enough but there is not much Powershell going on in this office so…

First example I showed was how to use the CLI to make the change the value locally using:

set-itemproperty hklm:\system\currentcontrolset\services\nlasvc\parameters\internet -Name 'EnableActiveProbing' -value 0 -type dword

I then wrote a script that when logged onto a server we could run to check the current setting and update it if necessay. 
This of course led to a challenge “can you show what all of our 2008R2 servers are set for”… As I said before there is not much Powershell in this shop so Remoting is not an option.  That is when I rediscovered a module that I had not used in over a year… PSRemoteRegistry I was quickly able to give a brief instruction on powershell modules and then show a quick example of how to remotely check the value and then set it appropriately if necessary:

get-regdword -Computer computername -Hive LocalMachine -Key system\currentcontrolset\services\nlasvc\parameters\internet -Value EnableActiveProbing
set-regdword -Computer computername -Hive LocalMachine -Key system\currentcontrolset\services\nlasvc\parameters\internet -Value EnableActiveProbing -Data 0

 Wala… Now the computer just needs to be rebooted and the Security folks won’t see these machines trying to test for internet connectivity.   Now I did have one machine that was my test machine that was not cooperative, matter of fact a valid set-itemproperty statement would actually cause it to duplicate the key but there was another issue on that machine at the time and I didn’t take the time to resolve what appeared to be a one-off case.

Been Awhile

Wow, I have not posted here in some time.  With contracting and then starting a new job I have to admit my Powershell focus has been sporadic.  It is interesting that an employer can hire you in part for powershell but then don’t want you to focus on writing or perfecting scripts.

I am posting today based on the Scripting Guy’s recent post.  One of the things I have found interesting is to see Windows Admins who aren’t interested in scripting.  Then I show them how to run a simple wmi query from the Powershell prompt.

Then the next step is show them how to create a profile (colorful text still seems to get attention Smile) and then provide normal daily activities that can be accomplished via a function within their profile.

Of course there is still the work of converting vbscript coders to Powershell.  Admittedly there still seem to be things vbscript is better at but showing vbscript diehards some of the advantages Powershell provides is fun.

Passing on the power of Powershell

I was recently asked to help a fellow systems administrator in one of our divisions with a request.  The request was simple enough with Powershell and when I provided the information the recipient shared the attempts they had made.  When I saw the example it was the familiar blue background of a powershell console and the syntax showed they were familiar with the Quest AD cmdlets….. 

I noticed they tried to run the same command several times just changing the SearchRoot.  So, working on the request I offered a one-liner they could use to replace it, simplifying it to list through the OU’s instead of specifying each one in another command line and formatting the output to make it easier to use.

So I offered the following syntax as a possible solution for their request (Report the count of objects in a set of sub-OUs).

get-qadobject -Type OrganizationalUnit -Searchroot 'some.domain.com/OURoot/SubOU' -SearchScope OneLevel | `
% {$_.CanonicalName + ": " + (get-qadobject -SearchRoot $_.CanonicalName -SizeLimit 0).count }

The one-liner  produced the results they looked for and I was able to explain the line continuation with the backtick (`) and the alias for ForEach (%).  The obvious next question was how do I save this to a script.  So I have an admin hungry for some information on Powershell so I had to create an easy to read script. I had to include something I recently mentioned (thanks to Karl Mitschke) to add a new twist and make the code a little easier to read.

$QADObject = @{
Type = "OrganizationalUnit"
= 'some.domain.com/OURoot/SubOU'
= "OneLevel"
# Create array of OU's to measure
$checkous = Get-QADObject @QADObject
# Process a count for each returned OU
ForEach ($ou in $checkous){
# Generate output in report format
$ou.CanonicalName + ": " +(get-qadobject -SearchRoot $ou.CanonicalName -SizeLimit 0).count

Of course I also had to ask what they were using for an editor and suggested that, since they were obviously familiar with the Quest AD cmdlets, they try PowerGUI.



Just thought I would post a quick note on my experience with the Powershell ISE.  In the past I have stated my preference for Powershell Plus as my Powershell script editor.  I am still a huge fan (well other than the new version seems to have an issue) of the product and in truth it is much more than a script editor. 

I also enjoy the PowerGUI editor but in general I do not use the PowerGUI suite, but when working on a script on a machine that isn’t my workstation, it was easy to install PowerGUI and have access to a decent editor.

With Powershell V2, the ISE was introduced.  I had used it briefly when giving an internal demonstration of Powershell to my colleagues.  I also must admit that I tried to customize it using the ISE specific profile but failed miserably and had given up on it.

A recent project had me developing a script on a server and considering latency it was just easier to RDP into the server and interact with the console.  With the ISE, I had access to an editor and a powershell command line interface without installing PowerGUI or any other software.  I am very impressed with the ISE for developing and debugging scripts.

That said, I still think Powershell Plus is a great tool set.  Any script editor that includes syntax highlighting is helpful and there are some other niceties such as automatically certificate signing scripts, snippets and code completion.  Where I still use Powershell Plus the most is the actual shell.  Whether working on a script or just simple day to day sell usage, I have found Iuse get-help much less since within the shell I can type a cmdlet or function and it knows about most if not all the parameters and includes links to help documents or searches.

Okay I have to get back to completing this script.


Technorati Tags: ,,,