Move vRanger Repository

I needed to move a vRanger Repository, but didn't want to start all my backups over, so I found a handy article from Quest that identifies how to do it.

FYI, I believe it requires vRanger 5.3 and up.
The basics are you go into SQL Management Studio, expand down to dbo.Repository to identify the repository, and change the host or target directory. Then go to dbo.RepositoryCIFS to change the sharename.

Make sure you restart the vRanger Services after making the changes.

------
Dustin Shaw
VCP

Datastore Alarm Not Accurate

I had the unfortunate mishap of a VM dropping offline because it outgrew the amount of free space on the datastore it existed on. On the plus side, it happened in the middle of the night and I wasn't on call :-) The on call guy simply had to reboot the box, and it came back online.
When I got in and looked, the datastore that it existed on had 0.00 B of free space. Not very comforting, considering the fact that there were no alarms on that datastore, and there were several other Production VMs on that LUN.
To fix the alarm state, it was easy. Go into the alarm definition and disable and re-enable it. This will force it to refresh it's states and you will get to see all the pretty yellow and red icons that you've been missing.

This also will work if it is reporting a Usage Above Threshold before it should too.

------
Dustin Shaw
VCP

vRanger "host could not be identified"

We had our vCenter sever hiccup on us yesterday, so (naturally) our vRanger backups failed last night.

The error we received was:

An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: VMSERVER's host could not be identified

Essentially what causes this issue is a communication sync error between vRanger and vCenter. I ran across this error a year and a half ago running on vRanger 4.x (you can read my post here). This time it was on Quest vRanger version 5.3.0, so I did a quick search to see if there were any newer solutions for verison 5. It appears that Quest now has a KB article about it.

Basically, their solution is to restart the services - stop the API and FLR Services, restart the vRanger service, then start up the API and FLR services.

I always prefer to go above, so I also refreshed the jobs (like my previous experience taught me) by opening them up and click next and finish all the way through (without changing anything).

Next time I'll remind my guys to restart vRanger services whenever vCenter bounces.

------
Dustin Shaw
VCP

Change DAG Witness Server - Exchange 2010 Hosted

I recently had to change a DAG on Exchange 2010 Hosted. This only uses the Exchange Management Shell, and I couldn't find instructions specific to this, so I thought I'd share my experience.

Requirements

Witness Server has the following Requirements:

-          Can’t be part of the DAG

-          Same AD forest as DAG

-          Windows Server 2008 R2, Windows Server 2008, Windows Server 2003 R2, or Windows Server 2003

-          Each DAG requires a different witness directory, but they can all be run on the same server

Permissions

Set permissions on target server –

Local Administrors group – add Exchange Trusted Subsystem

Reboot server to apply permissions

Commands

Go to Exchange Management Shell, and type in:

Get-DatabaseAvailabilityGroup | fl

There are two lines to pay attention to: WitnessServer and WitnessDirectory

To change the Witness server, type the following:

Get-DatabaseAvailabilityGroup | Set-DatabaseAvailabilityGroup –WitnessServer witness.serverdomain.local –WitnessDirectory C:\DAG1

------
Dustin Shaw
VCP

V2V from Hyper-V to VMware ESXi

So you finally came to the realization that Microsoft Hyper-V really isn't as mature as you were lead to believe. Good! You can attend the Gullible Anonymous meetings later. First, let's get you over to something that can keep your servers up and running and performing like the $10k you spent on your hardware should provide you.

Assuming that you have a free server available, doing a V2V from Hyper-V to VMware ESXi is extremely easy. Just think of this as doing a P2V, and ignore the wasted resources in between...

Take one of your spare servers, and load up VMware ESXi on it (you can do 4.1 or 5, or whatever strikes your fancy). Get it all ready for the VM to run on it, and get it on the same network and gig switch as your Hyper-V box.

Login to the VM that you want to convert, and download and install VMware's Standalone Converter on it (current version is 5.0). Current supported platforms are:

Windows XP Professional (32-bit and 64-bit)

Windows Server 2003 SP2, R2 (32-bit and 64-bit)

Windows Vista (32-bit and 64-bit)

Windows Server 2008 (32-bit and 64-bit)

Windows Server 2008 R2 (64-bit)

Windows 7 (32-bit and 64-bit)

Next, you will want to run the Converter against the local machine, and convert it to ESXi server that you just created. There are several settings to change to verify that it's done properly:

• Prep your computer for a P2V by stopping ALL unneccessary services. You only need core services to make sure that it's successful.
• Select Powered-on machine; local machine

• Put in the IP/Hostname of your new ESXi server and root/password

• Give it a destination Virtual Machine name
• Select a Resource Pool (if used), datastore, and Virtual Machine hardware version (unless you have a driving reason, go with Version 7)
• Set your disk drives the way that you want them to be on the new environment - I prefer Thin on all my disks, but it's up to you and your application. To change this, Edit the "Data to copy," Advanced, and Destination Layout tab. Change the type to Thin

• Change the Disk controller to SCSI. To change this, Edit the "Devices" and go to the Other tab. I typically select SCSI LSI Logic SAS for newer OSes and SCSI LSI Logic for older OSes.

• Set all services that say Hyper-V to disabled. To do this, Edit the "Services" and go to the Destination services tab. The ones I came across on my most recent migration were (your mileage may vary based on the version/options you have):
• Hyper-V Heartbeat Service
• Hyper-V Data Exchange Service
• Hyper-V Guest Shutdown Service
• Hyper-V Time Synchronization Service
• Hyper-V Volume Shadow Copy Requestor
• Edit Advanced options and go to the Post-conversion tab and check "Install VMware Tools on the destination virtual machine"

Off it goes converting. Once it's done, power down your Hyper-V VM, power up the VMware VM, and wait for the VMware Tools to install. Once that's done, uninstall the VMware Converter, and your off and running.

Now you can wipe your Hyper-V server, load up ESXi on it, and build yourself a nice little redundant cluster.

------
Dustin Shaw
VCP