Thursday, February 28, 2008

Fun with changing the IP address of ESX Server 3.5

We (our IT manager and myself) have been having some fun with out shiny new VMWare ESX 3.5 server.  We have had it running for about two weeks now and we decided to change it's IP address.  The ESX server was on the same subnet as our LAN.  This meant that it the virtual machines were taking IP addresses out of a pool that was needed for our physical computers.  There were some other security issues, so we decided to put it on it's own subnet.

It was fairly easy to change the IP address address via the command line (this site helped a lot), the fun started with the NFS connection.  We are using NFS to mount a folder located on a Windows file server to add some offline storage for the ESX box.  To mount with NFS, you have to create a VMKernel in the ESX networking and the VMKernel gets it's own IP address.  That IP address must be on the same subnet as the NFS server.

When we moved the ESX to it's own subnet, we put it on it's own physical network and that broke the NFS connection.  We tried a few things and then we checked the Windows box that was running the NFS server.  It had two network cards.  The second one was not enabled, but fully functional.  We enabled it and set it's IP address to the subnet of the ESX box.  I had to drop and recreate the NFS mount, but it all worked.

While testing the networking, the IT manager was running one of the virtual machines (XP 64-bit) and set the network adapter in the VM to a static IP address.   It turned out he set it to the IP address of the ESX server.  That's when the fun started.  When you connected to the VM, ESX would lose it's connection and you lost control over ESX and the VM.  After a minute or two, you could access ESX through the VMWare Infrastructure Client, but you couldn't access the VM to change it's IP address.

We racked our brains trying to figure out how to get control of the VM to reset it's IP address.  The fix turned out to be really simple.  I powered down the VM from VIC and edited it's hardware settings.  I added a second network adapter (it's all virtual) and set the first one to be disconnected.  I powered the VM back up and the new adapter had a safe IP address.  I connected to the VM's console and opened up "Network Connections" in Windows.  The first adapter was enabled, but not connected.  I opened up it's properties and set it to grab an IP through DHCP.

I powered down the VM, removed the second adapter, and reconnected the first one.  I rebooted the VM and it had a new IP address.  Peace and harmony reigned through my virtual kingdom.

Tuesday, February 26, 2008

Just when I thought my SmugMug plugin was finished...

After tackling the Wix learning curve, I have an installer for my SmugMug plugin does usual things: check for .NET 2.0, install the files, add the registry key to register the plugin, and support upgrading in place.  One step closer to releasing this plugin for Windows Live Writer.

Meanwhile, over at SmugMug, a security issue of sorts popped up.  Don MacAskill, the CEO of SmugMug, blogged about it with great detail and openness and I'm not going into it here.  At any rate, in response to what was perceived to be a security, SmugMug is implementing some changes to their API.  The changes were fairly trivial to implement so it made sense to augment my plugin's code to be compliant with the updated API.

With their recent changes, I saw that my plugin was no longer displaying images for one of my test galleries, where it had worked before.  I spent a hour or so trying to track it down in my code, when the clue light finally flickered above my head.  I logged into my SmugMug account and examined the properties of that gallery. 

Sure enough, for that gallery, the "allow external links" option was set to "No".  This meant that even though my plugin would return valid URL's for the images in that gallery, SmugMug would send back a blank page for those URL's.  I augmented my call to get the gallery list to check the properties for each gallery and filter out the ones that did not allow external linking.

I thought that there would be performance hit for making a web service call for each gallery.  It wasn't really noticeable at all.  That's what I love about SmugMug, their API performance is damn fast.

At any rate, I was hoping to finally push this plugin out the door by now, but I'm going to take a few more days and beat on the code.

Thursday, February 21, 2008

I hate spam that comes in under my own name

For the last few weeks, I've been getting spam email addressed to my work account with the "from:" field set to my work address.  That allows it past our companies spam filters.  The subject line is usually something liken "January 79% OFF" and the message body contains a few images, some oddly worded links, and some boiler plate text about receiving this mailing because I am "subscribed to MSN Featured Offers".

The images are blocked by our central spam filter, which means they are being hosted on a known site for spamming.  I haven't verified that with our IT manager, but it's a safe assumption. 

I'm going to block this message at my email client (Outlook 2007), but first I'm going to send a message to the ISP that is hosting the machine that sent the email.  The first thing to do is to see where the images and links are pointing to.  With Outlook, if you right click in the body of the message and select "View Source", Outlook will create a file named email.txt and launches it with the app registered to handle text files.  That's usually notepad, but YMMV.

For this message, I saw something that looked very much like the spam that was reported to the newsgroup in this post.

Most of the links were junk, but there was a link to "s y l l a b l e h e a v y . c o m" (I added spaces to prevent it from being a live link and inflating it's Google ranking).

A quick search in the Internic registry brings up the following results:

Whois Server:
Referral URL:
Name Server: NS.XINNET.CN
Name Server: NS2.XINNET.CN
Status: ok
Updated Date: 19-feb-2008
Creation Date: 16-jan-2008
Expiration Date: 16-jan-2009

That tells us a couple of things.  One, the website is registered by a Chinese registrar.  Two, it was created about a month ago.  The next step is to track down the Registrar, Xin Net.  A quick search on Xin Net, gives us some more information:

   Address: 1st Floor,2nd Building Section A,BDA BeiGongD, Beijing, China 100176, CN
   Phone Number: 86.1058022118
   Whois Server:
   Referral URL:
   Admin Contact: cody zhou
   Phone Number: +
   Admin Contact: xiaorui wang
   Phone Number: +86.1058022118-205
   Admin Contact: Baosheng Jiang
   Phone Number: +86.1058022118-623


This gives a whole bunch of email addresses to complain to.  What I did was to send a polite message to all of the addresses listed above.  I sent the following:


Please excuse this unsolicited message, but I have been receiving numerous spam emails and they link to a site,, that you are listed as the registrar of.   This site probably violates your terms of service and I am sure that you do not want to be associated with it.    The message did not originate from that site, but it is using that site.

I then included the message header and the message source.  I doubt that they will do anything, but if they do take action, it takes a spam site offline.

The next thing to do is block additional messages like that. 

  • From the Outlook menu, I selected "Tools->Rules and Alerts" to create a new junk mail filter. 

  • In the "Rules and Alerts" dialog, I clicked "New Rule...". 

  • Under "Start from a blank rule", I selected "Check messages when they arrive", and then clicked the "Next" button.

  • Under "Which condition(s) do you want to check?", I selected "with specific words in the sender's address"

  • For the "with specific words in the sender's address", I entered my address.  I rarely send myself email from my work account.  When I do, Exchange just uses my first and last name, not the SMTP address.  Then I clicked "Next"

  • Under "What do you want to do with this message", I selected "move it to the specified folder" and "mark it as read".  I selected "Junk E-mail" as the selected folder.  I then clicked the "Next" button.

  • I clicked the "Next" again to skip over the exceptions to this rule.

  • I gave it a name and set the checkboxes to run it on messages already in the inbox and to enable the rule and clicked finish.

  • Clicked "Apply" and then"OK" and we are done.

That will permanently take that style of junk mail out of my in box.  I didn't permanently delete the message.  About once a week, I take a quick peek in the junk e-mail folder just in case a false positive hit grabs a legitimate email.

Saturday, February 09, 2008

Nvidia nForce network driver problem under Vista

On my home machine, I rarely reboot it. If a software update requires a reboot, then I do it. otherwise it stays running for weeks at a time. Vista (32-bit) has been stable enough for me, where I don't have to start the system or suffer system crashes.

But when I reboot, about 10% of the time (just a wildly inaccurate guess), the machine comes up without any network connectivity. In the past, I have associated it with Windows Update installing a wonky driver for the network card and I System Restore the machine back to normal. It happened today and the list of the usual suspects did not include any hardware updates. Time to dig deeper.

This machine has a NVidia nForce motherboard (Asus M2N-SLI Deluxe) and it has built-in dual Gigabit LAN controllers. I had an Ethernet cable hooked up to the first port and had disabled the 2nd one through Vista's "Network Connections" utility. My dead Windows Home Server box was next to my PC, so I unplugged it's Ethernet cable and plugged it into the second port on my machine. I enabled the network adapter and after a few seconds, it was live and had grabbed a IP address from router.

That was interesting. Since the working adapter used the same driver as the non-working one, that pretty much ruled out Windows Update nuking one of the drivers. I peeked at the driver settings for both adapter, they were both set to the defaults. I also checked the device status of the adapter, Windows reported that "This device is working properly." That was a pretty good indicator that the problem was not a fried controller on the motherboard.

The next thing to check was the ethernet cable. I swapped cables and there was no change. I decided to do the Nintendo fix. That's when you pull out the cartridge, blow on the connectors and ram it back in again. In this case, I disabled the adapter, waited 30 seconds, and re-enabled it. As Emeril says, Bam! The adapter started working. Time to start googleing and see if anyone else is having this problem.

And the number one hit for "nforce network adapter fails" in Google was a long thread in the Nvidia message forums. A sizeable number of people were having the same problem and they were all running Vista. It may be a timing issue during boot-up. Two workarounds were suggested. One was to change the duplex setting from "Full Autonegotiation" to "100 Mbps Full Duplex". The other was to change the priority order of the network adapter priority. I didn't want to mess with the driver settings, so I opted for changing the priority order. I'm not confident that it will fix the issue, but it wont hurt anything. Right now this is more of an annoyance than anything else, but I would like to resolve it permanently.

Sunday, February 03, 2008

Using Wix for my Live Writer Plug-in

I finally have version 1 of my Smugmug gallery plug-in completed. The next step is to do the installer. To get a plug-in up on the Windows Live Gallery, it must have an installer that meets the requirements on the Gallery Developer Center page. A content plug-in has to meet these requirements:

  1. Content Plugins must be built using either the .NET 1.1 or .NET 2.0 frameworks.
  2. Content Plugins must be packaged and submitted as a Microsoft Installer (*.msi).
  3. If you use the .NET 2.0 framework, the installer must link to the .NET 2.0 download site or use the Visual Studio 2005 Bootstrapper. The Bootstrapper detects and downloads the correct .NET 2.0 framework.
  4. Your installer must copy the assembly to the "Plug -ins" sub-directory of the Windows Live Writer installation directory.

I have #1, my plug-in uses the .NET 2.0 framework. Number 2 is that it must be packaged using a Windows Installer .msi setup. I'm still figuring out the best way how to implement #3, but I'm not sweating it. With #4, I'm not doing it that way. The alternative method is to install the plug-in in your own folder and write a registry key to Software\Windows Live Writer\PluginAssemblies (HKLM or HKCU) with the name of your plugin and the path to it. That way you don't have to worry about where Live Writer was installed to. In fact that page is probably obsolete, there is an MSDN article that covers the registry method.

Let's start with the .msi requirement.

I looked that the "Setup Project" template in VS 2008. Um, no thanks. After 30 minutes of playing with it, I started getting annoyed. It felt awkward and non-intuitive. Granted, most things with Windows Installer are awkward and non-intuitive, but I couldn't get fast handle on "Setup Project" template. It was easy enough to get the files installed, but getting the registry written correctly was a task I just couldn't figure out. After two years of doing .msi with Wise For Windows and now InstallAware, I have a pretty good idea of an .msi is supposed to work.

I decided to knock out an setup with InstallAware. It took about 5 minutes and worked perfectly. But it was 1.2 MB in size. That seemed excessive to deploy 45K for two assemblies. Frankly any installer will be excessive, but I have to follow requirement #2. I have lots of love for InstallAware and it's my tool of choice for application installs, but it still bothers me to have a setup that 26 times larger than the files being deployed.

With VS's "Setup Project" and InstallAware out of the picture, I decided to check out WiX. WiX stands for WIndows Installer XML and is an open source toolkit for building .msi setups from an XML source file. The current version, 3, installs nicely into VS 2008. It installed so nicely, I didn't need to be concerned with how to run the Candle (the WiX compiler) or Light (the WiX linker). There is also a .msi decompiler, named Dark. It will emit Wix source code from a .MSI or .MSM file.

WiX source code is pretty intimidating when you first look at it. if you have no experience with authoring Windows Installer, it will be hard to grasp at first. The WiX site has a nice tutorial, but it's for version 2 and uses syntax that's deprecated in version 3. Fortunately, I was able to google the differences and I was able to get a working installer in about an hour. It's not handling step 3 completely, but it is terminating the install if .NET 2.0 is not available.

The size of the .msi is much smaller, about 220k. Still way too large, but it's as about as small as I'm going to get for a .msi file. So far, I'm very impressed with WiX. Once you start getting the hang of the syntax, it's very clear on how to setup a proper .msi file. There's even a open source editor called WixEdit. I didn't need it for this task, but I think I make take at peek at it at another timer.

Enough people are using it so that I was able to google for the bits I needed. Morten Lyhr had a great post on how to detect the .NET Framework. I figured out how to write the registry key from a post by Chris Jackson. Bonnie (one of the Live Writer developers) had a good sample WiX file for installing a plug-in. While I didn't follow her pattern, it did give me a tour of the neighborhood. Mike Stall has a good post that covers the basics. I think I need to spend some time reading the blogs of the WiX developers, they have a build a really cool tool.