Huge Advice When Upgrading Windows Server 2003 R2 to SP2

I just found out (the hard way) about something (that I could not find documented anywhere) that should be done when you are upgrading a WIndows 2003 R2 SP1 box to SP2 if you are planning on using WDS.

If you upgrade Windows Server without belonging to a domain, WDS will NOT work when you try and configure it. You will get a very useful error instead:

WDS Error Code: 0xe0000102

which can be translated to: "You should have been on a domain prior to installing SP2!"

AFAIK, there is no turning back. I tested this theory using virtual machines and it holds - no domain, no WDS, no cigar.

Importing a VM from another Product? Uninstall the Additions!

VMWare, VirtualPC, Virtual Server, Parallels - they all have one thing in common: in order to work faster, they install a set of drivers that patch the VM. This has a very positive effect on the virtual experience, but what happens when, say - the VMWare drivers are running under Virtual Server?

As you might have guessed it, no good things happen. Products such as Parallels and VMWare Virtual Server allow you to import machines that were created with Microsoft's virtualization products. If you grab a machine from Microsoft's VHD test drive program and import it right away, you are in for a nasty surprise. The drivers for the previous product are still there, and they *will* conflict when you install the additions of the new product.

So remember, get rid of your product's "additions" *before* migrating virtual machines.

How to get a machine to use a specific pxeboot file with WDS?

We are racing against time to get an application ready that needs to deploy images with WDS and Active Directory.  This is the latest problem I have encountered:

Ok, so based on this article (http://technet2.microsoft.com/windowsserver/en/library/383538a3-4129-4205-b363-d36b08e22ca81033.mspx?mfr=true) , when using WDS and having the machine boot, you can bypass the F12 keypress by replacing pxeboot.ini by pxeboot.n12.  This works like a charm, all machines that boot into the PXE server bypass the F12 key.   However, I would like to specify which machines should boot fron pxeboot.com and pxeboot.n12.   I generated an Excel sheet that has the info required to prestage the client on the AD.  This is what I have entered on the 4th row:

SERVER01   GUID    Location....  \\wds_server_name\reminst\Boot\x86\pxeboot.n12

This pre-stages the machine on AD and based on what I have read, will point the machine (identified by its GUID to boot from the pxeboot.n12 file).

I have used the script called "PrestagRISCInt.vbs" (found here: http://www.microsoft.com/downloads/details.aspx?familyid=aaf0a7a4-71c1-4ee9-b974-66214651a23b&displaylang=en) and issued the following command:

cscript /InputFile:C:\Foo.xls /Server:hpc-dc

After a short wait, I get the following message: "Success creating new computer accounts in Active Directory based on UUIDs!"

When I boot tha machine, it still requests F12 to be pressed, which means that it is STILL using pxeboot.com to boot.  

I have followed all the instructions carefully, any idea on what the problem might be? 

Go Away, F12! (or how to disable F12 at bootime to boot into WinPE)

While looking for a way to fully automate the installation of wim image file to a server, we immediately stumbled upon a small problem.   When doing a PXE boot, the boot rom imaged asked for the F12 key to be pressed.  If the key was not pressed, the machine booted normally into Windows - so much for the automation idea, huh?

Fear not, as Stephen sent me a link that explains the following from a RIS installation:

"...To enable a fully automated RIS-based installation, it is necessary to substitute the Startrom.n12 boot file for the default Startrom.com boot file..."

Further reading revealed this vital piece of information:

To configure all clients serviced by a RIS server with an automated installation, rename the startup boot files as follows:
• Change Startrom.com to Startrom.bak
• Change Startrom.n12 to Startrom.com

These files are located in the following directory location on your RIS server:

RemoteInstall\OSChooser\i386

There are certain differences between the RIS and WDS installations, but nothing big.   First off, the location of the files for boot time (given that it is a 32-bit box is the following):

\\WDS_Server_Name\reminst\Boot\x86

There you will not find Startom.com and Startrom.n12, but rather pxeboot.com and pxeboot.n12.

If you rename pxeboot.n12 to pxeboot.com, your machine will PXE boot and will NOT ask for F12 key press.   Ok, now that the problem is solved, we can go back and try to find solutions for the remaining 500.

Workaround for OCX State Problem (VMRC Active X)

On a previous post I was having problems with the VMRC ActiveX control when creating an instance at runtime.  The problem boiled down in having an invalid OCX state exception thrown at me whenever I tried to access a property of the VMRC ActiveX control at runtime.

After researching for quite a while on the Internet, it struck me that if I just placed the VMRC ActiveX in a UserControl at Design time, and instantiated that UserControl instead of the ActiveX directly, things would work great.  I implemented this into the VMCA application and it worked perfectly fine.   You can see I managed to get VMRC connections to different machines in different tabs at runtime on this post.

Some people have asked where they can get a copy of the VMCA.  Unfortunately as of now, the application hasn't been thoroughly tested and is missing some functionality which I deem as basic.  Also, this is something I have been working on my spare time and lately I have been swamped with other projects.  Perhaps the best approach would be to take it to stable phase and then try and get it on CodePlex so that everyone can pitch in...we'll see how that goes.

For all things related to software migration, be sure to visit Artinsoft's website. For training in Visual Basic to C# migrations, Visual Basic to VB.Net, Virtualization, and 64-bit training check our training web page.

Virtual Machine Configuration Assistant

As I previously mentioned, I've had some chance of working on the application dubbed as the Virtual Machine Configuration Assistant in the last few days.   One of the most noticeable changes are the GUI.  This is the old GUI of the app:

This is the revamped, improved version:

The application has undergone major revisions under the hood.  I have tried to separate tasks into different classes in order to gain modularity.  So far I have a VMManager, a VHDManager, a VMRCManager and so on.  Reading the code now makes a lot more sense than before.

This is the part in which most of the work has been lately done, the Disks tab:

From here, you can pretty much do anything related with VHDs.  After modifying some ISOs,  I have also managed to completely automate the defragmentation-precompaction-compaction phase required to reduce the size of VHDs.  Now I just leave the process running and when I arrive the next day, my VHDs are like 50% smaller.

I had not touched C# in a while, and all I can say is "Wow".  C# rocks, it is very intuitive and creating efficient GUIs is a bliss.  One can only wish that there was a 2.0 framework to run under OS X.

I have also fixed the problem with OCX stats at runtime - actually it was a workaround, not a fix.  Here is a video I made of some of the features of the application, which include:

• VHD Attachment
• VHD Creation
• VM Creation
• VMRC in tabs for each of the machines

*sigh*...It has been impossible to embed the video here, here is the youtube link.

In case the resolution of the movie above is too small, the avi can also be downloaded.

For all things related to software migration, be sure to visit Artinsoft's website. For training in Visual Basic to C# migrations, Visual Basic to VB.Net, Virtualization, and 64-bit training check our training web page.

Problems Creating a VMRC ActiveX Instance at RunTime

During the Virtualization labs, which are freely available to anyone interested in Virtualization, the Artinsoft trainers have had a chance to teach the Virtual Server COM API and its uses.  One of the attendees showcases the application that they build on his blog. I think the application in its finished state is a great start to create something functional, but it is in no way something that can be used for management right out of the box.  The reason for this is simple: we wanted simple in order to reduce the learning curve of the COM API. 

I have started to work on my spare time on a new version of the Virtual Machine Configuration Assistant (VMCA) which will be version 2.0 due to major UI overhaul it has had.   One of the cool things I wanted to do, was the ability to open VMRC connections within the app in tabs (gotta love tabs in everything!).  So here is the interface I have so far (click on the image for larger view, as it has info on what I am trying to accomplish):

Sounds easy, huh?  Well, that is what I thought.  I have in my application the reference to the VMRC ActiveX control, the image that you see above depicts a VMRC instance placed on the form in Design Time.

When the user selects the VMRC option, I have the following code:

vmrcControl = new AxVMRCClientControl();
vmrcControl.ServerAddress = "vs02";
vmrcControl.Size = new System.Drawing.Size(985, 675);
//Add a New Tab
this.tabPage1 = new TabPage();
tabPage1.Text = VMCA.VirtualInstances.getVMInstance().Name;
//Add the VMRC Control
tabPage1.Controls.Add(vmrcControl);
vmrcControl.Location = new System.Drawing.Point(0, 0);
this.tbcVMRC.TabPages.Add(tabPage1);
vmrcControl.UserName = "Administrator"

The line in red below is where all hell breaks loose:

The problems seems to be that at design time, the VS Designer creates and configures a resource that is used to keep track of the ActiveX instance's state.  At runtime, this resource does not exists and that is the reason why the ActiveX is an invalid state.  Not being the ActiveX hacker that I would like to be, I am baffled on this problem.

Have you ever suffered with a problem such as the one above?  I have looked for help at various locations without any luck.  Although not critical, this feature is something that would definitely rock.  Help me solve this problem and I will send you a couple of pure quality Costa Rican coffee wherever you may be (if you are in Costa Rica, I'll send you beer instead ;)

I have posted a project which repros the problem:

http://amd.streamload.com/artinsoft/Links/5B75335893

In order to repro, just debug the app, and from the menus select Remote Control...if you can somehow make it through without the invalid OCX state exception, you are right on the money.

UPDATE: In order to run the project above, you *need* to have the VMRC ActiveX control installed on your machine.  The following page will guide you with the necessary steps to complete this process: https://www.microsoft.com/resources/virtuallabs/installactivex-technet.aspx

For all things related to software migration, be sure to visit Artinsoft's website.  For training in Visual Basic to C# migrations, Visual Basic to VB.Net,  Virtualization, and 64-bit training check our training web page.

Why can't I delete a file in Windows?

Ever had this happen to you?:

I think this is the most annoying message that Windows has (OS X has one similar which is not very useful in letting you know what the problem is).  IMHO, I think that if the OS is informing you about an attempt to delete a file that has a handler open, it should be smart enough to tell you one thing: which is the application/process using it!!!

Fear not, as there is a workaround for this.   Unlocker is a (free) utility that will give you this info.  Once installed, it is a contextual menu:

Unlocker will then present you with a dialog that will let you deal with the situation:

One less Windows nuisance to worry about.  Credit where credit is due: Stephen was the person who referenced me to this program.

For all things related to software migration, be sure to visit Artinsoft's website.  For training in Visual Basic to C# migrations, Visual Basic to VB.Net,  Virtualization, and 64-bit training check our training web page.

Multiple Remote Desktops (on Windows)

I use CoRD for multiple desktops on OS X - it works like a charm.  But what about Windows users, what can they use?  After reading a bit on Dugie's Perspective, I read about MuRD (multiple remote desktops), which does exactly this trick. 

Further reading on his blog points out to vXCopy, which is like xcopy on sterorids (which was like the copy command on steroids).

I haven't tested any of the two, but I am sure the Virtualization crew at the upcoming Munich event will put vXCopy to the test when copying VMs through the network.

Longhorn Hypervisor in Action (and an Intel intro to Virtualization)

Longhorn Server will have a virtualization role that will basically replace the need to use Virtual Server when working with Longhorn.  If you want to play around with the new virtualization role as of now, it is not going to be possible because this feature not present in any public betas. 

If you are curious about what this "role" is and a little more information on how this will impact that way we run virtual machines, take a look at the following demo done byJeff Woolsey:

Video: Longhorn - Windows Server Virtualization

Try this link instead for no-registration hassle

If you are still a bit lost in terms of what virtualization is, check the Intel webcast below: