As I’ve been managing more and more infrastructures using fibre channel storage, I’ve found that it’s been somewhat difficult to keep the LUN paths to each host balanced. By balanced, I mean that for each LUN to each host, there is a number of paths and I want to make sure that, for example, each LUN 10 to each of the hosts is using path A as the primary and path B as the stand by. LUN 11 uses path B as the primary, LUN 12 back to path A, and so on.

It so happens that I’m using a DMX-4 for storage, and the policy we have is to use a fixed path policy. I realize that Round Robin would make this entire script moot, well, except for making sure that the PSP is correct. I also realize that PowerPath would be the ideal solution for EMC storage, but we don’t use it…that’s a story for another day.

This script is, admittedly, long…longer than I expected it to be. The original inspiration for this script came from Justin Emerson’s very functional and succinct script, however I was not satisfied with the way LUNs were balanced. His script queries the host for LUNs then sorts them by canonical name and round robins the paths based on the number of paths present for the first LUN.

This works well, so long as all the LUNs are present on all the hosts and they all have the same number of paths. I can only presume that he assumes that those cases have already been checked for, and fixed, prior to execution. I wanted to do that all in one script.

Additionally, and it’s rather petty, I wanted the LUNs to be balanced based off their LUN identifier rather than the canonical name…they don’t always follow the same order, and in the case of my hosts with two HBAs (and consequentially, two paths per LUN), I wanted all odd LUNs to use one path for the primary and all even LUNs to use the other. Justin’s script does an excellent job of ensuring that the paths are evenly distributed, as you will end up with the same number on each, but not in the pretty fashion I desired.

Also, thank you to Glenn, who helped me “powershellize” this script…my PowerShell looks and reads like Perl, and therefore doesn’t use a lot of the optimizations that PoSH brings…such as automatic parameter handling and other niceties.

So, without further ado…

[cmdletbinding(SupportsShouldProcess=$true)]
Param(
    # name of the cluster to modify
    [parameter(Mandatory=$False, ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
    [String]$clusterName = "Cluster_01"
,
    # the multipath policy to set for LUNs. be careful with RoundRobin though...it requires some extra params for the Set-ScsiLun command
    [parameter(Mandatory=$False, ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
    [ValidateSet("Fixed", "RoundRobin","MostRecentlyUsed")]
    [String]$multipathPolicy = "Fixed"
) 
Process
{
    Write-Verbose "Getting list of hosts to check/modify..."
    Try
    {
        $clusters = Get-View -ViewType ClusterComputeResource -Filter @{'Name'=$clusterName} -Property Name,Hosts
    }
    Catch
    {
        Write-Warning " cluster $clustername not found"
        return
    }
 
    Try
    {
        $hosts = Foreach ($c in $Clusters)
        {
            $c.Host | ForEach-Object { Get-VIObjectByVIView $_ }
        }
        $hosts = $hosts | Sort-Object -Name
    }
    Catch
    {
        Write-Warning "Error enumerating hosts in $clusterName "
        return
    }
 
 
    if ($hosts.Count -lt 1) 
    {
        Write-Warning "No hosts were found in cluster $clustername "
        return
    }
 
    # determine the LUNs available
    Write-verbose "Determing LUNs and paths based on $($hosts[0].Name)"
 
    # get the LUN order based on the first host
    $hostView = $hosts[0].ExtensionData
    $storageView = Get-View $hostView.ConfigManager.StorageSystem
    $hbas = $storageView.StorageDeviceInfo.ScsiTopology.Adapter | Where-Object { $_.Adapter -like "*FibreChannelHba*" }
 
    $lunList = @{}
    $lunCnames = @{}
 
    foreach ($hba in $hbas | Sort-Object -Property Key) {
        foreach ($target in $hba.Target | Sort-Object -Property Key) {
            foreach ($lun in $target.Lun | Sort-Object -Property Lun) {
 
                $l = New-Object PSObject -Property @{
                    Target = $target.Key.Split("-")[2]
                    Lun = $lun.Lun
                    ScsiLun = $lun.ScsiLun
                    CanonicalName = $(Get-ScsiLun -VmHost $hosts[0] -Key $lun.ScsiLun).CanonicalName
                    Name = $l.Target+":"+$l.Lun
                }
                Write-verbose "Found LUN $($l.Name)"
 
                if (!$lunCnames[$l.CanonicalName]) {
                    $lunCnames[$l.CanonicalName] = @()
                }
 
                if (!$lunList[$l.Target]) {
                    $lunList[$l.Target] = @()
                }
 
                $lunList[$l.Target] += $l
                $lunCnames[$l.CanonicalName] += $l
            }
        }
    }
 
    $lunOrder = @()
 
    # by sorting these two hashes before looping, we end up with the LUNs being in C:T:L order
    $lunList.GetEnumerator() | Sort-Object -Property Name | %{
        $_.Value | Sort-Object -Property Lun | %{
            if (!($lunOrder -contains $_.CanonicalName)) {
                # since it's sorted, we can simply add to an array and it will retain the order
                $lunOrder += $_.CanonicalName
            }
        }
    }
 
    $i = 0
    $lunFinal = @{}
    $lunPathCount = @{}
 
    # now that we have the LUN C:T:L order, we simply round robin the avail paths
    foreach ($cn in $lunOrder) {
        $lun = Get-ScsiLun -VmHost $hosts[0] -CanonicalName $cn
        $paths = Get-ScsiLunPath -ScsiLun $lun | Sort-Object -Property SanID
        $x = $i % $paths.Count
        $path = $paths[$x]
 
        # the hash will store them in random order, but we don't care cause the path to use
        # was determined from the ordered array object...basically, don't be concerned later
        # in execution when the report doesn't have each one alternating exactly
        $lunFinal.Add($cn, $path.SanID)
 
        $i++
 
        Write-Verbose "Using $($path.SanID) for LUN ${cn} ( $(($lunCnames[$cn] | Sort-Object -Property Name)[0].Name) )"
    }
 
    # let's check each host to make sure it has the LUNs we found before
    # and report on any new or missing LUNs
    Write-Verbose "Verifying LUNs are on all hosts..."
 
    foreach ($vmhost in $hosts) {
        Write-Verbose "Checking $($vmhost.Name)"
 
        $hostLuns = @()
        $hostView = $vmhost.ExtensionData
 
        # using the view is faster here and still has the info we want/need
        # the where clause on this line will need to be evaluated depending on the environment
        # currently I only have EMC arrays, which all LUNs that are *correctly* presented have 
        # an NAA name.  I don't think all arrays are that way...so this may need to be modified
        $hostView.Config.StorageDevice.ScsiLun | ?{ $_.CanonicalName -like "naa.*" } | %{
            $hostLuns += $_.CanonicalName
        }
 
        # check for each LUN, remove if found, report if not
        foreach ($cn in $lunFinal.GetEnumerator()) 
        {
                Write-verbose "Checking LUN $($cn.Key)"
 
            if ($hostLuns -contains $cn.Key) 
            {
                Write-Verbose "`tLUN found on host"
 
                # remove the LUN from the array so we know it was found
                $hostLuns = $hostLuns | ?{ $_ -ne $cn.Key }
 
                # check for correct number of paths
                $pathsOnFirstHost = $($lunCnames[$cn.Key]).Count
                $pathsOnThisHost = $($hostView.Config.StorageDevice.MultipathInfo.Lun | ?{ $_.Lun -eq $lunCnames[$cn.Key][0].ScsiLun }).Path.Count
 
                Write-Verbose "Found $pathsOnThisHost of $pathsOnFirstHost expected paths for LUN"
 
                if (! $pathsOnFirstHost -eq $pathsOnThisHost) 
                {
                    Write-warning "LUN $($cn.Key) does not have expected number of paths ( $pathsOnFirstHost expected, $pathsOnThisHost found )"
                }
             } 
             else 
             {
                Write-Warning "LUN $($cn.Key) was not found on this host"
            }
        }
 
        # anything left in the array must be unique to the host...e.g. local storage
        if ($hostLuns.Count -gt 0) {
            foreach ($cn in $hostLuns) {
                Write-verbose "LUN $($cn) was not found in initial scan and will be ignored!"
            }
        }
    }
 
    # now we set each host in the cluster to use the determined paths
    foreach ($vmhost in $hosts) 
    {
	    if ($vmhost.ConnectionState -ne "disconnected") {
		    Write-Verbose "Starting configuration of $($vmhost.Name)"
 
		    foreach ($lunCanonicalName in $lunFinal.GetEnumerator()) 
            {
			    $lun = $vmhost | Get-ScsiLun -CanonicalName $lunCanonicalName.Key
			    $path = Get-ScsiLunPath -ScsiLun $lun | ?{ $_.SanID -eq $lunCanonicalName.Value }
 
			    IF ($PSCmdlet.ShouldProcess($VMhost.Name, "Setting $($lun.CanonicalName) active/preferred path to $($path.SanID)"))
                {
				    $lun | Set-ScsiLun -MultipathPolicy $multipathPolicy -PreferredPath $path
 
				    # this sleep time may need to be adjusted for different arrays
				    Start-Sleep -Seconds 3
			    }
		    }
	    } else {
            Write-Warning "$($vmhost.Name) is disconnected from vCenter"
        }
    }
}

When you have a lot of hosts, with a lot of LUNs, it can be difficult to keep abreast of the status of the paths for them. I have encountered issues where a path was unknowingly marked as dead, plus it’s generally a good idea to ensure that your storage paths are actually available.

Consequentially, I searched for a PowerCLI script that would give me a simple report of the status of each of the LUN paths to each of the HBAs on my hosts. I found John Milner’s post to be very helpful, and it gave me exactly the results that I wanted. However, it took forever to execute…almost 30 minutes for just one of my clusters (to be fair, that cluster has 12 hosts with > 100 LUNs and two paths to each).

Using his script as an example, and keeping a good bit of the formatting code, I have modified his script to use views of the host objects and cull the information from there. This makes it significantly faster…what took 28 minutes before now takes about 30 seconds.

$views = Get-View -ViewType "HostSystem" -Property Name,Config.StorageDevice
$result = @()
 
foreach ($view in $views | Sort-Object -Property Name) {
    Write-Host "Checking" $view.Name
 
    $view.Config.StorageDevice.ScsiTopology.Adapter |?{ $_.Adapter -like "*FibreChannelHba*" } | %{
        $hba = $_.Adapter.Split("-")[2]
 
        $active = 0
        $standby = 0
        $dead = 0
 
        $_.Target | %{ 
            $_.Lun | %{
                $id = $_.ScsiLun
 
                $multipathInfo = $view.Config.StorageDevice.MultipathInfo.Lun | ?{ $_.Lun -eq $id }
 
                $a = [ARRAY]($multipathInfo.Path | ?{ $_.PathState -like "active" })
                $s = [ARRAY]($multipathInfo.Path | ?{ $_.PathState -like "standby" })
                $d = [ARRAY]($multipathInfo.Path | ?{ $_.PathState -like "dead" })
 
                $active += $a.Count
                $standby += $s.Count
                $dead += $d.Count
            }
        }
 
        $result += "{0},{1},{2},{3},{4}" -f $view.Name.Split(".")[0], $hba, $active, $dead, $standby
    }
}
 
ConvertFrom-Csv -Header "VMHost", "HBA", "Active", "Dead", "Standby" -InputObject $result | ft -AutoSize

The result looks exactly like the original:

VMHost HBA    Active Dead Standby
------ ---    ------ ---- -------
host1  vmhba1 9      0    9
host1  vmhba2 9      0    9
host2  vmhba1 9      0    9
host2  vmhba2 9      0    9
host3  vmhba1 9      0    9
host3  vmhba2 9      0    9
host4  vmhba1 9      0    9
host4  vmhba2 9      0    9
host5  vmhba1 9      0    9
host5  vmhba2 9      0    9
host6  vmhba1 9      0    9
host6  vmhba2 9      0    9
host7  vmhba1 9      0    9
host7  vmhba2 9      0    9
host8  vmhba1 10     0    10
host8  vmhba2 10     0    10 

This is also helpful, for me, because each of my hosts should have the same number of active and standby paths…if there is more of one or the other, that’s an indication that a path is missing, or there is an extra for some reason. For example, the above is a single cluster, so they should all be identical. Multipathing appears to be good because there are the same number of active and standby paths. However, one host has an extra pair of paths…a simple check revealed that an old LUN had not been removed…no damage done, but very easy to spot with this script.

Thanks to John for doing all the hard work with formatting!

Last week I had the pleasure of presenting to the Atlanta PowerShell User Group.  The presentation was available over live meeting, if you missed it the recording can be found below.  The scripts used in this presentation can also be downloaded here.  Note we had a little problem getting the audio working so fast forward to the 2:00 minute mark.

Atlanta PowerShell User Group August 2011 from Glenn Sizemore.

~Glenn

I had an issue recently where a single ESXi host’s clock was incorrect. The administrator had never set the clock initially, so NTP never kept it in sync cause it was too far off to begin.

Since I’ve got a large number of hosts and the idea of clicking to each one through VI Client and checking the configuration tab, I immediately turned to PowerCLI. Naturally, one of Luc‘s scripts was the top search result.

That solved my immediate need to check the hosts, but I also wanted to setup some general monitoring. Since my monitoring infrastructure is compromised, primarily, of a linux Nagios host, that means PowerCLI couldn’t help. So, I did the next best thing and ported Luc’s script to perl.

Below is the result of that porting. It can also be run from vMA for reporting via email or another mechanism.

#!/usr/bin/perl
#
# vi-check-host-time.pl - written by Andrew Sullivan, 2011-08-17
#
# Please report bugs and request improvements at http://get-admin.com/blog/uncategorized/perl-toolkit-check-esxi-host-time/
#
# A perl port of LucD's script for checking the time of an ESX(i) host against
# the localhost to check for drift.  The original can be found here:
# http://communities.vmware.com/message/1732818#1732818
#
# Examples:
#   Check all hosts connected to a vCenter server
#   ./vi-check-host-time.pl --server your.vi.server
#
#   Check a specific host
#   ./vi-check-host-time.pl --server some.esxi.host
#
 
use strict;
use warnings;
 
use FindBin;
use lib "$FindBin::Bin/../";
 
use VMware::VIRuntime;
use Time::Local;
 
Opts::parse();
Opts::validate();
 
Util::connect();
 
# number of seconds that is tolerable for drift
my $allowedDrift = 20;
 
# get only hosts that are connected to vCenter, get only the name and dateTimeSystem MOR
my $hosts = Vim::find_entity_views( 
		view_type => 'HostSystem',
		filter => {
			'summary.runtime.connectionState' => "connected"
		},
		properties => [ 'summary.config.name', 'configManager.dateTimeSystem' ]
	);
 
foreach my $host (@$hosts) {
	# get the date of the system and all the parts so we can convert to epoch time
	my $dts = Vim::get_view( mo_ref => $host->get_property('configManager.dateTimeSystem') );
	my $hosttime = $dts->QueryDateTime();
	my ($year, $month, $day, $hour, $minutes, $seconds) = $hosttime =~ /(\d{4})\-(\d{2})\-(\d{2})T(\d{2})\:(\d{2})\:(\d{2})\.*/;
 
	# do the convertion to epoch time
	my $hostepoch = timegm($seconds, $minutes, $hour, $day, $month - 1, $year - 1900);
 
	# get the epoch time for the local system
	my $localtime = time();
 
	# check for drift, output something
	if ( ($hostepoch - $localtime) > $allowedDrift ) {
		print $host->get_property('summary.config.name') . " is " . ($hostepoch - $localtime) . " seconds off! \n";
	} else {
		print $host->get_property('summary.config.name') . " is within allowable drift \n";
	}
 
}
 
Util::disconnect();

My NetApp fanboyism is fairly well established at this point.  I devoted almost three years to developing a PowerShell module that would teach NetApp how PowerShell worked.  To my delight a year ago at TechED they took the storage world by surprise when they shipped an official module.  I was then humbled to learn that they had found PoshONTAP, and used it as a blueprint when developing the DataONTAP PowerShell toolkit.  This experience taught me a valuable lesson.  If you believe in something… just do it… life has a funny way of sorting it all out.  I took this philosophy an started anew , and my career ski rocketed.  The affirmation of all that work was when NetApp approached me six months ago.  At first I didn’t believe it was possible, but after many grueling interviews I started to realize I could do this job.  Fast forward two months and I’m all settled in at NetApp, and LOVING it!  This place is the google of the storage/IT world.  Everywhere you look there is another brilliant engineer, but something was still missing… The PowerShell toolkit had shipped and was doing fantastic, but PowerShell still wasn’t in the forefront of developers writing the tools for a windows administrators.  I thought about what I could do, again if you believe in something just do it.  Enter PowerGUI.

A while back Kirk had approached me about writting a PowerPack for NetApp, and I always thought it was a great idea.  So… I learned, and learned fast.  Turns out a PowerPack is fairly simple to author.  About a week later I had a working demo to show around internally.  I had my position papers worked out, and had the elevator pitch ready.  I was going to hit the streets and sell PowerShell using PowerGUI as my catalysis.  Then something amazing happened, everyone I showed PowerGUI to loved it! Furthermore they instantly knew the advantage of building a tool on top of PowerShell had.  I didn’t have to sell anything the tool simply sold itself.  At MMS this year if you stopped by during a lull you would have gotten an early alpha demo of the PowerPack.  I gave my boss said demo, and his guidance was clear, SHIP IT!  Over the past month with the help of the whole team, we went through the gambit from legal to marketing, but in the end my secret project shipped yesterday.  What started out as a sales tool ended up being such a compelling user interface that we just couldn’t keep it to ourselves.

If your a PowerGUI user of just a NetApp customer check out PowerGUI, and the PowerPack, as I think it is quite compelling.

~Glenn

Update: There is a known bug in PowerGUI where the first two objects returned don’t display alias properties, as the DataONTAP Toolkit uses alias’s heavily many object appear to be blank. Kirk’s team know about the issue and are working to fix it.

Grab this badge here!

The 2011 Scripting Games are almost upon us, and I for one am very excited.  There will be some modifications made to the games this year.  For one this will be the first year that the games will only be in one language.  This was done for several resons, but they all boil down to one…. There is simply no reason to not be using PowerShell at this point!  As a reformed VBScritper I for one welcome the change.

Another modification is that you will only be allowed to enter in one catagory.  There was some heart ache last year, because I participated in every event.  This raised the bar so that anyone who wanted to win would have had to produce 20 scripts in 14 days.  The other side of the coin was that I was unfairly entering scripts that a true beginer shouldn’t have to compeate against.  Both are valid points, and in hind site perhaps entering in both catagories was a poor choice on my behalf.  That said, I welcome only participating in a single catagory, as delivering two high quality scripts per day for two weeks was a daunting task, and I was burned out after two weeks.

Another potentialy game changing modification is that the submitions may not be visiable until after the deadline for a given challenge.  Again I welcome this change as last years games only had one or two original solutions per event.  By making the submitions private until after the deadline every solution will be original.  This change by it’s very nature will enable cleaver, and uniqe approaches to a problem.  I don’t think cheeting was a problem last year, but instead if you saw a script that used a rare .net object, and that script got 5 starts…. well doesn’t that influence you to use the same rare .net object yourself?  Of coarse it does, it’s only human nature to want to deliver the best solution possible.

At the end of the day whether your new to scripting or a seasoned pro I highly encourage you to participate in the games this year.  I for one will attempt to defend my title, but there will be stiff competition, and I will be shocked if I can pull off a back to back championship.  Oh yeah, and did I mention first prize will land you a free pass to TechEd Atlanta!

~Glenn

Recently I was asked to do a guest post on the illustrious “Hey, Scripting Guy!” blog. I was very happy, and excited by this opportunity, but didn’t know what to write. I kicked it around for a couple days, and still nothing. So I called an old friend and asked him what his pain points were. He informed me that his shop was now operating under a 24×7 operations cycle, and it was impossible to keep his 3000+ workstations patched. With that I had my topic; having worked in these environments before I was acutely aware of the strain they put on the sysadmin to stay compliant. A couple days later I had compiled all the best techniques for detecting if a user was active on his/her PC, and shipped my draft off the scripting guy. This morning Google reader greeted me with my very own post!

http://blogs.technet.com/b/heyscriptingguy/archive/2011/03/17/use-powershell-to-detect-if-a-workstation-is-in-use.aspx

Thanks to the Scripting Guy again for this awesome opportunity and I hope you enjoy the post!

~Glenn

I’ve had the pleasure of spending the last several days talking to the development team here at NetApp about the DataONTAP PowerShell Toolkit.  As a result we’ve all learned alot, one of the more interesting features they brought to my attention was the credential management solution included with the toolkit.  I found this very compelling, you see embedding credentials within a script is as old as scripting itself.  There was a time not too long ago when it was considered taboo.  However with PowerShell came access to the .net Security.Cryptography encryption/decryption methods.  Scripters have unknowingly been accessing said methods indirectly whenever they would use the credential management funcions that Hal amd BSonPosh wrote long ago.

Which brings me to the DataONTAP toolkit.  The Development team has steped it up a notch and included a full credential management solution with the latest version of the toolkit.  The way it works is first you need to save logon information by using the Add-NaCredential cmdlet to save the credentials for a given NetApp controller onto the local machine.  Then the next time you run the Connect-NaController cmdlet the credentials you previously saved will be used. So how do we use this new feature, and why do you care?

First the how, to get started you simply run the Add-NaCredential cmdlet for every Controller you plan on scriptitng against.  Some of you may notice a SystemScope switch, be aware that when you apply this parameter the credentials are saved in the systemscope.  This paramter is intended to be used in situations were you want to grant the SYSTEM account access to the credential store…. in other words don’t use it unless told explicitly that it’s required as this is inhearently less secure. It was included in an attempt to support any possible senerio…  That said, let’s add a controller to the local store.

[0:4]> Add-NaCredential -Name SIM01 -Credential root
Name                                    Credential                              HostUser
----                                    ----------                              --------
SIM01                                   System.Management.Automation.PSCrede... GetAdmin\glnsize

Now that the credential have been added to the local store you can connect to the target filer without supplying any credential information.

[0:5]> Connect-NaController SIM01
Name                 Address           Ontapi   Version
----                 -------           ------   -------
SIM01                192.168.19.130    1.12     NetApp Release 7.3.4: Thu May 27 15:43:26 PDT 2010

From a feature and functionality perspective it’s the same as using RPC, but will work with any protocol.   Additionaly because there is a proper PSCredential object embeded in the resulting NaController connection object,  you can also use the Invoke-NaSSH cmdlet without supplying any credentials!  Something you cannot do when connected via RPC.  For good measure the team also included a couple cmdlets to manage the contents of the credential store.

[0:6]> Get-NaCredential
Name                                    Credential                              HostUser
----                                    ----------                              --------
SIM01                                   System.Management.Automation.PSCrede... GetAdmin\glnsize
SIM02                                   System.Management.Automation.PSCrede... GetAdmin\glnsize

[0:7]> Get-NaCredential SIM02 | Remove-NaCredential

[0:8]> Get-NaCredential
Name                                    Credential                              HostUser
----                                    ----------                              --------
SIM01                                   System.Management.Automation.PSCrede... GetAdmin\glnsize

So weather your connecting on the fly or from within a script using the included credential store can significantly decrese the complexity while incresing the security of administering any NetApp infrastructure from a PowerShell prompt.

~Glenn

While driving up to RTP today I was listening to the PowerScritpting podcast episode 140.  Hal and Johnathan received a question about execution policy settings.  The conclusion they reached was that remote signed was a good compromise.  I would like to expand on this a bit.  The real fear with script execution is that you’ll unintentionally run code that has malicious intent buried within it.  Personally I don’t run around running code before I review and test it, but that doesn’t mean I’m safe.  As PowerShell MVP and trainer extraordinaire Don Jones has previously stated the risk is with your profile.

You see your profile is ran automatically, it is triggered by it’s mear presence.  If script execution is enabled you don’t even have to create the profile.  A co-worker could simply place one in your $PSHOME directory and powershell WILL run it.  So now that we’re in the land of malicious intent there isn’t anything you can do to stop said intent, but you can prove it wasn’t you.  This is why I have every pc in my domain set to AllSigned, but I then lower the execution policy to RemoteSigned after my profile is finished running.  This way even if someone does maliciously compromise my profile or a module I autoload there are two possible results.

1. The hash will be broken and powershell will not only not run the modified code, but it will also aleart me to the unauthorised modification.
2. It loads meaning someone has signed it with a valid certificate thereby leaving a forensic trace of the codes origin.

Finally, I would highlight that malicious intent isn’t always something egregious like removing all users in AD.  It’s often something simple like adding someone to a group there not authorized access to.  Before you run off snickering there is no reason to leave yourself exposed when there is a simple remedy.

First set your execution policy to AllSigned.  Then in your profile after you’ve loaded everything simply place the following line.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process

Now you have a best of both worlds scenario, protection for code that powershell runs automatically, and an environment more development friendly!    Admittedly there is still the potential that someone compromises a script or module that you don’t autoload, but the only remedy there would be to run AllSigned all the time… and well, if that was easy everyone would do it.

~Glenn

The VMware vSphere PowerCLI Reference will officially go on sale April 12th, and if your a vSphere administrator this one is a must have. We gathered the collective automation experience of four vEXPERTS and a MVP, and then filtered it through a fifth vEXPERT. The end result was a collection of polished solutions that are not only technically proficient, but more importantly will work the first time every time! Having all built and maintained large infrastructures we combined our collective knowledge and wrote a complete reference, we cover the entire life cycle from creating your environment to monitoring it long term. I mean it, we left no stone unturned where VMware had no PowerCLI solution we wrote our own. This book includes a PowerShell Module with 79 custom advanced functions! We also considered how you would use our book, and chose to take a task driven approach, this enabled you to just flip to the answer you need. You don’t have to “read” all 780 pages… instead think of this book as a fire extinguisher for your virtual infrastructure.

So that’s great, but who needs a book? With blogs and the community forums you can just find the answer right? Yes, yes you can eventually, but if you do that your shopping at a fishery. In this book we WILL teach you to fish! As a commitment to that end we created a dedicated web site to support our work. If you find a bug, or if we missed something you can post a question in our forum!

Admittedly this is my first published work, but I couldn’t be prouder of it. In my opinion The ONYX, and vSphere SDK chapters alone would be worth the cover price. I look forward to the release, and to your honest opinions of our work!

~Glenn