Configuring SharePoint Virtual Machine LAN Connections
 
Published: 21 Apr 2008
Abstract
Insufficient VM LAN connectivity in the development of SharePoint solutions may cause developers to lose valuable time and peak development capabilities. This article provides reasons and steps to configure the most valuable VM LAN connectivity practices with the help of relevant steps and screen shots.
by Steven Barden
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 30364/ 64

Introduction

It is not uncommon for developers new to using Virtual Machines to use Microsoft Virtual PC LAN connectivity in a manner that inhibits their development goals. This practice can not only lead to personal frustration by forcing the developer to take more complicated steps than is necessary to accomplish common goals, but it may even cause the developer to lose valuable time and peak development capabilities, resulting in slowed productivity, reduced 'eureka' moments and even one's job in extreme cases. This article pursues positive solutions to the problems posed by bad LAN connectivity practices in multiple examples.

What is this about?

As you are aware, in the development of SharePoint solutions you can of course use the main OS to install your products, development tools, etc., or you can use a Virtual Machine. Whenever possible I choose to use a Virtual OS for many reasons. Along with that decision I tend to use Microsoft Virtual PC due to its fabulous price. That said, this article is not a suggestion of how to tune your Virtual OSs. Take a look around the internet and you will find a significant amount of web articles devoted to that topic. This article focuses specifically on issues of connectivity. I choose this sliver of a topic because of the immense impact it can have on your development speed.

Which Virtual PC software choice

I am going to take a detour for a minute and touch on the holy war that is Microsoft versus VMware. I tend to use Microsoft Virtual PC on the desktop simply for the reason that it’s free and that is usually what I am allowed during contract employment. I don’t think it’s really fair to compare Microsoft Virtual PC and VMware Workstation for the fact that VMware Workstation is so much more advanced than Microsoft Virtual PC due to its intended scope and features. VMware's team system, cloning capabilities and so on put it far ahead of Microsoft Virtual PC simply because Microsoft does not address those considerations. Yet, in its base requirements and functionality it gets the job done. The server environment is a different situation, to me, and far outside the scope of this article. If you are going to seriously run in the Virtual OS space it’s worth your time to find the product that works for you. And to be fair I have not even touched on the fact that there are many more answers than just MS and VMware. I will simply wrap up by saying that if, like me, you tend to use Microsoft Virtual PC on the desktop, and VMware Virtual Server on the server side (again free), you may be happy to learn that VMware Server will open and run Microsoft Virtual PC images. Many times I have had to use Microsoft Virtual PC to start an image, just to find out that the image is worth running long term. As such you can copy it to your VMware Server environment with minimal changes and keep running the same image through server reboots under VMware Server.

How to view and work with an image

You can of course choose to start your Virtual OS and press Alt+Enter to cause the image to take up the whole screen. One problem with this method is that people have been known to become unsatisfied with the visual performance of the Microsoft Virtual PC product. It just has problems. You do have the option to drag and drop a file into the Virtual PC window as well as setup a Virtual PC to share folders, I personally have had several issues with both of these pieces of functionality, and I'll take a good old LAN configuration every time. As such I have always opted to configure Virtual PC to share network cards with the base OS. Virtual PC does this by adding an IP address to the base OS adapter and assigning it to the Virtual OS, just like adding multiple IP addresses to any Windows LAN adapter. By doing this you get all of the advantages of any other LAN connected PC. I feel that the best advantage is the fact that you can then Remote Desktop into the Virtual OS. Your experiences may vary but I have never had the use of a desktop expanded Virtual PC image react as well as using RDP.

Connecting to the image via mstsc

MSTSC stands for Microsoft Terminal Server Client, which uses the RDP, Remote Desktop Protocol. There are a few ways that you can connect to an OS via RDP, for example:

mstsc /v:<server>:<port> /console /full /span

This command can be run from the Start | Run line and where Windows will cache it for future use by default. Or you can put it in a command file (say connectServer.cmd). If you have not loaded the latest version of the RDP client I highly suggest you do so. One advantage is that it will allow you to cause your security administrator a nightmare by caching your credentials, thus not having to provide the login and password each time. But it has other features as well. For example:

mstsc is of course the command line to execute, Microsoft Terminal Server Client

/v: is the switch that tells the command what OS to connect to, by IP, NetBIOS name or host name

:<port> is a feature I use a lot. You can change the port that an OS listens on, although I don‘t suggest it. But if you have a single IP on your firewall that you want to stack exposed ports (for example having the external NIC port 44444 point to server1 port 3389, or port 44445 on the outside point to server2 port 3389 and so on), this feature can be very useful, or even required in some circumstances

/console is not required but is very helpful. When you connect to a server generally you’ll get one of the two admin consoles. With this switch you can get the main desktop, just like windows XP, which only allows one inbound RDP connection to the console session. This is a great trick to get a “third” console when the others are taken up. It is unlikely that a human will be logged into the physical desktop of a server at all times. As a side note I just read that Microsoft changed the /console switch to /admin on Vista and Windows Server 2008

/full is a switch that tells your client to take up the full screen as seen by one video card or panel on the initiating side

/span while not required it is a good way to cover multiple panels on your client pc. I used to use the /h:<height-in-pixels> /w:<two-panels-width-in-pixels>, and still do in some cases, until this trick came out

And of course before you connect to the server via mstsc you can set all of the available options and save. When you adjust and save, it will adjust the default settings, and then the command options seen above over-ride them. You will also find that if you want to connect to your image remotely while it’s running under Microsoft Virtual PC on a desktop you have to do it this way, since Virtual PC as a program does not you to remotely connect to another running instance of Virtual PC.

Setting your adapters: reasons and some suggestions

As you know, you can configure a Virtual OS adapter to bind to a Host OS adapter. Yet I have been in places where I was surprised to find that an admin had loaded XP, Virtual PC, and an imaged OS, just to assume the users will be happy to use Virtual PC expanded mode. Not only is Virtual PC quirky in its video presentation, but at this point the Virtual OS cannot get to the internet, much less other LAN resources. The answer from some people seems to be that configuring one or more NICs is troublesome, or at least for the short term. Personally, no matter the time length, I cannot stand to work on an imaged PC that cannot get to the outside world. Having to drop all resources in to a Virtual OS window, much less copy and paste internet web page text or any remote files is also a bother.

Connection number one… NAT

In later steps I will show you how to connect your Virtual OS to the LAN like any other device. But for this instance let's assume that you don't want to go through the steps, or, quite likely, your Virtual OS is an image that is used in more than one place. This second issue would cause multiple copies of Windows with the same name to shut its adapter connection down so it will not cause conflicts. But by using NAT, and hiding your Virtual OS from the LAN, just like your router hides your LAN from the internet, you can get around this problem. Virtual PC allows the use of Network Address Translation, NAT, just like a home Linksys router. I have found that there are times I am likely to use Virtual PC hosted NAT and other times I may not need it. But because Microsoft allows NAT to be used on only one adapter, Virtual PC adapter slot #1, I set it that way.

As you step through the other configurations you will find that there is almost always a Virtual OS adapter bound to a Host adapter by way of the Virtual PC settings. This is one of the exceptions. When you use NAT you will find that the Virtual OS needs to bind an adapter, but the Host OS does not. At least that is the way it appears in the Virtual PC settings. In reality Virtual PC is binding the first Virtual OS adapter to the primary Host OS adapter, as well as providing DHCP services. The IP address most often given to the Virtual OS adapter is 192.168.131.65. Then, as the Virtual OS pings out to the LAN from behind NAT, returning packets come back to the Host OS primary adapter. It is important to note that the primary adapter is defined as the main adapter used by the Host as NAT was engaged. If you move your laptop from a wired to a wireless connection while the Virtual OS is running, and all adapters are loaded, it's likely that Virtual PC will not keep up, and your Virtual OS will lose connectivity. You should then disable and re-enable the adapters in question. In any event, once this configuration is running as expected, the Virtual OS can get out, but no one can get in, including RDP to control the Virtual OS.

Loopback and main connections

Probably the first thing many people will do is setup a basic connection but I submit the consideration of using a loopback adapter on adapter slot two. Due to the Microsoft media sensing feature an adapter will generally drop its address once the media is not longer sensed. I’ve had this happen when a switch goes down, even though the NIC is still connected via a CAT5 cable. Or you are using a wireless connection, your laptop for example, and you need to hibernate and go home… same result. This has the nasty side effect of dropping your RDP connection to the imaged OS. You can of course open the Virtual PC console, but there is a better way.

Disabling media sensing

Before I continue, there is a way to disable media sensing in the networking configuration. Media sensing is the act of Windows turning on or off an adapter based on whether it can sense a physical connection. Sometimes I would prefer that a connection stay live even if I remove the CAT5 cable. Thus (one example) I can still ping from a Virtual OS adapter, through a binding like NAT, to another laptop adapter, even when it’s not connected to a media. I will warn you ahead of time thought that you may get "hardware error" messages at times, so it's not perfect. To do this, follow the instructions at http://support.microsoft.com/kb/239924

Set up a loopback adapter

Using the second adapter in the Virtual OS and a loop back adapter on the host OS, we can configure an unbreakable connection between your host and virtual OSs. That way when your LAN connection breaks, your RDP session does not.

1.    In the control panel of your base OS open the Add Hardware applet.

2.    Tell your PC you have already added the new device.

3.    Scroll to the bottom and click next.

4.    Choose advanced, next.

5.    Click N to help you find "Network adapters".

6.    Select Microsoft and Loopback Adapter.

7.    The following addresses are suggested settings but you can adapt as needed.

8.    Go to the Network Panel and select the new loopback adapter.

9.    Press F2 and rename it loopback(10.0.0.10).

10. Add the same address to the NIC via it's settings, skipping DNS and gateway.

11. Go into the Virtual PC settings for the intended OS and adjust for three adapters.

12. Bind the first adapter to the Microsoft Loopback Adapter.

13. Start your Virtual OS and change the settings to 10.0.0.20 for one of the adapters.

14. Now from both sides ping around until they can see each other. You should now have an unbreakable connection between your Oss by way of the loopback adapter on the Host connecting to the second adapter on the Virtual OS.

The following screen shots may assist.

Figure 1: Scenario 1 - This view shows the NAT adapter (and loopback adapter for RDP on the Virtual OS) enabled on the Virtual OS. Notice the adapter numbers correlate with the adapter slots in Virtual PC

Figure 2: Scenario 1 - A Virtual PC software binding view showing NAT and loopback bindings. Notice that adapter #1 is bound to NAT

 

Figure 3: Scenario 1 - A view of the Host OS configuration

 

If you find that you cannot ping out from the Virtual OS, start by disabling all adapters on the Host and Virtual OS, as well as the bindings in Virtual PC. Then, in this order, enable the Host adapter, the Virtual PC adapter bindings, and lastly the Virtual OS adapter, which should then get a DHCP address and the settings of the adapters upstream.

Setup the next adapters: wired and wireless

If on the other hand you do not want or need NAT, you can bind other Virtual OS adapters to Host OS adapters so that the Virtual OS acts like any other OS on the LAN. In this case you have the choice to assign a static or LAN enabled DHCP address to the Virtual OS. It is common for me to assign the Virtual OS adapter #3 to an onboard wireless LAN adapter via Virtual PC's binding settings, and setting the last one to a wired adapter. As I move from place to place I use CAT5 when I can, otherwise the wireless picks up.

Wrapping up and other points to consider

At this point you will find there are many different experimental paths you can take that are not shown here. For example when using NAT, although you can bridge files from the Virtual OS to the host pc that can be picked up by LAN connected devices, how can you access Virtual OS hosted files or services, such as sharepoint? Luckily the base OS has this ability, so you could browse Virtual OS port 80 from host hosted 10.0.0.10 for example. Or if you wanted to get trickier you could use various port-forwarding capabilities on the host to reach Virtual OS services (Cygwin and SSH tunneling?). We have not even considered how Windows ICS can be used, but you may find it useful when using an air card. It's obvious that Virtual PC NAT has some drawbacks even compared to Windows ICS (which does have port forwarding), but at this point you have to ask yourself if it is worth getting much more complicated? If more complexity is required you can do a lot more with VMware or Microsoft Virtual Server, but at this time Virtual PC has addressed most of the simpler needs.

In review, using the above described methods, you can bind to the laptops onboard LAN adapter, the onboard wireless adapter or use NAT, while connected to the Virtual OS via Remote Desktop using a private network (10.0.0.x). And if that were not cool enough, you can do this with multiple running virtual OSs; just configure the correct IP address for each adapter on each Virtual OS.

Some technical considerations

One technical side note… during these experiments I found that when I switched from direct connections to NAT and back, I could not always get out to the internet. This was because the routing table still held all three gateways. The answer to this is to delete and add the gateways as needed, which you can do with batch files.

Figure 4

More than that, the more I switched around in active combinations the more likely it was that something would go wrong and I could no longer ping someone from somewhere. Try not to switch things around too much when you have a good working combination. But if you just can’t get things fixed, my suggestion is to disable EVEYTHING. Then enable all required adapters on the host. For example if you plan to be on the LAN with a wire, enable just those; else the wireless or air card. Then enable the desired combination in the Virtual PC software settings, one of the four adapters as seen in Figure 4. Then finally enable the Virtual OS adapters as needed. This way all of the route table entries are built as they are needed and removed otherwise. The most notable example of this would be when using an air card and Virtual PC NAT.

Conclusion

You have noticed by now that these suggestions are not simply SharePoint related. I configured a lot of this while doing BizTalk development for the same reasons. But in the end it’s a matter of providing yourself maximum connectivity and flexibility to get as much done as you can.



User Comments

Title: guest   
Name: Andrei
Date: 2010-05-12 1:51:46 PM
Comment:
Steven, thank you for the great article. I was able to use your steps and configured host and VPC connection back and forth, so the host can access SharePoint VPC thru the browser. But I lost internet connection from VPC then. Could you please give some more details how to fix it. Thanks. Andrei.

Product Spotlight
Product Spotlight 





Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-28 9:00:16 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search