vSphere 5.5 is available for download!

Here's a nice blog post which highlights important KBs:

http://blogs.vmware.com/kb/2013/09/vsphere-5-5-is-here-kbs-you-need-to-know-about.html

Event ID: 4292 The IPSec driver has entered Block mode. - Server initially pingable during startup, then stops

This morning I had a VM which was inaccessible over the network.  The VM was "up" and I was able to log into the server locally using the console.  IP settings were good, I confirmed that the network settings on the VMware side were good, and I did the ol' disconnect/reconnect of the vNIC.  No Go.

One interesting thing,  upon reboot, I would receive ping replies, then they would abruptly stop:

The Event logs had the following:

Event ID: 4292 The IPSec driver has entered Block mode

Apparently, the IPsec service on the server 'lost its mind" and placed the NIC in a blocked state.  The resolution according to Microsoft KB 912023 is as follows:

To resolve this issue, follow these steps:

1. Delete the local policy registry subkey. To do this, follow these steps:
   1. Click Start, click Run, type regedit in the Open box, and then click OK.
   2. In Registry Editor, locate and then click the following subkey:
      HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\Policy\Local
   3. On the Edit menu, click Delete.
   4. Click Yes to confirm that you want to delete the subkey.
   5. Quit Registry Editor
2. Rebuild a new local policy store. To do this, Click Start, click Run, type regsvr32 polstore.dll in the Open box, and then click OK.
3. Verify that the IPSEC Services component is set to automatic, and then restart the domain controller.

In my case, the registry did not have the \IPSec\ Key...  So, I ended up just running following command and restarting the server:

regsvr32 polstore.dll

I bounced the server several times to confirm that the server came up clean and the issue had been resolved.

PowerCLI: How to Find VMs with Change Block Tracking (CBT) Enabled

Our previous backup solution had a  interface which conveniently displayed which VMs had Change Block Tracking (CBT) enabled.  Unfortunately, our new solution does not...

To quickly find the VMs which have CBT enabled, run the following "one-liner" against your vCenter server:

Get-VM | Get-View | Sort Name | Select Name, @{N="ChangeTrackingStatus";E={$_.Config.ChangeTrackingEnabled}} > c:\cbt.txt

Depending on how large your environment is, it may take several minutes to complete.  I piped the output to a text file for documentation purposes.   Here's an example of its output:

How to free up disk space in Windows 7 and Windows Server 2008 R2

I recently needed to free up a little space on the OS partition of a Windows Server 2008 R2 SP1 server.  One way to reclaim space is to remove the Service Pack files after a successful SP installation.

**Warning** Confirm that the Service Pack install was successful.  The following command will make the service pack permanent.  An uninstall will no longer be possible.

Run the following command against an online installation:

dism /online /cleanup-image /spsuperseded

 

This process takes several minutes to complete, but freed up close to 4GB of disk space.  This should hold me over until the server is ready to be decommissioned.

PowerCLI: How To Enable Change Block Tracking (CBT)

VMware Change Block Tracking (CBT) is a feature that assists in incremental VM backups.   The virtualization layer identifies the disk sectors which have changed within the virtual disk.  The backup software can then leverage CBT and request only the blocks that have changed since the last backup.  Incremental backups are waaaay faster.

The ESX(i) host must be version 4.0 or above and the VM version must be at least 7.

To enable CBT using PowerCLI run the following: (Thanks Lazywinadmin.com !):

$vmtest = Get-vm myvmname| get-view
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.changeTrackingEnabled = $true
$vmtest.reconfigVM($vmConfigSpec)

This can be run against a VM which is powered on.  (The VM must be powered off using the method in the VMWare KB).

To "fully" activate CBT, the VM must go through a "stun-unstun" cycle.   I typically just create a snapshot, then immediately delete it.

To confirm that CBT has been activated, browse to the folder of the VM and confirm that for each vmdk file, there is a corresponding xxxx-ctk.vmdk file:

PowerCLI: How To Find Snapshots in vCenter

I've been noticing a few stray/orphaned snapshots left by our new backup solution and was looking for a way to quickly locate them using PowerCLI.

1. Launch PowerCLI 5.1 as administrator, then connect to your vCenter server with the following command:

Connect-VIServer –Server "myvcenterserver" -Protocol https –User "myusername" –Password "mypassword"

Enter the appropriate info for "myvcenterserver", "myusername"and  "mypassword".

2. After connecting to your vCenter server, run the following command to query vCenter and find all of your open snapshots:

Get-VM | Get-Snapshot | Select Created, VM

The output will display the date and time the snapshot was created and the VM name.

To export to csv:
Get-VM | Get-Snapshot | Select Created, VM | export-csv C:\temp\snapshots.csv

Happy Hunting.

How to Find the File Allocation Unit Size reported in Bytes Per Cluster: fsutil

For most installations of SQL server, the SQL data and log files should reside on partitions with a 65,536 Byte (64KB) file allocation unit size/cluster size.  Cluster size is determined when the partition is first formatted.  By default, it's set to 4K.

In the past, I was using chkdsk to find the allocation unit size.  However, it takes a while to run...

To quickly find the current value for Bytes Per cluster, run the following command:

fsutil fsinfo ntfsinfo d:        
(Enter the appropriate drive letter for your environment)

For additional info on SQL Disk best practices:
http://msdn.microsoft.com/en-us/library/dd758814.aspx