vSphere Claim Rules with PowerCLI

We’ve been implementing HP 3PAR 7000 series into our environment. During this task we’ve tryied to be good admins by following the HP 3PAR StoreServ Storage and VMware vSphere 5 best practices.

Within this excellent resource there is a section for automating round robin policy for all 3PAR LUNs with a custom SATP rule.  That’s great, but it involves an esxcli command that must be run on each host:


For a small number of hosts that’s not too terrible--until you realize that you must either reboot each host or modify the policy for each LUN currently presented.  That’s not something that I’m likely to do.

With my aid of my technology buddy Google, I discovered several tidbits online:

• Philip Sellers has a blog that works through much of this in PowerCLI.
• Cormac Hogan has a blog that re-iterates the above, along with the commands required to unload each already claimed device (LUN), reload the claim rules, and rescan the HBAs.

Most of what I needed was out there already, of course. But I wanted to reload the claim rules in order to test the custom rule and without setting the policy individually on each LUN. I also didn’t want to impact every iSCSI LUN—just 3PAR—and there’s no need to reclaim a LUN that is already configured for round robin.

Here’s how I did it for each host:


Of course, I wrapped all of this around more PowerCLI that obtained a list of hosts in each cluster and managed the connections for esxcli.

If you receive any errors during the unclaim, make sure that your HA configuration is not using those LUNs as heartbeat datastores.  I experienced that problem which was easy to remedy in our environment.

Office 365 Staged Migrations with PowerShell

I have a love-hate relationship with PowerShell.  I want to love it and often do--except when my knowledge is lacking or it acts mysteriously (to me).
To aid my memory and perhaps help others, I've decided to post snippets as I continue my journey toward improving my PowerShell skills (I hear that shaking Luc Dekens' and Alan Renouf's hand at the same time increases one's PS Mojo).
With that out of the way, onward and upward.

---

We are in the midst of migrating from Exchange Server 2003 to Office 365 as a Staged Migration.  While not a particularly arduous task, it does involve pulling mailbox statistics and email addresses and using that information for the planning and creation of migration batches. It's tedious and error-prone.
Given a set of Exchange Servers, Domain Controllers, and a Universal Security Group, Get-MailboxSizes.ps1 generates a CSV containing mailbox names, server, size, number of items, office location, department, active mailbox flag, and string suitable for directly pasting into a Staged Migration CSV file.


The ActiveMbx column is TRUE if the user is not enabled or a member of a Universal Security Group used for tracking progress and automating other things.

The odd column header at the last column should be directly pasted into your Staged Migration CSV file as row 1.  For successive entries, copy that column value in filtered rows as you plan the migration.   Please note that this column assumes Active Directory Synchronization with Office 365.

We've been known to paste entries from the last column into Notepad for a quick Search-Replace of ",,FALSE" with ";".  That yields a list that you can paste into the To field of a notification email or add members box of the Universal Security Group.

I’d like to thank Iain Brighton who lent a hand when I was stuck with Custom Objects. Yea Twitter!