If you use virtualization in your company, at some point in time you might be tempted to perform a Physical-To-Virtual conversion, also known as P2V. The ability to create a complete working copy of a physical server as a virtual machine is really useful for migrating to a virtualized datacenter, but it can also wreak havoc in your environment if you use it to generate a copy of a server for testing and the only change you make is the name of the server.
Consider that you have a multi-purpose server running SQL Server, IIS, and an Application, lets call this ServerA. To test a new Service Pack or release of the application you decide to P2V ServerA to VM-ServerA-Test, and you change the FQDN. In the past ServerA was a stand alone solution, so the expectation is usually that VM-ServerA-Test is now its own stand alone solution for testing the upgrade, but its not. The applications on VM-ServerA-Test are configured to use the SQL Server named ServerA, so any changes made on the P2V copy of the server actually happen against the production database.
Beyond the obvious “Don’t Do that”, there are a couple of solutions that can be done to prevent this from actually being a problem. The first and most obvious one if you know that you are going to have a problem is to change the application configuration so that it talks to the new server name, making it once again a stand alone solution. At the same time, you should probably also tell SQL Server that its name changed using sp_dropserver and sp_addserver since it still thinks its the old server (http://msdn.microsoft.com/en-us/library/ms143799.aspx). Another solution is to bring the server up on a segregated vLAN that doesn’t have routes to the production environment.