Learn about Windows PowerShell
Summary: Guest blogger, Mike Robbins, talks about using Windows PowerShell to manage Dell AppAssure.
Microsoft Scripting Guy, Ed Wilson, is here. Guest blogger, Mike Robbins, returns today to share his experience. You can also read previous blogs by Mike.
Mike Robbins is a senior systems engineer with almost 20 years of professional experience as an IT pro who currently works for a healthcare company located in Meridian, MS. During his career, Mike has provided enterprise computing solutions for educational, financial, healthcare, and manufacturing customers. He’s a Windows PowerShell enthusiast who uses Windows PowerShell on a daily basis to administer Windows Server, Hyper-V, SQL Server, Exchange Server, SharePoint, Active Directory, Terminal Services, EqualLogic Storage Area Networks, AppAssure, and Backup Exec. Mike is an author of a chapter in the book PowerShell Deep Dives, he has presented sessions at PowerShell Saturday 003 in Atlanta, for the Mississippi PowerShell User Group, and for the Florida PowerShell User Group. Mike is also one of the cofounders of the Mississippi PowerShell User Group.
Blog: Mike F Robbins Computing Solutions Twitter: @mikefrobbins Mississippi PowerShell User Group
For those of you not familiar with Dell AppAssure, it’s a backup, replication, and recovery solution. More information about this product can be found on the AppAssure website.
It’s no secret that I’m a big fan of Windows PowerShell so when a third-party vendor, such as Dell, adds PowerShell support to their products, I also become very interested in those products. (I’m not affiliated with Microsoft, Dell, or AppAssure in any way other than being a customer.)
AppAssure added Windows PowerShell support via a Windows PowerShell module in version 5.3.1 of their product. This module named AppAssurePowerShellModule includes a total of 31 cmdlets, which are listed in the following image:
Usually most vendors are slow to support the latest and greatest version of Windows PowerShell, but not AppAssure. According to AppAssure’s support documentation, How to Import the AppAssure 5 PowerShell Module, they prefer Windows PowerShell 3.0, although Windows PowerShell 2.0 is also supported. The examples found in this blog use Windows PowerShell 3.0 syntax, which also means that the AppAssure PowerShell module doesn’t have to be explicitly imported before using the cmdlets. If you were running Windows PowerShell 2.0, you would need to import the AppAssure PowerShell module by using the following command prior to attempting to use any of the cmdlets:
In the previous example, Name is a positional parameter which can be omitted if the first item specified after Import-Module is the name of the Windows PowerShell module.
From what I’ve seen in the industry, the average IT pro isn’t using Windows PowerShell yet. Hopefully that will soon change with more third-party vendors adding Windows PowerShell integration to their products and with cmdlets (such as those in the AppAssure PowerShell module) being so easy to use. Most of the cmdlets in the AppAssure PowerShell module require only opening Windows PowerShell on the AppAssure core server and running the cmdlet with no parameters or with very few mandatory parameters being required.
The Get-ProtectedServers cmdlet is a perfect example of this. It returns all of the servers that are protected by the AppAssure core server that you’re currently logged in to without specifying anything other than the cmdlet name. The information provided includes the server names, status, AppAssure agent version, and a few other properties:
Wasn’t that much easier and more efficient than using the GUI to retrieve this information? Grouping the protected servers to determine how many are listed for each version, or returning a list that is grouped by version (including the names of the protected servers for each version) are also easy tasks when using Windows PowerShell:
I’ve found something that it is difficult to determine in the AppAssure GUI. When I start replicating protected servers to another AppAssure core server, and I choose to initially seed the transfer via SneakerNet, how do I know when the seeding of the protected server to the portable media device is complete?
This is something that’s very important. Disconnecting it from the source AppAssure core server and shipping it to the site where the destination AppAssure core server resides, before the seeding process has completed, could cause the protected servers to not be replicated, not have a replicated base image, or have an orphaned chain of recovery points. Determining the seed drive progress for each protected server that you’ve chosen to replicate to a remote AppAssure core server is also easy to determine with Windows PowerShell as shown in the following example:
I’m not really a big fan of logging on to a server via a remote desktop to manage it. In the following scenario, I use the New-PSSession cmdlet to create a persistent connection to three AppAssure core servers. Two of the servers are in different Active Directory forests than the Windows 8 workstation where I am running the commands. Each of these AppAssure core servers requires different credentials than those I’m currently using on my workstation and to run Windows PowerShell. They also each require different credentials than the others:
According to the previously referenced AppAssure article, How to Import the AppAssure 5 PowerShell Module, the module shouldn’t be imported on a non-AppAssure core server. This is why I don’t have the AppAssure Windows PowerShell module installed on my local workstation. Using the Windows PowerShell Invoke-Command cmdlet allows us to remotely manage multiple AppAssure core servers while staying within the recommended supported configuration for using their Windows PowerShell module.
Now I can use a single Windows PowerShell command to check the status of all the protected servers in the three datacenters, which have an AppAssure core server. I want to know if any of the servers that are supposed to be protected by AppAssure aren’t being protected:
Based on the results in the previous example, I have one server out of all the protected servers in all three datacenters that has a status of unreachable. This doesn’t seem too impressive until you factor in that the three datacenters have a total of 53 protected servers:
With that many servers, it’s easy to see how efficient it is to use this Windows PowerShell command rather than using the AppAssure GUI (web) interface. It took a total of 1 minute and 25 seconds to query the three AppAssure core servers for the status on all 53 protected servers:
Two of the AppAssure core servers and twenty-two of the protected servers in the previous example reside at remote datacenters that are connected via a VPN across the Internet (not on the LAN).
We’ve only looked at one of the cmdlets provided in the AppAssure PowerShell module in this blog, but there’s much more that can be done with Windows PowerShell when it comes to managing AppAssure. Want to protect a new server? That’s what the Start-Protect cmdlet is for. Want to pause the AppAssure replication between AppAssure core servers during business hours and resume it after business hours due to bandwidth constraints?
That’s what the Suspend-Replication and Resume-Replication cmdlets are for. This is also where Windows PowerShell 3.0 comes in handy. You could use Windows PowerShell to set up scheduled tasks that run Windows PowerShell commands to pause and resume the replication. I wrote a blog about that very subject last month: Use PowerShell to Create a Scheduled Task that Uses PowerShell to Pause and Resume AppAssure Core Replication. It demonstrates this process, if it’s something of interest.
There is also an AppAssure event log added to the AppAssure core server during installation of the product that contains an abundance of information that can be queried by using Windows PowerShell—as you would any other event log.
Where can we find more information about Managing Dell AppAssure with Windows PowerShell? In the AppAssure 5 Technical Documentation section of the AppAssure website, there’s an AppAssure 5 PowerShell Reference Guide. You could also view the Help for the cmdlets contained in the AppAssure PowerShell module. If you’re interested in more blog posts about using Windows PowerShell to manage Dell AppAssure, see the AppAssure category on my site, Mike F Robbins Computing Solutions.
I would also like to invite you to join us on the second Tuesday of each month at 8:30 PM Central Time for the Mississippi PowerShell User Group meetings. These meetings are held online (virtual) via Microsoft Lync. Anyone from anywhere can join in and learn more about Windows PowerShell from our awesome line-up of speakers that we have scheduled throughout 2013. Each of our guest speakers for the remainder of this year is an author of at least one chapter in the book PowerShell Deep Dives.
Awesome blog post, Mike. Thank you so much for taking the time to share your experience with us.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
What part of a verb-singularnoun naming convention is hard to understand?
This pair is really interesting:
"failed" and "passed" are nouns now? ;)
These cmdlets really do not meet normal naming standards for cmdlet naming. It's a shame that the folks what wrote these cmdlets did not follow normal naming conventions of Verb-[prefix]Singularnoun. WHAT ever possed them to do it their way ?
For example, take the first cmdlet I see: Get-ActiveJobs.
The cmdlet name should be: Get-ActiveJob NOT Get-ActiveJobs. Or better yet, it should be: Get-DAActiveJobs or Get-DellActiveJobs. Plural nouns kills part of the discoverability of these cmdlets and the lack of a prefex increases ths likelyhood of naming collision. Both of these issues should have been avoided - and would have had naming standards been enforced.
I wonder if it's not too late to fix thesenaming issues, or whether the community will have to live with yet another module with very poorly named cmdlets, especially when they could have been better named (and should have been).