Use PowerShell to disconnect the CDROMs from all VMs in vCenter

Recently I was moving all VMs from one NFS datastore to another so we could destroy the old volume. Storage vMotion took care of this for the most part, but even after moving the files, vCenter still showed that the VMs were using the old datastore. It turned out this was due to the VMs having mounted ISOs on that datastore. The solution was to eject/unmount the CDrom, but I didn’t want to do “Edit Settings…” and manually remove the CDrom for 200+ VMs.

I found this page which shows how to do almost exactly what I wanted via PowerShell. We’re using the vCenter Server Appliance though, which runs Linux, so I wasn’t sure how to run PowerShell stuff. But that was solved easily enough by installing VMWare’s PowerCLI package on my Windows desktop and connecting to the vCenter remotely:

PS C:usersevandocuments> Connect-VIServer vcenter.example.com

PS C:usersevandocuments> Get-Datacenter -name "Primary Datacenter" | Get-VM | Get-CDDrive | Set-CDDrive -Connected $false -NoMedia


Confirm
Are you sure you want to perform this action?
Performing operation "Setting Connected: False, NoMedia: True." on Target "CD/DVD drive 1".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Connect-VIServer pops up a username/password box where you put in your creds. The next command disconnects the cdrom for every VM in the “Primary Datacenter” datacenter in vCenter. I haven’t tried it but I think you can use different containers to scope the command however you want (cluster, resource pool, folder, etc). See here for other “location” options.

Advertisements

Exchange 2010 Post-Upgrade weirdness: can't edit Mail Non-Universal Group or Security Group

Now that everyone’s been moved to Exchange 2010 we’ve started using the 2010 Exchange Managment Console/Shell exclusively which has revealed some weirdness. First, we created a new group in AD using an old script (which used LDAP) and created a Mail-enabled Global Security group. We put people in the group, and everything seemed to be working fine until it was discovered that users in the group couldn’t see the group in the Global Address List. Users not in the group had no problem seeing the group. Additionally, users in the group couldn’t see users added directly in 2010. This only appeared to affect the GAL; the users were able to send/receive email fine with the full SMTP addresses.

Continue reading “Exchange 2010 Post-Upgrade weirdness: can't edit Mail Non-Universal Group or Security Group”

Exchange 2010 Post-Upgrade weirdness: can’t edit Mail Non-Universal Group or Security Group

Now that everyone’s been moved to Exchange 2010 we’ve started using the 2010 Exchange Managment Console/Shell exclusively which has revealed some weirdness. First, we created a new group in AD using an old script (which used LDAP) and created a Mail-enabled Global Security group. We put people in the group, and everything seemed to be working fine until it was discovered that users in the group couldn’t see the group in the Global Address List. Users not in the group had no problem seeing the group. Additionally, users in the group couldn’t see users added directly in 2010. This only appeared to affect the GAL; the users were able to send/receive email fine with the full SMTP addresses.

Continue reading “Exchange 2010 Post-Upgrade weirdness: can’t edit Mail Non-Universal Group or Security Group”

Changing all Exchange mailboxes to use database defaults for quota limits with PowerShell

Here’s an example of why I’ve come to love PowerShell. Under Exchange 2003, we set users’ mailbox quota limits per-user, since we initially set them ridiculously high (around 20 GB). The reason we did that was that prior to this year we actually didn’t have any quotas on user mailboxes and the average mailbox was about 9 GB. In preparation for moving Exchange to the datacenter (over our measly 5Mbps upload line) we introduced quotas and over the course of about 2 months gradually lowered the limits as people whittled away their old email until they were under the quota we had established (about 2.25 GB for the no-send limit — I forgot the rationale for that number — and 1.75 GB for the warning limit [the no-receive limit was set to about 40GB since I never wanted users to hit that limit]).

I think the quota limits Exchange 2003 would allow you to set through the UI were capped at around 2.0 GB so to set quota limits above this we used ADModify to update the mDBQuota* settings for each user directly in their AD entries.

However, now all those users have been moved to Exchange 2010 which let me easily set the quota limits on the Exchange DB to 2000 MB (warning) and 3000 MB (no-send). The problem with this was that all the users were set to override the database setting. How could I quickly set them all to use the database default once again? With PowerShell, this was simple:

First, get the list of all users not using the database defaults:
[PS] C:\Windows\system32>get-mailbox -filter { usedatabasequotadefaults -eq $false -AND recipientTypeDetails -eq 'usermailbox' }

When doing any bulk operation, always verify the list of objects you’re going to be modifying before actually doing the modification. 🙂 The first filter I created didn’t have the RecipientTypeDetails in it and included a DiscoveryMailbox, which I didn’t want to touch. The above command affects only UserMailboxes. If the list looks ok, set them all back to defaults:

[PS] C:\Windows\system32>get-mailbox -filter { usedatabasequotadefaults -eq $false -AND recipientTypeDetails -eq 'usermailbox' } | set-mailbox -UseDatabaseQuotaDefaults $true

And voilà, everyone’s back to using DB defaults (which I increased to 3000MB to celebrate not having to do any more mailbox moves any time soon).