Removing a disk from a powered on VM in VMware

Here is my procedure for removing a disk from a powered on VM on VMware 3.5. The procedure was tested on a Windows 2003 SP2 32-bit VM but should be applicable to other operating systems. This is unsupported, but I have not encountered any problems.

1. Remove drive letter/mount point in Windows Disk Manager
2. Right click on disk in device manager and choose uninstall (if you skip this step the plug and play manager will complain about unexpected removal)
3. Connect to host using ssh/putty
4. Get VMID with vimsh -ne "vmsvc/getallvms"
5. Get SCSI Controller Number and Disk from properties of disk in VC
6. vimsh -ne "vmsvc/device.diskremove vmid scsiControllerNumber scsiUnitNumber deleteFile"

Example:

vimsh -ne "vmsvc/device.diskremove 9999 scsi0 4 n"

Listing NetApp Snapshots using PowerShell

NetApp has recently released a support PowerShell module for managing Data OnTap.

You need to unzip and import the module
import-module DataOnTap

I'm just getting started with it, but I've noticed a few inconveniences. One of the first tasks I would like to do is list all snapshots older than a certain date.
get-navol myvolname | get-nasnapshot

will return a list of snapshots on a given volume, but unfortunately the time is stored as an integer. A little playing around discovered this will provide the correct information:

Get-NaVol myvolume | Get-NaSnapshot | select Name, @{Name="AccessTime"; Expression = {([datetime]"1/1/1970").AddSeconds($_.AccessTime).ToLocalTime()}}

It is possible to find snapshots older than one week using a command like:
Get-NaVol | Get-NaSnapshot | select Name, @{Name="AccessTime"; Expression = {([datetime]"1/1/1970").AddSeconds($_.AccessTime).ToLocalTime()}} | where-object {$_.AccessTime -lt (Get-Date).AddDays(-7)}

Hopefully version two of the module will use native data types to make this all easier.

DPM PowerShell: Force a Sharepoint Catalog to populate

Brief Description: After creating a SharePoint 2010 protection group in DPM 2010 the item level restore capability isn't browseable for up to 24hrs.

Problem: It's difficult to verify that your SharePoint protection group is configured correctly for item level restore if you can't actually browse it in the recovery pane, you could waste a lot of days making changes and waiting 24 hours to see if they were the right ones.

Solution:
To force the catalog to populate you can run the following powershell command from the DPM PowerShell commandline (thanks calebfinley for noting the need for clarification).

Get-ProtectionGroup yourdpmservername |get-datasource |where-object {$_.type -like "*sharepoint*"} | start-createcatalog

IsSharepointFarmProtected appears to be the only property that indicates the protection group is a sharepoint farm.

This can be re-run on an existing group, and can be run on a protection group which contains both a sharepoint farm and other objects like databases. The object type like is inelegant, but I'm still working on how to get it to compare the whole string.

Sharepoint Powershell: Finding and configuring databases to be configured as failover in Sharepoint.

First, I need to take a second to be an over the top fangirl about how great the failover mirroring is in sharepoint 2010 w/sql 2008 (R2 in our case). Beautiful, amazing, etc. Lightning fast failover not just from the DB side, but from the app side. We're only running a small test farm (compared to our much larger production infrastructure), and we haven't done serious load testing yet (so I hope I won't come back disappointed in a couple of weeks). But seriously, just in our "I hard crash the SQL server while our SharePoint administrator messes around adding items/clicking around" we're seeing one dropped request and no data loss (obviously you can't take messing around testing to the bank). It's synchronous mirroring so I suppose it would be shocking if it did lose data but still, so nice. Way faster failover than anything I've seen on SQL and since we don't have RAC, faster than I've ever seen Oracle failover either. Just gorgeous. Really, I'm not doing it justice. It's so pretty I want to buy it things.

Configuration of failover mirroring from the sql side is standard synchronous with witness. Initial SharePoint configuration is easy with the powershell interface. There's a lot of great articles out there. This technet article publishes the script.

You can run the following command to get the list of databases and their failover servers but if you have a whole bunch of content databases it's easy to miss, or misidentify one.
"get-spdatabase | select name, failoverserver"

Again, cribbed from the technet script for configuring database mirroring the first time is here. My hacking of the meat of the script to check for and configure unconfigured databases is below.

Param([string]$FailoverInstance = $(Read-Host "Enter the Mirror (Partner) SQL Instance(like server\instance)"))
get-spserviceinstance -all | foreach-object {
if ($_.typeName -eq "Microsoft SharePoint Foundation Database")
{
foreach ($Database in $_.Databases){
if ($Database.FailoverServer -eq $null) {
write-host "Found unconfigured database -- setting failover instance to " $Database.Name "to" $FailoverInstance
$Database.AddFailoverServiceInstance($FailoverInstance)
$Database.Update()
write-host "Successfully Updated Failover Partner on" $Database.Name "to" $FailoverInstance

}
else {
write-host $Database.Name "already configured."}
}
}
}