We recently faced a problem whereby a customer’s database server stopped working due to a hardware failure. The server was running on a physical box, and XP and Windows 7 users had a mapped drive which pointed to a share on the database server in order to run the application from their PCs.
The solution was to build a new server, restore the database and connect users to the new server. However, this would have had a major impact on the business due to the fact that a new server would need to be purchased and delivered to site and then rebuilt. This process would have taken at least 2-3 days, meaning serious downtime before users could work on the system again.
axon IT had implemented a Hyper-V solution for the customer a few months previously, so we were in fact able to rebuild a new virtual server (Windows 2008 Standard) to host the database server straight away. The process of having a server ready in the production environment took less than an hour, which then allowed the administrator to restore the database on the virtual the server by around lunch time the same day, saving valuable days of downtime.
We then had to use the DNS entry (CNAME) to point the old server name to the new virtual server. This worked fine for Windows 7 users who were able to connect to the new share on the virtual server and then launch the business application. XP users on the other hand, could not connect.
We carried out some diagnostics on the XP clients and found that we could successfully ping the DNS record, but when trying to access the share on the new server, it failed.
I did some research online and found that this is a known issue with SMB share via CNAME alias. Windows 2008 and Windows 7 will work fine, Windows XP will have issues.
This fix for this problem comes in two stages;
1.Add a registry key “DisableStrictNameChecking” as explained on Microsoft KB 281308, (Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name):
http://support.microsoft.com/kb/281308/en-us;
2. Run the following set on the domain controller:
SetSpn -A HOST/<ALIAS> <Hostname>
SetSpn -A HOST/<ALIAS>.<Domain>.<ext> <Hostname>
This should effectively resolve this problem.