Recently I setup a Hyper-V Server and ran into a few issues around networking and setting up a virtual firewall with ISA 2006. It turns out that Hyper-V creates a virtual network adapter for the physical computer and plugs it into the physical adapter which is turned into a de facto network switch. So, if you’re going to use a router or firewall inside a virtual machine you will end up with two network adapters plugged into the “switch” on the external side of your firewall. That might be fine, but it poses a small problem when used in conjunction with Comcast because they see it as two computers and the physical computer may win out and get the external IP while Comcast ignores the other network adapter.
The solution is to disable the virtual adapter that was auto-created for the physical host on your external physical adapter “switch”. Thus Comcast will only see one computer and all will be happy. Searching around for the commands to do this in a Core/Hyper-V console only install of server 2008 proved to be a bit of a trek. After a few days and a few Google searches later I found the answer. Here it is…
Rename a network connection:
netsh interface set interface name=”Local Area Connection 3” newname=”Internet Connection”
Disable a network connection:
netsh interface set interface name=”Internet Connection” disabled
Pretty simple, but my install of Hyper-V Server also suffered from a bug that luckily has a hot fix. It was showing no interfaces when I ran this:
netsh interface show interface
…which is a bug. After I found the patch for that though the rest was done in no time.
I’ve been playing with a REST WCF service for a bit and noticed when I attempted to add it to Azure’s service bus that it blew up on me. It even goes so far as to kill the development web server in VS2008.
After a little debugging I traced it back to a small bug in the Microsoft.ServiceModel.Web code from the starter kit. Turns out the code relies on the OperationContext.Current which is null unless AspNetCompatibility mode is Allowed or Required, which doesn’t work on Azure (at least not that I could see). So… I fixed that bug and all was well, sort of…
You see, it seems that now I have an endpoint disagreement somewhere because I’m getting this now:
a:DestinationUnreachableThe message with To 'http://servicebus.windows.net/services/improvGroup/Manager/Contacts/help?apikey=bigGuidHereSnipped' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree.
I guess I’ll poke around with it later when I have a few hours. Any suggestions?
Technorati Tags:
REST,
WCF,
Azure,
Message,
Bus,
DestinationUnreachable,
AddressFilter,
EndpointAddress,
EndpointDispatcher,
OperationContext.Current,
AspNetCompatibility
This is pretty obscure… EBS goes through its setup perfectly until it tries to install System Center Essentials, which we all know was invented by Satan himself because it never freakin’ installs correctly even by itself. So, if anybody reading this has any ideas about how to get around this issue, let me know… And no, installing VMware is NOT a solution, even if that might work.
