Around The Block Blog
by Justin Braun, Microsoft Product Specialist — September 03, 2009
This week, Compellent successfully submitted a 20,000 mailbox storage solution for Microsoft Exchange as part of the Exchange Solution Reviewed Program (ESRP). This adds to our 1,000 and 8,000 mailbox solutions that have been previously published.
For those of you who are not familiar with ESRP, it’s a Microsoft program that allows storage vendors to post specific storage solutions for different mailbox configurations for Microsoft Exchange Server. This is not a logo or certification program. It’s a solutions showcase. As part of the process, a series of tests are run with the results submitted to Microsoft and reviewed for accuracy and validity. Once reviewed and approved, a link is added to the whitepaper on the Microsoft ESRP website.
You’ll notice that in our submissions that the databases and logs are divided into separate disk folders. This is a requirement from Microsoft. We have discussed how the Compellent Storage Center works in depth with Microsoft and how our best practice is to work with a single pool of disk (our virtualization treats all disks in the array as one virtual storage resource and all reads/writes are spread across all the disks). Microsoft does not accept this type of configuration for submission with ESRP at this time; however, we’ll continue to recommend a single pool as a best practice. Simply put, Microsoft requires physical separation of the database and log disks for solutions submitted into ESRP.
We will continue to participate in this program and look forward to Exchange 2010, and Compellent continuing to provide best-of-breed storage solutions for Exchange.
You can find links to Compellent’s current ESRP submissions under the “Featured Downloads” section on the right sidebar at http://www.compellent.com/microsoft. We expect that Microsoft Technet will also be updated sometime in the next week to contain our new 20,000 mailbox submission.
Let us know if you have any questions or suggestions for ESRP testing by submitting a comment.
You can also follow me on Twitter at @justinbraun (http://twitter.com/justinbraun)
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
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.