Create custom wallpaper for your servers

I like to set the Windows Desktop to a specific color to easily identify it from other desktops I may have open. This way when I have multiple Remote Desktops running I can quickly see which one I need to click on. At a minimum I usually set the background color of the Desktop.

Recently though, I started making custom images that I use as wallpaper that incorporate color idea and adds information to positively identify the server I am working on. This information usually includes the host name, IP address, a brief description, and the type of OS running.

I try to make the color the same as the color associated with the primary software installed on  the server. For example, our Prophet21 server is purple since that was their primary color in their logo, orange is used for our Shoretel server, etc. Some servers just have a color that was picked randomly years ago and stuck. Our database server uses olive while our webserver uses teal.

I use Gimp to make the images and put them on the root of the C: drive of the server. Since these are servers themes are usually disabled. To make the image appear as wallpaper I have to open them in Paint and from the File menu select “Set as Wallpaper”. The following are examples of wallpaper for a few of my servers.

This is a screenshot of my Taskbar showing how helpful these wallpapers are:

Advertisement

Cannot login to Windows machine on vmware snapshot

In setting up a new SQL Server 2008 server in VMWare I created a baseline snapshot of the machine as it was before installing SQL Server. This way I could practice installing SQL Server refining the process with each installation.

Today, I reverted back to my baseline snapshot and suddenly could not log in to the server using Remote Desktop. The Widows 7 Remote Desktop client was less than helpful about what could be the cause.

Checking the Event Log on the server only added to the mystery. The server recorded event ID 4625 for a logon failure. According to the log the username and password was not correct but, I know that was not true.

The clue that revealed the actual cause of the problem came from Windows 8! When trying to connect to the server using Remote Desktop on Windows 8 the error was much more specific:

True enough, when I looked down at the time the date and time was way off. The server running in the virtual machine appeared to be using the date of the snapshot’s creation. Being a member of an Active Directory domain I expected the date to be set to the date and time of the domain controller.

Fortunately, you can run DOS command to set the time to the correct time provided by the network time server. The following command resets the time and instructs the server to seek out the network time server:

w32tm /resync /rediscover

Surprisingly, the ancient “net time” command still works and gives you instant feedback:

net time /set

The lesson learned here was to make sure to reset the date and time when going back to a previous snapshot in VMWare.

Transferring logins in SQL Server

I am in the process of upgrading our Prophet21 databases from SQL Server 2000 to SQL Server 2008 R2. After restoring the backup from the old server you are left with a database that has user logins assigned to it that do not exist in the new SQL Server. Furthermore, if you try to just re-create them in SSMS you’ll still have a problem because the “Security Identifiers” or SIDs will be different. You must transfer the logins from the old SQL Server to the new SQL Server.

First, to check for orphaned users in the restored database on the new SQL Server using the stored procedure sp_change_users_login:

This will list all the users in the database that do not exist in SQL Server. To correct this you need to create these users and their SIDs by transferring them from the old SQL Server. There are a few ways to do this but, I found the simplest is to use a modified version of the script Microsoft provides in kb Q918992 that I downloaded from this thread on SQLTeam.com. I ran this script on my old SQL Server.

After running this script I then ran the command (still on the old SQL Server) EXEC sp_help_revlogin which creates, as output, a series of script commands that will create new users when run on the new SQL Server. After running the script output by the stored procedure on the new SQL Server I re-ran the command to check for orphaned users and the result was none being found:

You can download the script I used or get it from the forums. I tweaked it a bit adding a line to check for the existence of the stored procedure it creates since I had run it once already before figuring out what was happening.

Another option for transferring users is to use the transfer logins task within SSIS. Andy Hayes explains how to do this on his blog but, I ran into problems — it appears to only work if the database name is the same on both the old SQL Server and the new SQL Server. I had changed the name of my database during the restore. This may still work but, my knowledge of SSIS is still fairly limited.

Yet another option presented by Shaun Stuart was to use SQL Server 2005 like a swing server — transferring users from 2000 to 2005 and them from 2005 to 2008. Apparently, even when able to use transfer logins task within SSIS going from 2000 to 2008 had problems that were overcome with his technique. You can read about this on his blog.