I very often tear down/distress my “lab” environment while working on docs/testing code/trying to replicate issues/etc. I was trying to recreate an issue the other day and decided to replace my vCenter Appliance. I deleted the VCSA, but left some of the other VMs, as they had some services I needed like DNS.
After deploying the a new VCSA, I noticed an error in the Cluster’s Monitor tab, under Virtual SAN, specific to my VSAN objects. The Compliance status for all my old VM’s was “Out of Date.”
I clicked on a single VM, picked my VM storage policy, and selected the VM home and clicked OK. I could have just as easily selected Apply to all. Not hard, but potentially time consuming in the case of a lot of objects.
I thought for a second. I’d rather not do this for each of these objects… Plus, I’ll likely tear down the VCSA again… So why not script it?
I looked at 2 PowerCLI cmdlets to handle this. Get-SpbmEntityConfiguration shows the currently assigned SPBM policy, along with whether it is compliant or not, and the last time it was checked. Set-SpbmEntityConfiguration sets SPBM configuration data for VMs, HardDisks, and cluster objects.
My PowerShell/PowerCLI is a little rusty, but I was able to crank out a one liner for the task.
|
1 2 |
Set-SpbmEntityConfiguration -Configuration (Get-SpbmEntityConfiguration | Where-Object {$_.ComplianceStatus -eq 'outOfDate'}) -StoragePolicy $_.StoragePolicy |
I didn’t really sort those objects, but adding “Sort -Property Id” to the Get-SpbmEntityConfiguration call would clean it up. Hard disks would then be listed under their VM’s home entity.
Refreshing the Web Client, all of the objects show as Compliant.
Also, in the script, I’m only reapplying policies to objects that are out of compliance.
A quick check using “Get-SpbmEntityConfiguration” shows that all my VM’s are compliant with their assigned Storage Policy.
Reposted from jasemccarty.com
