Error connecting to external SQL Server from Virtualbox: "Cannot generate SSPI context."


I have a Windows 7 Ultimate guest running on Virtualbox under an OS X (10.9) host. I use the default NAT networking because it's convenient, especially when I need to connect to our corporate network on the VPN, and want both guest and host to have access. Recently, under NAT mode, I started getting this error when connecting to a remote SQL Server instance:
The target principal name is incorrect. Cannot generate SSPI context.
Apparently this is one of those generic authentication failure errors that can happen for dozens of reasons, so tracking it down was a beast.


Changing the Virtualbox NAT connection to "Use the following DNS server addresses" and specifying the same DNS servers the host was using did the trick.


One of the first things I tried was changing the Virtualbox network mode to "bridged", instead of "NAT". That worked. In fact, when I switched it back to NAT, the Sql Server connection still worked. It wasn't until later that I discovered that a system reboot in that state would cause it to fail again.

I tried disabling Ipv6 for the connection (per this post), checked the server name returned by ping -a ipaddress_of_sql_server, as suggested by the official troubleshooting article, and querying the DNS from the OS X host machine. I strongly suspected a DNS issue.

Finally, I learned about `dig` and began trying it on the host and guest (via cygwin in the `bind-utils` package) to query the DNS servers. The query against the Virtualbox-provided DNS,, had a warning that the host query against my organization's DNS servers did not:
;; Warning: Message parser reports malformed message packet.

I now realize that the root cause was running the following command, after experiencing some internet connection issues while using a new version of the Cisco VPN:
VBoxManage modifyvm "VM name" --natdnshostresolver1 on
(Suggested at https://supportforums.cisco.com/discussion/12085546/anyconnect-3104072-wont-allow-internet-connectivity-virtualbox-vm.)

For whatever I was trying to achieve, it sounds like using `--natdnsproxy1 on` may have been a less-intrusive choice, as the Virtualbox docs say about the hostresolver option:
"Note that this setting is similar to the DNS proxy mode, however whereas the proxy mode just forwards DNS requests to the appropriate servers, the resolver mode will interpret the DNS requests and use the host's DNS API to query the information and return it to the guest." (https://www.virtualbox.org/manual/ch09.html#nat-adv-dns)

Other references

  • https://www.virtualbox.org/ticket/7711
  • http://serverfault.com/a/627670/174855


Recovering from a failed BIOS update on a Dell Latitude E6500

While working on a friend's Dell Latitude E6500 I decided to update the BIOS, just for kicks. After using the Windows executable to kick off the update, it eventually failed. The computer wouldn't boot (not even to the BIOS splash screen). Instead, it would simply emit one beep, then turn off. Usually, it would turn itself back on, spin the CPU fan, then turn off again. Finally, I found some instructions in the DELL forums (http://en.community.dell.com/support-forums/laptop/f/3518/t/19506901) to recover from the failed update. In summary:
  1. Download the BIOS installer from the dell website. For example, http://downloads.dell.com/FOLDER01530518M/1/E6500A29.exe
  2. Drag and drop the file to a CMD window, hit space once, then type /writeromfile
  3. Drag and drop the file to a CMD window again, hit space once, then type /writehdrfile
  4. Rename the .hdr file to include just the machine name, in this case E5600.hdr
  5. Put on a FAT32 formatted USB drive
  6. Remove the battery
  7. Plug in usb to the left side slot (try each other slot if that doesn't work)
  8. Hold end key and power button, then plug in power cord.
The computer then read the file and repaired itself. Presumably, this works by using "Boot Block protection":
Most BIOS manufacturers (Award, Phoenix, AMI and Insyde) now include an option known as Boot Block protection. The Boot Block sector is write protected, thus it can only be damaged if the flash utility is explicitly directed by a command line switch to overwrite this EEPROM memory range.

Another post for a Vostro laptop contains very similar instructions: http://en.community.dell.com/support-forums/laptop/f/3518/p/19593398/20675627#20675627.