I have been playing with a third party (don't want to reveal )sync tool lately to backup and sync my personal and official content between my laptop and external USB harddisk. Initially I was very much impressed with the tool and loved it, until I came across with the limitation and as always the trial period which forced me to look for an alternative.

The free tool I discovered was SyncToy which you can download it here. The tool is excellent and does whatever I wanted. check it out!

Yes, deploying Windows Server 2008 Terminal Services is the cheaper solution which can give citrix like functionality at a fraction of a cost of equivalent citrix solution.

Let's see what are the different types of roles available for Terminal Services in Windows Server 2008 first. There are five roles:

1. Terminal Server - TS enables a server to host windows-based programs or the full windows desktop. Users can connect to a terminal server to run programs, save files, and use network resources on that server.
2. TS Licensing - TSL manages the terminal services client access licenses (TS CALs) that are required to connect to a terminal server. You can use TS Licensing to install, issue, and monitor the availability of TS CALs.
3. TS Session Broker - TSSB (formerly session directory) supports session load balancing between terminal servers in a farm, and reconnection to an existing session on a terminal server that is a member of a load balanced terminal server farm
4. TS Gateway - TSG enables authorised users to connect to terminal servers and remote desktops on the corporate network over the internet (YES, OVER THE INTERNET)
5. TS Web Access - TSWA provides access to terminal servers through a web browser or sort of like citrix application publishing over the web.

Recently, I had some trouble with my free burning software "DeepBurner" and was looking for another free alternative.

After hours of search on the web for a free tool, I realized that Windows 2003 resource kit has a free tool called DVDBurn. Those who love only gui will be highly disappointed because it's just a simple command line tool.

So, how do I get this utility? First, you need to download the reource kit from here and install it on your windows PC.

Then go to the command prompt and try the command as shown below. Of course, you need to change the ISO filename.

I pointed out about device access in my earlier post, differentiating between emulated device and non-emulated device in Hyper-V. Ever wondered how non-emulating devices work internally in Hyper-V? If not, then read on...

Device access virtualization is a method for sharing hardware efficiently without any emulation. All physical devices are controlled by existing device drivers without creating new ones.

VSP's or Virtualization Service Providers runs within parent partition. It talks to the respective device driver and acts as a multiplexer and offers hardware services to guests by establishing a communication with VSC's or Virtualization Server Clients over VMBUS (A communication channel for VSP's and VSC's).

VSC's runs within the child partition and acts as a service. For every VSC, there will a corresponding VSP in parent partition. It's the VSP/VSC pair which makes a device type within a guest. Microsoft provides VSP/VSC pairs for storage, networking, video, input, USB.

Ok. This is what I've learned so far about device access in Hyper-V.

For device access in Hyper-V, there are two underlying methods:- Emulated and VSP/VSC devices.

Emulated devices are just like the devices you have seen or used in Virtual Server 2005 R2. Whenever the virtual machine or VM attempts to access I/O, the hypervisor traps that request and the I/O gets emulated in the parent partition. This approach is highly compatible across most of the OS, but it has its own overhead and slow.

To overcome the above mentioned I/O performance issues, VSP/VSC devices have been developed in Windows Server 2008 Hyper-V. The hidden caveat is, these are supported only on specific OS. Of course, Windows 2003 and above is supported. This approach requires VSC drivers in the guest OS which looks like normal drivers in windows. With VSC drivers, I/O is not trapped by the hypervisor as it does in emulated one - rather the VSC drivers directly communicates with VSP's over VMBUS and operates much faster than emulated devices.

Ok, now we know the two underlying methods available for device access. Let's take a look at the type of disk contoller Hyper-V provides for storage. The excerpt below has shamelessly been copied from here.

There are two types of disk controllers that Hyper-V supports: SCSI and IDE.  There are two IDE controllers and four SCSI controllers available.

Each IDE controller can have two devices.  You can't boot from a SCSI controller.  This means an IDE disk will be required.  The boot disk will be IDE controller 0 Device 0.  If you want a CDROM it will consume an IDE device slot.

EACH SCSI controller can support up to 255 devices.

Both SCSI and IDE can support pass-through, Fixed, Dynamic, Sparse, and Delta drives (see http://blogs.msdn.com/tvoellm/archive/2007/10/13/what-windows-server-virtualization-aka-viridian-storage-is-best-for-you.aspx).  The difference lies in how the controllers are actually implemented.  The IDE controller is emulated where as the SCSI controller is synthetic.  So what does this mean?

The IDE controller implements a well-known IDE controller and this means there is extra processing before the I/O is sent to the disk.  This processing occurs in vmwp.exe (a user mode process that exists for each started VM.  More on this in a later post).  Once the IDE emulation is complete the I/O is sent into the Root Partition’s I/O Stack.  I/O completion requires a trip back to vmwp.exe.

The SCSI controller is not emulated.  The SCSI controller uses VMBUS (Virtual Machine BUS.  More on this in a later post).  The I/O's pass from the Child (aka Guest) Partition to the root over VMBUS and enter the I/O stack.  You can already see one less process/machine context switch is required because vmwp.exe does not get invoked.  Once and I/O completes its completion is sent over VMBUS.

There is a lot more to how both the IDE and SCSI controllers work however the descriptions below should help you to understand why SCSI controllers are the right choice for the best performance.

One of the main reasons you can't boot off of SCSI device is because it is implemented as a synthetic device in Hyper-V and the VMBUS is not available during the boot. Rest of the devices such as CD, IDE, Legacy Network Adapter and Floppy is supported though.

Note: Since Hyper-V is not RTM'ed all numbers are subject to change as are the behaviors.

I've been testing Hyper-V lately and thought of compiling a list of things which are either incompatibilities, issues or "bugs" with Hyper-V.
Note: This is what I have experienced personally or from the field and is never a complete one. I'll be updating it as and when new information is available.

1. All roles except DC (Domain controller) role is supported
2. If you are using virtual switches in a VM cluster then make sure they are identically named on both nodes. Make sure you have installed integration services before attempting a failover. I also noticed that creating virtual switches using the GUI during installation doesn't cut it and you need to delete it and recreate it again to make it properly work inside a cluster
3. Since, we are dealing with pre-release material here and one thumb rule is, don't expect everything to work straight forward. For instance, upgrading a VM configured on Hyper-V pre-beta code (RC0) to Hyper-V Beta RC1 may not be supported and may offer un-predicatable results.
4. Always install the virtualization integration components for Linux inside Virtual Guests. Otherwise, you won't see the devices. The Linux downloads are available from Connect Website 
5. While enabling Hyper-V role, make sure you keep (do not change) EN-US as your default language otherwise you may get VMM service failures and Hyper-V wouldn't start
6. Wireless network adapters on laptops are not supported by Hyper-V.

I recently did an implementation where the customer wanted to have a solution where they can have redundant print servers serving all the print queues and migrate all of them without any outage. Among couple of different options - MSCS, NLB, DFS etc, we went with NLB.

I'm going to give you the complete details on how we did it. Though this works seamlessly and customer is happy, it is not "supported" my MSFT. So, decide and use at you own risk.

1. Configure NLB on the 2 servers using the "Network Load Balancing Manager" (part of Admin Pack) use a dedicated NIC on each server and use unicast. Some CISCO routers do not pass ip address with multicast MAC addresses

2. Set NLB Port Rules to listen on port 135 (TCP/UDP) and ports 1024-65535 (TCP/UDP)

3. Configure the print queues identically on each server including Printer Name, Share Name, Driver etc. You can use printmig utility (download here). You can setup all your queues on one server and migrate them over using the tool to the second server very easitly.

4. Make the computer policy change on both servers. On the Local Computer Policy set "Computer Configuration > Administrative Templates > Printers > Allow Print Spooler to accept client connections" to Enabled and restart the Print Spooler service.

5. Manually create a DNS A record pointing to the IP of the NLB Cluster.

Now comes the tricky part - Obviously, those who need a new mapping would go with \\NLBClusterName\PrinterShareName, very simple and easy right?, but what about those users who are still mapped to the printers using old name? Alright, here's the trick - First you add a DNS A record for the name of each of the old print servers which points to the new cluster IP. Be sure to remove the old DNS entries or rename them to avoid duplicate name and un-planned outage (needless to say that a proper change management is required.)

7. Add an alias entry for each old server name you want the new server to be identified with on the new load balanced servers. The idea here is, if anyone uses old server name to map their printer, they'll automatically be re-directed to the new one.

Navigate to registry hive, HKEY_Local_Machine\System\CurrentControlSet\Services\LanmanServer\Parameters

Add Value: OptionalNames REG_SZ String: "Alias"

If you make it a type REG_MULTI_SZ, you can add multiple aliases.

If do not like step 7 and feel that you shouldn't be dealing with old print server names then use login scripts to re-map your users to the new print server or deploy a software package using a software deployment tool (SMS, Altiris etc) to re-map them.

Have Fun!