Moving Virtual Machine Storage using System Center Virtual Machine Manager (SCVMM) 2008 R2 SP1 (Quick Storage Migration)

Wow, it’s been a long time since I posted here.  I’m going to try to get back into the habit, especially with issues that I can’t seem to find answers to anywhere else.  Here’s one now:

My company recently bought a new SAN, and we are in the process of migrating the storage for our Windows Server 2008 R2 Hyper-V guest machines from using the Cluster Shared Volumes that are located on the old SAN to CSVs that are location on the  new SAN.

We have connected the hosts to both SANs, and have set up new CSVs in the new SAN.  We are using the Quick Storage Migration feature in SCVMM to migrate the storage.  This should result in little downtime while the machines are being migrated from the old SAN to the new SAN.

Theoretically, this is a simple process.  I say theoretically because, while this does actually work, it takes a little attention to detail to make sure this process happens smoothly.

The process as documented is fairly straightforward.  The goal is to move both the VM definition files and the .vhd files from the old SAN to the new SAN.  In SCVMM, this should be as simple as right-clicking the virtual machine, and choosing “Migrate Storage” from the context menu.  After that, simply selecting the new CSV in the Virtual machine path drop-down menu and clicking Next should take care of the rest.

Unfortunately, that is not always the case.

In our environment, we store the .vhd files and the VM definition files (.xml, .bin, .vsv, etc.) in the same folder, named after the machine (i.e. SERVER01).  When you select a new CSV from the Virtual machine path drop-down menu, the Virtual Disk Location should update to reflect the new path.  For example, if you were migrating SERVER01 from C:\ClusterStorage\VMOldSAN to C:\ClusterStorage\VMNewSAN, your Virtual Disk path should update from C:\ClusterStorage\VMOldSAN\SERVER01 to C:\ClusterStorage\VMNewSAN\SERVER01.

But beware…that isn’t always the case.

I haven’t found a rhyme or reason as to why, but for some machines, the path simply doesn’t update.  If you barrel forward in the process (by clicking the extremely tempting Next button), you’ll find that your VHD stayed where it was, but your VM definition files moved. And it’s the moving of the VHD files that takes so long, mainly because that operation is always completed using BITS.

So, how should a good (i.e. lazy, I mean, efficient) admin get around this issue?

The first instinct, of course, is to click the Browse button next to the Virtual Disk Location field.  But beware!  Doing so will either force you to create the directory first (which will mean that your VM definition files will end up in another directory called C:\ClusterStorage\VMNewSAN\SERVER01-1, autogenerated by SCVMM) – or if you choose the root folder (C:\ClusterStorage\VMNewSAN\), your VHD will end up in the root folder.

The most consistent way I’ve found to make this work properly is using Powershell.  Fear not, those who are still holding out on Powershell…I have good news for you.  SCVMM does its work under the covers with Powershell.  So, the SCVMM Migrate Virtual Machine Wizard can generate the Powershell script for you.  All you have to do is copy and paste it into Powershell.

Run the wizard as you normally do by right-clicking on the Virtual Machine, and selecting Migrate Storage.  Select your new destination for the machine by selecting the new CSV from the Virtual machine path drop-down menu.  If the path updates correctly, click Next and then Move But if not, you still click Next, but then click the View Script button.

In the script, you should find a line that starts with Move-VirtualHardDisk for each .vhd file associated with the machine.  You can ignore these lines.

You’ll then find a line starting with $VM =, a line starting with $VMHost = , and a line starting with Move-VM.  Those three lines are the key.  You can move the entire machine (including the .vhd files) with those three lines.  So, copy them (in order) and paste them (also in order) into a Powershell window (important note: make sure import the System Modules when you start Powershell, and are running Powershell as an admin!) and your machine and its associated VHDs will be moved to the new path, creating the new directory along the way.
Hope this helps someone avoid the pain that I had during migration!

Advertisements
Posted in Uncategorized | Leave a comment

Running the Research In Motion BlackBerry Simulators on Windows 7 x64

In my new position at Eastern Michigan University, I see more diversity in computing than I ever have, particularly in platforms, and specifically (lately) in smartphones.
 
To help make sure our hosted Zimbra solution is working well for the greater University community, we try to be more than just open to new devices…we actually want to test them.
 
We are using Zimbra’s Mobile Sync for synchronizing mobile devices.  This is basically an implementation of Microsoft’s Exchange Activesync, which works great for devices that use or have licensed the EAS technology, like Windows Mobile, Apple’s iPhone, Palm’s Pre, and some Android phones.  However, RIM’s Blackberry would typically use a Blackberry Enterprise Server (BES) to synchronize Blackberry devices with Zimbra.  (In fact, Zimbra has an add-on to allow BES to communicate with Zimbra called the Zimbra Mobile Connector for BlackBerry Enterprise Server.
 
As our Zimbra solution is hosted, we’ve chosen a different (read: less expensive) route to support Blackberries: Notifysync, which is basically an EAS client that runs on the Blackberry.
 
We ran acrossed a bug in Notifysync recently, and do not have any ‘extra’ Blackberries to test on.  After a bit of searching, I ran across the Blackberry Smartphone Simulators.  Perfect for my needs.
 
However, the simulators, as with all Blackberry software, run on Java.  And haven’t exactly been developed for Windows 7 (with the UAC) or for the x64 platform.
 
It turned out to be a formidable task to get the simulator running.  And as such, I’m hoping this post will save you some time and effort.  Here’s how I got the RIM Blackberry Smartphone Simulator for the 9630 running on Windows 7 x64, step by step.  I had a little help from a post on the forums.crackberry.com site – thanks for that, vedasmantra!
 
How I got the BlackBerry Emulator running on Windows 7 x64
  1. Install 64-bit Java SDK (I used jdk-6u17-windows-x64.exe)
  2. Install BlackBerry MDS simulator (I used Blackberry_Email_MDS_4.1.2.17.exe)
  3. Install a BlackBerry Simulator (I used Blackberry_Simulators_4.7.1.40_9630.exe)
  4. Change permissions on C:\Program Files (x86)\Research In Motion\BlackBerry Email and MDS Services Simulators 4.1.2\MDS to give Modify permissions to the user / group who will run the emulator
  5. Change permissons on C:\Program Files (x86)\Research In Motion\BlackBerry Smartphone Simulators 4.7.1\4.7.1.40 (9630) to give Modify permissions to the user / group who will run the emulator
  6. Modify the C:\Program Files (x86)\Research In Motion\BlackBerry Email and MDS Services Simulators 4.1.2\MDS\run.bat file to
    replace: !BMDS_CLASSPATH!;!BMDS_CLASSPATH2!
    with: %BMDS_CLASSPATH%;%BMDS_CLASSPATH2%

Launch the MDS from Start > All Programs > Research in Motion > Blackberry Email and MDS Services Simulators 4.1.2 > MDS

Launch the Tour 9630 simulator from Start > All Programs > Research in Motion > Blackberry Smartphone Simulators 4.7.1 > 4.7.1.40 > 9630

Closing the simulator can be a bit tricky.  You can’t use the typical Windows X or the File > Exit in the simulator.  Instead, create two files in C:\Program Files (x86)\Research In Motion\BlackBerry Smartphone Simulators 4.7.1\4.7.1.40 (9630):

controllerc.txt should include:
 
Exit
Kill
Quit
 
Stop9630.bat should include:
@ECHO OFF
C:
cd "\Program Files (x86)\Research In Motion\BlackBerry Smartphone Simulators 4.7.1\4.7.1.40 (9630)"
FledgeController.exe < controllerc.txt
 
Just run Stop9630.bat to close the simulator.  You can even put this file on the desktop.
 
And a huge important note if you want the Blackberry’s internet connection to work the second time you launch the emulator:
 
After launching the emulator for the second time, you will need to make sure it is using the 1x/EVDO network (not GPRS).  You can get there through Blackberry > Manage Connections > Mobile Network Options.  Change the Network Technology to 1XEV (from Global).
 
HTH.
Posted in Windows 7 x64 | Leave a comment

Windows SharePoint Services v3 Search – Class not registered

Class not registered.

Seems innocuous enough.

I recently started a project to upgrade our Windows SharePoint Services v2 sites to v3.  I set up some test servers, ran a test upgrade against backups of the production databases – all was smooth.

Until I tried the same thing in production.

Our web front ends are Windows Server 2003 R2 x64 boxes.  So, I set ASP.NET to run in x64 mode, and installed WSS v3.  I also set up a virtual Windows Server 2003 R2 x86 box running WSS v2 so that I could run the actual upgrade, as our v2 server is an x64 box running ASP.NET 2.0 in 32-bit mode, so I can’t do the upgrade there.

Seems all good.

The x86 box does the upgrade, and does it well.  The search service on the x86 box starts fine, creates the database on the SQL 2005 backend, and all is good.

Until I configure the search service on the x64 box.

And get the dreaded, "Class not registered."

The long and short of it is that after a call with Microsoft, I found out that the domain user I was using did not have the permissions to insert the information for the search service into the registry.  I haven’t tracked down the exact keys yet, but on the x64 box, the search service user needed to be an administrator on the box to set up search.  Not so on the x86 box.

Hm.

The document Microsoft sent me details which users need which permissions, and looks like it was grafted out of the WSS v3 installation and configuration instructions, although I haven’t located exactly where yet.

More when I know the answer to which keys.  Until then, I hope this helps someone!

Posted in Uncategorized | Leave a comment

Connecting a Linksys WRV200 with a Cisco PIX 506e

My company uses a VOIP phone system, and has for about 2 years now.  Recently, we hired someone who will work out of her home in Minnesota.  Although we already have two full-time remote workers, I never had the time to explore exploiting our VOIP system by putting in a router-to-router (or, in this case, router-to-firewall) VPN and putting a VOIP phone at the remote office.
 
That’s recently changed.
 
So, armed with the knowledge that this experiment has a lot of potential pitfalls, I began looking for an inexpensive wireless SOHO router that could VPN back to my PIX.  And, amazingly, there is one – the Linksys WRV200.  More info on that device here:
 
 
So I drove over to Best Buy, and picked one up for $99.99 plus tax.  Definitely affordable.
 
Now came the challenge – could the WRV200 negotiate an IPSec tunnel with my PIX?  I started scouring the web to see what other folks had done – and although I found lots of references to Linksys to PIX VPNs, not one was using the WRV200.
 
I gave it a shot anyway.
 
And, amazingly, it worked – both the VPN AND the VOIP phone.  Flawlessly.
So, if you’re in a similar situation, let me tell you what you need to do.
 
Assumptions:
  • You’re not using Cisco’s EasyVPN on your PIX as a client.  If you do so, you cannot also have your PIX be a IPSec VPN server.  I don’t know if you can have your PIX as an EasyVPN server and a standard IPSec VPN server, but I doubt it.  I’d avoid the EasyVPN technology altogether.  YMMV.
  • Remote internal IP address range: 192.168.0.0/24
  • Remote external IP address: dynamic
  • Home office internal IP address range:  10.0.0.0/24
  • Home office external IP address: static

General instructions:

On the PIX, create an access list to allow trafic from the remote router’s internal IP range (or from a specific host address, if you want to get that detailed) access to your internal network (or to a specific host).  Using our assumptions, that would be:
 
access-list (insert a descriptive name here, like external_vpns) permit ip 192.168.0.0 255.255.255.0 10.0.0.0 255.255.255.0
 
Now associate your access list with an interface:
nat (inside) 0 access-list external_vpns
 
Permit IPSec connections:
sysopt connnection permit-ipsec
 
Setup your IPSec tunnel parameters:
Setup your transform set (how traffic will be encrypted and authenticated over the tunnel):
crypto ipsec transform-set (name your transform set here) esp-3des esp-md5-hmac
 
Associate your transform set with a dynamic map, because you have a dynamic IP on the remote end:
crypto dynamic-map (name your dynamic map here) 1 set transform set (name of transform set from previous line)
 
Setup your crypto map to map to your dynamic map:
crypto map (name your crypto map here) 10 ipsec-isakmp dynamic (name of your dynamic map here)
 
Associate your crypto map to the outside interface, so traffic going to the remote peer will be encrypted:
crypto map (name of crypto map from the previous line) interface outside
Next, you’ll set up how the tunnel will get negotiated:
Enable IPSec tunnel negotiation on the outside interface:
isakmp enable outside
 
Setup your shared secret to start the tunnel with any remote address (remember, the remote address is dynamic):
isakmp key (put in a complex shared secret here) address 0.0.0.0 netmask 0.0.0.0
 
Setup the PIX to send its outside IP as its identifier to the remote router.  This is necessary for the tunnel to negotiate with the WRV200:
isakmp identity address
 
Setup how the security associations are negotiated (encryption and authentication).  This must match the VPN configuration on the WRV200:
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
That should be all that’s necessary on the Cisco PIX side.
 
So, on to the Linksys WRV200.
 
Login to the web interface, and set up the DHCP server to be the remote office’s IP range:

Under the Setup section, go to the Basic Setup tab and configure the Lan Setup section to use the IP range – 192.168.0.0/24

[Optional – I wanted my remote clients to be able to see my home office computers by name – so I added the home office DNS server as DNS IP Address 1 (i.e. 10.0.0.2), and the Linksys itself as DNS IP Address 2 (i.e. 192.168.0.1)]

Configure the VPN tunnel:
On the VPN tab, go to the IPSec VPN tab and configure a Tunnel Entry:
  • Select a tunnel (the first tunnel is Tunnel A
  • Set the VPN Tunnel to be Enabled
  • Give the tunnel a name (i.e. ToHomeOffice)
  • If your home office PIX is NATted on the outside interface, you’ll need to enable NAT-Traversal – provided the device in front of your PIX will allow NAT-Traversal.  I didn’t have the problem, so you’ll need more info from elsewhere if you need to do this.
  • Setup the Local Secure Group to be your WRV200 router’s subnet (i.e. 192.168.0.0, 255.255.255.0), or the static address of the one remote host you want to traverse the tunnel.  If you choose a single host, make sure you assign that IP outside of the router’s DHCP scope!
  • Setup the Remote Secure Group to be your home office’s subnet (i.e. 10.0.0.0, 255.255.255.0).
  • Setup the Remote Secure Gateway to be the outside IP address of your PIX.
  • Setup Key Management to use the same methods as the PIX.  For the example above, that would be:
    • Key Exchange Method: Auto (IKE)
    • Operation Mode: Main
    • ISAKMP Encryption Method: 3DES
    • ISAKMP Authentication Method: SHA1
    • ISAKMP DH Group: Group 2: 1024-bits
    • ISAKMP Key Lifetime(s): 86400
    • PFS (Perfect Forward Secrecy): Enabled
    • IPSec Encryption Method: 3DES
    • IPSec Authentication: MD5
    • IPSec DH Group: Same as the ISAKMP
    • IPSec Key Lifetime(s): 3600
    • Pre-Shared Key: (Same as the complex shared secret in the PIX line that starts with isakmp key)
  • I enabled Dead Peer Detection to Recover Connection when it drops, as well as If IKE failed more than 5 times block this unauthorized IP for 60 seconds, and Anti-replay.

That’s it!  Now there are two ways to see what’s happening with your tunnel, and both are useful for troubleshooting:

On the PIX, at the console (or an SSH connection), do:

debug crypto ipsec
debug crypto isakmp

and watch the messages scroll by.

On the Linksys, under the VPN section, you can go to the VPN Summary tab and see the status of the tunnel.  You can dive deeper into the tunnel there as well, and see the errors in the VPN log.

Also, some commands to check the status of the tunnel on the PIX:
show crypto isakmp sa—View all current IKE security associations (SAs) at a peer.
show crypto ipsec sa—View the settings used by current security associations.
clear crypto isakmp sa—(from configuration mode) Clear all active IKE connections.
clear crypto ipsec sa—(from configuration mode) Delete all IPSec security associations.

Before deploying your remote router, I’d recommend going into the Administration section, under the Management tab, and setting up Remote Management of the router from the home office – i.e. the external IP address of the PIX.

Also, if you use a VOIP phone on this router, you can set the port that the phone is plugged into to have higher priority than the rest of the ports.  Go to the QoS section, and to the Port-based QoS tab, and enable QoS.  Then set the port to have High Priority.

Hopefully this set of instructions help at least one other person with the pain of setting up this type of VPN!

Once the tunnel is created, if everything is set up properly, traffic – including VOIP traffic – should flow fine.  You may need to setup your phone to communicate directly with the VOIP server, as typically the phone gets this info from the DHCP server – but it won’t in this case.
 

Posted in Computers and Internet | Leave a comment

Vista and BDD – custom partitioning

So, I’ve been feverishly working through deploying Vista using Microsoft’s Business Desktop Deployment (BDD) solution and Windows Deployment Services (WDS).  I’ve run into several snags along the way, and there’s one in particular I want to highlight, as I haven’t found references anywhere else on the web.
 
When you deploy Vista using BDD, there are several scripts that run.  One in particular (ZTIDiskPart.wsf) uses a text file (ZTIDiskPart.txt) that exists in your DistributionPoint\Scripts directory.  This script partitions your hard drive according to ZTIDiskPart.txt.
 
You might want to do this if, say, your company buys laptops from an OEM (like Dell or HP), and the OEM includes diagnostic and WinRE partitions in their builds.  You may want to save these partitions for your users, but still deploy a company-standard build of Vista.
 
Back to ZTIDiskPart.txt.  This file contains the commands for diskpart to partition your hard drive.  So, if you want to custom partition your hard drive, (or, at the very least, you don’t want to delete all the exisitng partitions and create one big partition, which is what ZTIDiskPart.txt does by default,) you need to edit diskpart.txt.
 
However, even after you’ve changed the diskpart.txt file, you will find (if deploying via BDD) that Vista doesn’t just automatically gett installed to the correct partition, even if you’ve assigned your partition the drive letter C: and made it active.  This is because of another script called LTIApply.wsf, which reads the location to install the Vista image from a text file called Unattend.xml.  So, to make sure to install Vista on the proper partition, you need to:
 
1. Edit diskpart.txt to create the right partitions.
2. Edit the unattend.xml file, which you can do right from BDD (which uses Windows System Image Manager, which is installed with the Windows Automated Installation Kit, necessary for BDD).
 
So how do you do this?
 
To edit diskpart.txt:
Find your distribution file share (assuming you’re using one for BDD).  Open up the Scripts folder, and edit diskpart.txt with Notepad.  You’ll need to know how to use diskpart (included in Windows XP and Vista) to edit this file properly.
 
To edit Unattend.xml:
In BDD, go to Builds, right-click your build and click Properties, select the Settings tab, and click the Edit Unattend.xml button.  This will open Windows System Image Manager.  To set the partition, in the Answer File pane, under Unattend, under Components, expand WindowsPE, expand x86_Microsoft-Windows-Setup_neutral, expand ImageInstall, expand OSImage, and click on InstallTo.  In the InstallTo Properties pane on the right, under Settings, set your DiskID and PartitionID to install Vista to the partition you set up in the diskpart.txt file.
 
Install your build as you normally would, and you’ll have an install of Vista on the correct partition!
Posted in Computers and Internet | Leave a comment