Megosztás a következőn keresztül:


Installing VMRCplus 1.8.0 on Windows XP SP3 or Windows 7 SP1

I never expected to post another item on VMRCplus since we have Hyper-V for years now. But, I mentioned this before, there are still people using Virtual Server despite the fact that we have Hyper-V in Windows Server 2008 and beyond and that we also have a free product called Hyper-V Server 2008 R2. So I expected people to either use the paid product or the free product if costs were the issue. However there are other reasons for people to stay with Virtual Server. These vary from using Hyper-V incompatible hardware to internal certification or accreditation of products.

For whatever reason I still get mails on VMRCplus. People running into RPC issues, Access denied issues, incompatible .Net Framework issues, etc. Not long ago someone asked me to update VMRCplus for Windows 7. And today I got the same request. In this particular request it turned out the person had issues running VMRCplus on XP in Windows Virtual PC’s XP Mode. But VMRCplus, or any other application, is totally independent on the hardware configuration. It simply does not matter whether you run VMRCplus on a physical machine or a Virtual Machine.

Just for the fun of it I started my Virtual Server super laptop to test both the Windows XP SP3 and Windows 7 SP1 clients. I call it my Virtual Server super laptop as it runs 30 Virtual Machines with Windows Server 2003 SP2 with a total of 4 GB of host memory. All on a laptop with a single hard disk and everything is still snappy.

Anyway, I went through all the steps to get VMRCplus working and below are the steps I had to take.

Windows XP with Service Pack 3

This OS was running on my x64 Windows 7 SP1 machine in Windows XP Mode. I joined the guest OS to the Virtual Server domain and I logged on as a domain administrator on the client. The Guest OS was otherwise default so it had the Windows Firewall turned on.

1. I installed VMRCplus 1.8.0.

During setup I chose to install the VSCOMAPI since this is a client and VMRCplus needs the COM API of Virtual Server to communicate with the remote host. See the picture below.

image

2. I started VMRCplus.

It gave me an application error with code 0x00000135. This is caused by the fact that the .Net Framework is not installed. VMRCplus needs the .Net Framework so this is basically an operating system error (it is a LoadLibrary error since the OS cannot find the necessary .Net library files).

image

3. I installed the .Net Framework 3.0 SP1

I used the file dotnetfx30SP1setup.exe which is basically a dynamic setup using the Internet to download all necessary files.

4. I started VMRCplus.

It started up just fine so the .Net Framework setup was OK. I then entered the IP address of the remote Virtual Server host and clicked ‘Connect’. This resulted in the RPC Server Unavailable error.

image

VMRCplus uses the COM object which uses DCOM in the remote scenario. DCOM involves callbacks from the remote Virtual Server host to the client and Windows Firewall was simply blocking them.

5. I closed VMRCplus and opened Windows Firewall. I added an exception for VMRCplus. Then I added another for RPC by adding a port exception for TCP on port 135. I also changed the scope to limit RPC allowed traffic to the remote Virtual Server host.

6. I started VMRCplus and tried to connect to the remote Virtual Server host.

This now succeeded and it was clear I had done everything I needed to do to get VMRCplus connecting to the host.

image

As you can see from the picture, I had 30 Virtual Machines running on this host with only 4 GB of memory. I could even start a couple more but did not want to stress the host for this test.

 

To summarize the installation on Windows XP SP3. It basically took installing the .Net Framework 3.0SP1, adding Windows Firewall exceptions for VMRCplus and DCOM (RPC) and that was it. The Windows Firewall is still fully enabled.

 

Windows 7 with Service Pack 1

With Windows 7 SP1, things turned out to be even easier or less work. Windows 7 has the .Net Framework already built-in so I did not need to install that.

So here are the steps:

1. Install VMRCplus exactly as above for Windows XP.

2. Start Windows Firewall and go to Advanced. Go to Inbound Rules and add VMRCplus.

image

I used the principle of ‘least privilege’ here as well. So I configured a rule for TCP only (the wizard would have created one for TCP and one for UDP). I selected the Domain Profile and limited the scope to only allow traffic from the remote Virtual Server host.

I enabled the ‘Windows Management Instrumentation (DCOM-In)’ rule which is basically a RPC rule. But I also limited that the same way.

-------------------

That was it for Windows 7. I could connect to the remote host without any issues.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    May 20, 2011
    Thanks for figuring out the windows firewall with advanced security exceptions needed for VMRCplus on windows 7. It finally works again after about a month and a half. It's also good to hear that it wasn't just me who was bugging you to find a fix. But this still doesn't explain why VMRCplus was working on my computer without the exceptions, but suddenly stopped working one day. Why would it suddenly need the exceptions if it was working before? That is the question.

  • Anonymous
    September 07, 2011
    I have Hyper V and I created multiple Virtual Machines (Window 7 and Windows XP)  The question is, how do I access them from another desktop without having to go to Hyper V.  I don't know if this make sense at all. The only way I know is to RDP to the actual server and connect to it via Hyper V.  Is there a way for me to distribute access so an end user running XP can connect to this virtual machine running Windows 7 and do some testing? Sorry for this confusing question.  

  • Anonymous
    June 28, 2012
    You seem surprised that people don't update to Hyper-V as soon as maybe! We have an old server hosting VMRC+. We have others with Hyper-V. Yet more are VMWare. Being a normal company we rely on software continuing to work for years. When it stops working we look at the support contracts.