Category Archives: Solutions

Various solutions and quickfixes discovered during the course of normal life.

Stories from the test bench: Machine Passwords

Leave a reply

At AIS, we keep several virtual machines images “on ice” to support our test bench validation of the various software packages we develop.  Hyper-V is a perfect tool in the software development tool chest as it allows a development team to quickly spin up the appropriate back office tools (Such as IIS or SQL server) to validate everything plays nicely in the sandbox.

Over the last couple of weeks, we were performing validation against MS Exchange 2007 and SQL Server in support of a Time Matters conversion.  During our testing, the Exchange server began to act very funny.  Issues such as:

  • Unable to connect to the virtual host except as the local administrator
  • Various errors in the error log for failed services
  • E-Mails failing to route correctly

After some research, we realized the Exchange server was no longer validating against the test bench domain controller.  Odd….

It turns out that the machine password was out of date on the exchange server resulting in the test bench domain controller refusing to validate the server on the domain.  Now the pieces were falling into place.  Here is what happened:

  1. We created the exchange virtual machine and created a backup of the VM
  2. During our testing, we would reset the test bench baseline by thawing out the backup VM and restarting the VM.
  3. Every 7 days, the exchange server invalidated and reset its machine password with the Domain Controller. Domain controllers will allow machines to log on with the current or the last use machine password.  By allowing the last password to be valid, MS gets around several domain replication issues.
  4. After 14 days, the machine password in the frozen image was no longer valid resulting in the domain rejecting the machine’s access to the domain.

Fortunately, it is very easy to reset the machine password. 
Take a look at this KB article from Microsoft for details

 

As a parting thought, this will also impact users who backup their VM images as a disaster recovery process.  If you recover a virtual machine image which is more than a couple of weeks old, you will very likely notice odd security and domain level issues with the restored image.  Resetting the machine password should be part of your SOP for recovery operations.

dasBlog “Mail to Weblog” IPV6 setup

One of my clients recently installed dasblog.  While the overall installation was exceptionally painless, the “Mail to Weblog” feature refused to work within the customers environment.  After much hair pulling, we were able to track the issue down to an IPV6 issue within the POP3 handling of the Mail to Weblog feature.

Target Environment
The customer’s environment consisted of an edge server running IIS7 and the exchange POP3 client on a single Hyper-V image.  The Exchange server was a standard install on a Hyper-V image running standalone on bare iron.

The Errors
Whenever dasBlog would activate, the log file would contain an error line of Pop3ServerError: System.Net.Sockets.SocketException: An address incompatible with the requested protocol was used fe80::8d30:bd51:31d9:60ac%15:110.

Root Cause
This particular client is IPV4 centric…which confused us in that the error contained an IPV6 address.  Upon closer examination, all IPV6 protocols were active within exchange and the firewall was open for port 110 on both IPV4 and IPV6 protocols so the IPV6 address should not have been blocked.  This was not making sense.  To confound us even more, we were referencing the actual server by name (In this case edgeserver.clientsdomain.com) which returned an IPV4 address from the DNS.

OK.. so where was the IPV6 address coming from and why was it causing POP3 problems?

After a bit of network sleuthing, it appeared the Hyper-V Virtual Machine bus was translating the IP into a localhost call.  The localhost call within Hyper-V then translated the IP address into an IPV6 address from the lmhosts file.

Solution
We removed the IPV6 address from the server’s hosts file.  To remove the IPV6 localhost IP, perform the following actions:

Locate the hosts file at
C:WindowsSystem32driversetc

Comment out the ::1 IPV6 address.  Your entries should look like this when completed

127.0.0.1       localhost
#::1             localhost

Future Research?
We did not have the time to research why the call to the POP3 service was failing under IPV6.  Our guess is the Lesnikowski routines may not be IPV6 compliant or there maybe an ASP.NET trust issue.  With the Web Mail feature now working under IPV4, we declared victory and headed for coffee!

Full Error Text

code    650    message    <span>Pop3ServerError:<br/>System.Net.Sockets.SocketException: An address incompatible with the requested protocol was used fe80::8d30:bd51:31d9:60ac%15:110
&lt;br&gt;   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
&lt;br&gt;   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
&lt;br&gt;   at Lesnikowski.Pawel.Mail.Pop3.Pop3.Connect()
&lt;br&gt;   at newtelligence.DasBlog.Web.Services.MailToWeblog.Run()<br/> while processing .</span>