Sometimes I just need to jot myself some notes so I don't forget them.  In this case, this page on MacWindows.com has helped me greatly in the past (and will again in the very near future), and it may help others who find odd SMB access errors, slowness, or other problems (especially on older Mac OSs).

In this newer case, I think the problem is crappy firmware for the  WD Sharespace...  Need to convince the owner that a Synology or QNap or Drobo would be a far better thing to trust their business data to.  At least they have backups...

I recently came across a few issues configuring Network Load Balancing (NLB) on two Windows 2008 R2 Hyper-V VMs running IIS and MySql as a hosting solution for 100+ medium traffic WordPress sites to be migrated over after testing.

Installation and configuration of NLB went fine, and the cluster was initially configured as multicast.  This worked fine, until I went to go test connectivity from the outside world - no respone.  Turns out, the gateway on this network was (correctly) set to not relay multicast packets.  Unfortunately, creating static routes on this gateway was not an option, so it was going to have to be unicast.  Not a problem - I shut the machines down, added another virtual ethernet adapter, and reconfigured NLB to use the dedicated second adapter.  Windows 2008 R2 and 2012 Hyper-V hosts are now set to block VM MAC address spoofing by default, so that needed to be enabled for that second adapter.

All's well and good - WordPress sets up, everything works... until I log into WordPress and find that it can't retrieve any external info (themes, plugins, WordPress news, etc.)  Because of the way NLB works in unicast mode, each site was trying to use the adapter it was bound to (the dedicated NLB adapter), which because of the spoofed identical MAC addresses, couldn't guarantee that the response would come back to the machine that generated it.

The following commands, courtsey of The Cable Guy, cleared this issue up:

netsh interface ipv4 set interface {NLB adapter} weakhostsend=enabled
netsh interface ipv4 set interface {NLB adapter} weakhostreceive=enabled
netsh interface ipv4 set interface {NLB adapter}ignoredefaultroutes=enabled

...in addition to going into Advanced Settings from the Network Connections list and setting the Management adapter as a higher priority than the NLB adapter.

The first two commands reenable weak binding, while the third command allows outgoing traffic to go out over the non-load balanced adapter, based upon the order of the connections (and guaranteeing it would come back to that specific machine).

Upon further testing, this solution did not work for the given scenario.   NLB is an outdated solution with flaws, but for a while it was the only game in town (on the cheap end).  As stated in the setup docs, NLB creates a massive amount of multicast data in this mode.  The network configuration is unfortunately large and flat, and this configuration generated multicast storms of each and every request.  On an isolated VLAN, this could work, but at that point, you might as well have gone in another direction.  Also, upload speeds are hobbled because of how much traffic is created with incoming packets.

Dedicated load balancers and proxy servers are much better for keeping large amounts of web data highly available.   Physical devices are expensive but well-designed.  Even a lightweight software solution like Squid on quality hardware would fit the bill, plus you get the added benefit of offloading caching and compression to the proxy server, but you lose the ease of a single-point SSL configuration that the better featured physical devices include and instead have to pass encrypted traffic straight-through.  Luckily, IIS >= 8 has that covered.

I have the privilege of assisting a client in migrating from a long-running installation of Windows Small Business Server 2003 running the usual slew of SBS services & a couple of LOB apps, all on out-of-warranty hardware that's started to show the signs of old age.

Microsoft has an incredibly detailed guide covering best practices and needed steps to get the migration going. After configuring the newly purchased Dell T6600 (very few local non-profits that I've dealt with have actual hardware racks) as a Hyper-V host, I installed SBS 2011 using the answer file created on the old server. Instead of swapping disks, I just added a second optical drives to the VM, using the second one to mount an ISO of the answer file created using ImgBurn.

I was wondering why the installation was taking so long without the progress bar budging, so I opened the command prompt (using shift+F10) and ran netstat -a to see if the server was connecting to anything, which showed connections to Microsoft's update servers. After reading this post about updates failing, I figured I'd give it another 30 minutes before rudely interrupting, but by then it had finished the updates.

Next up: migrating Exchange…

One of my clients was experiencing some odd wireless dropouts on the computer set up the farthest from the router.  They mentioned that it started around when they gave their wireless key to a neighbor so he could get online.  It seems like a neighborly thing to do, until you consider that this new computer that they have no control over is on the same network as all of their machines, as well as their file server.  I told them I was uncomfortable with that setup, but if they wanted to share their access, I would find a way to make it work.

They have a WRT54G v8 that I had them purchase from NewEgg, on which I decided to swap out the stock firmware with the open-source DD-WRT firmware.  There's a great walk-through on SimpleHelp.net that covers the additional VxWorks Killer step necessary for the v7 & 8 models.  The DD-WRT firmware gives you near-complete control, especially over things like wireless transmit power (the stock setting is between 20-40mw) which I leave set to DD-WRT's default setting of 70mw.  After setting up the wireless network and the security, I went back downstairs to find that the signal was now solidly stable.

But what about their neighbors' access?  Using the extremely well-written guide available from Pennock's World about setting up multiple BSSIDs using DD-WRT, I was able to get multiple wireless networks running off of one router.  The rules in the firewall section stop any traffic going between the two networks, while still allowing the second network access to the internet.  They can even be set with their own security schemes, so the neighbors can use any old WEP-enabled device while all of the important computers connect via WPA2.

Netsh  is a valuable command-line tool available from Windows 2000 onwards.  I recently had a client who was unable to get his wireless adapter to repair, no matter how many times he rebooted, repaired, disabled, etc.  It would associate with the access point but never pull a correct IP.  Instead, it kept going to some non-self assigned IP (202.61.xx.xx)  All it took were the following commands (he didn't have any special settings, so when in doubt, reset everything you can!)

netsh interface reset all
netsh winsock reset

A quick reboot later, and the wireless jumped right on and got a valid IP from the DHCP server.

Additional Netsh Resources

• Microsoft's KB article - basic usage and description of the various contexts
• Petri has more advanced uses for the tool.
• Microsoft Technet Command Line Reference - Using Netsh