Around The Block Blog

Justin Braun, Compellent Technologies

PowerShell 2.0 Coming Soon—What's New? Part 2

by Justin Braun, Microsoft Product Specialist — July 13, 2009

Last week, I talked a little about some of the cool new features of PowerShell 2.0. Today, I’ll go over a few more and give you a way to share your experiences with PowerShell and the Compellent SAN.

PowerShell Integrated Script Editor (ISE)
I’m not sure about you, but starting out with PowerShell v1, I wrote a lot of scripts using Notepad.  As PowerShell became more popular, so did scripting editors for the PowerShell language.  Some were free and some were quite expensive.  Surprisingly enough, even though PowerShell was a Microsoft scripting language, they never added PowerShell language support for Visual Studio. 

With the release of PowerShell v2 comes the addition of the ISE, or the Integrated Script Editor.  This provides a GUI for script developers and also some nice features like syntax color coding and a form of IntelliSense, although that’s not they really call it.   It’s essentially auto-completion for cmdlet names.
Although it is a nice free addition that provides a better editor than using Notepad, it still falls short of some of the more professional editors on the market.

Script Functions
For the non-developer types, the inability to create your own homegrown cmdlets was a shortfall.  All cmdlets had to be coded in a managed-code language like C# and then compiled into a snap-in DLL to be accessed from the PowerShell command line.  In PowerShell v2, you can now create your own cmdlets via script functions.  It’s really just that easy!

Backwards Compatibility
Especially for enterprise environments, it is important to understand whether an updated technology now means an incompatible technology.  In the case of PowerShell v2, any scripts that you designed in v1 are completely interoperable.  It is also important to note that if you design scripts in v2 that make use of cmdlets only available in that version, special syntax is available to check the version of PowerShell being used before the execution of the script.  Nice!
This also means that the current version of the Compellent Command Set for PowerShell is also compatible with v2 of PowerShell and should work just fine.

Compellent Customers: Share Your Experience
Have you tried your Storage Center PowerShell scripts with the new version of PowerShell?  Share your experiences with fellow Compellent customers who also use PowerShell.  Share your scripts, ideas, or PowerShell questions over at the Compellent Customer Portal.

Read Part One
Justin Braun, Compellent Technologies

PowerShell 2.0 Coming Soon—What's New? Part 1

by Justin Braun, Microsoft Product Specialist — July 10, 2009

When Windows 7 and Windows Server 2008 R2 arrive later this year, PowerShell 2.0 will also make its debut as an integrated component for those operating systems and a Windows Update download for others like Windows XP, Windows Vista and Windows Server 2003.

A lot has changed in the newest release of this scripting language.  Over 70 new cmdlets are now available, along with the addition of remoting, background jobs, improved debugging, an integrated script editor and overall language enhancements.  Compellent will be integrating PowerShell 2.0 in our Storage Center Command Set for PowerShell for automated scripting.

Debugging
Debugging PowerShell scripts in the 1.0 release provided some challenges.  Not that it was impossible, but to me, it seemed to still resemble debugging principles of VBScript more than those used in Visual Basic or C#.  Nonetheless, the ability to directly debug inside PowerShell code in version 2 is there and contains cmdlets for setting breakpoints (Set-PSBreakpoint) as well as stepping in and out of code for all you developer types.  How about the ability to use a Try/Catch/Finally for exception handling?  That’s in there too.

Remoting
True enterprise integration and automation comes from being able to manage multiple components, servers, even environments from a single interface.  Remoting, something that seemed to be missing from the initial release of PowerShell will be available in v2.  Remoting will provide the capability to run PowerShell commands and scripts against a remote machine utilizing Windows Remote Management (WinRM) as the means to retrieve this information.  WinRM is the Microsoft implementation of WS-MAN, a standards-based, firewall-friendly protocol that provides management information securely.

Provisioning storage via the Compellent Command Set for PowerShell using PowerShell v2 means that you can run a single script from a management workstation that will handle that provisioning process which can now include one or more servers which also run PowerShell v2 and the WinRM configured as a listener.

Background Jobs
Scripts run under PowerShell v1 issued commands in a synchronous fashion, meaning that once the command was issued a response would have to be received before the next command would execute.  In PowerShell v2, background jobs are introduced via cmdlets: Get-Job, Receive-Job, Remove-Job, Start-Job, Stop-Job, Wait-Job.  This now means that when a command is issued, PowerShell is immediately ready for the next command, even while the first command is still in process.

This fits in perfect with the storage provisioning automation we just talked about. What if we could provision storage to 5, 10, or 20 servers all at once?  That’s right … These jobs can run independently and on totally different machines.

Check out part two of this post next week where I’ll discuss more of PowerShell v2’s capabilities and features.

Guest Post: MaximumASP and PowerShell

by Andy Stumph, Senior Systems Engineer with MaximumASP — December 16, 2008

 

Hi, my name is Andy Stumph and I’m a Senior Systems Engineer with MaximumASP. MaximumASP is a Microsoft Gold Certified hosting and IT services provider based in Louisville, Ky. We recently released a new product offering called MaxV. MaxV is virtual dedicated server offering that is hosted on Windows Server 2008, Hyper-V, Microsoft Failover Clustering and a Compellent Storage Center SAN and managed using the System Center Suite of products. We believe we are the first hosting company to market with a highly available / clustered virtual server offering based on Hyper-V!

The MaxV provisioning process is built entirely using PowerShell. When a customer signs up for a virtual dedicated server on the MaximumASP website, a set of PowerShell scripts kick off that runs the entire process, creating LUNs on the SAN, mapping those LUNs to a 14 node cluster, creating the virtual machine, running sysprep on  the VM, making the VM highly available and even setting up a backup routine for the VM. This whole process can be done in a matter of 15 – 20 minutes. In the past, provisioning a traditional dedicated server could take 2 – 3 business days.

One of the main reasons we are able to offer a clustered Hyper-V configuration with an automated process is our use of the Compellent Storage Center SAN. Compellent recently released a set of PowerShell cmdlets called the Storage Center Command Set for managing the SAN. These cmdlets are a key ingredient in this whole mixture. Without the Storage Center Command Set, MaxV would not exist in its current form today. If you had to use the GUI, imagine how long it might take you to create a LUN and then map that LUN to 14 servers across multiple interfaces…then log on to each server and perform a disk rescan. This can be done in seconds using PowerShell and the Compellent Command Set.

Below is a sample script that shows the power of the Command Set. It will connect to a Compellent Storage Center, create a new LUN from an existing replay, map the LUN across all cluster nodes and perform a disk rescan on all cluster nodes.

This is just a sample of the things you can do with the Command Set. There are a total of 60 cmdlets providing a very powerful set of tools for automating disk, LUN and SAN management.

function Get-ClusterNodes
{

$Cluster = New-Object -comObject MSCluster.Cluster
$Cluster.Open("") 

$Nodes
= $Cluster.Nodes 

foreach
($Node in $Nodes)     
     {
     
     [
array]$NodeList = $NodeList + $Node.Name
     } 

return $NodeList
$NodeList = $null
}

# Load the Compellent Command Set
if(!(Get-PSSnapin Compellent.StorageCenter.Scripting -ea SilentlyContinue))
{
Add-PSSnapin -Name Compellent.StorageCenter.Scripting
}
 

# Compellent SC Connection Variables
$User = "User"
$Pass = ConvertTo-SecureString "P@adf3adfe1" -AsPlainText -Force
$SCHost = "192.168.10.1" 

# Initiate Connection to Compellent Storage Center
$connection = Get-SCConnection -HostName $schost -User $User -Password $Pass -Save $SChost -Default 

# This is the description field for a given replay
$ReplayName = "GoldenImage" 

# Get the named Replay
$Replay = Get-SCReplay -Description $ReplayName 

# Create a new volume on the Compellent from the replay
$NewSCVolume = New-SCVolume -SourceReplay $Replay -Name "HyperVGuest1" 

# Get all nodes in the cluster
$Nodes = Get-ClusterNodes 

# Map the new volume to all the nodes in the cluster and perform rescan
foreach($Node in $Nodes)     
    {
      $SCServer = Get-SCServer -Name $Node

      
New-SCVolumeMap -VolumeIndex $NewSCVolume.Index -ServerIndex $SCServer.Index            
      Rescan-DiskDevice -Server $Node -RescanDelay 5                             
    }