System Management

Today I learned again a lesson I knew for some time but was hoping that I can forget it. The lesson was about: “Trust anyone. Test for yourself.”

Having to install WSUS on a remote SQL 2005 that had WSUS database installed before, I asked one SQL guy if renaming the old WSUS database is enough to install a new WSUS one. He said yes. Ok then, I started installing WSUS.

Needless to say, installation failed:

There is a problem with the windows installer package.A program run as part of the setup did not finish as expected.Contact your support personnel or package

Two hours of troubleshooting permission and connection problems, made me read all WSUS installation log files located in “X:\Users\username\AppData\Local\Temp”. One of the file was 1 KB size so it does not contain much info. Anyway, the file content was:

Changed database context to 'master'.
Msg 1802, Level 16, State 4, Server SQL-SERVER-NAME,  Line 2
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.Msg 5170, Level 16, State 1, Server SQL-SERVER-NAME,  Line 2
Cannot create file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\SUSDB.mdf' because it already exists. Change the file path or the file name, and retry the operation.
Changed database context to 'master'.

I will not comment the 4^th line as it says pretty much all…

I guess when doing something, you have to test for yourself everything. Lesson learned. Again.

Today a client called me and said that his second domain controller, which is on Hyper-V, is having connectivity problems. For example, running the ping command from DC2 results in very bad response times or timed out requests.

Searching the event viewer, I saw many errors with Event ID 1054: “Description: Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or exist or could not be contacted). Group Policy processing aborted.”

Found a Knowledge Base article on Microsoft website that basically says this is happening if the computer has some AMD technology enabled in the BIOS. Well, my client only has computers with Intel Xeon processors, so this is not the case. Anyway, having experience with such articles vs. errors, I read the article till the end. This way I found similarities with my client’s environment: computers with more than one processors.

Basically, Dual Core or multiprocessor processors may encounter Time Stamp Counter (TSC) drift if certain conditions are met:

• number of processors
• operating system
• technologies enabled in the BIOS
• BIOS version.

This conditions can affect important operations like network communications and performance monitoring tasks that are sensitive to system time

Windows XP, 2000 and 2003 servers use the TSC as a timekeeping source. Each processor core (whether it is a single-core processor or dual-core processor) includes a TSC. When the TSC for different processor cores are not synchronized, the above symptoms and behaviors can occur if the operating system is using the TSC as a timekeeping source.

The KB article’s resolution is to install a newer CPU driver that modifies the boot.ini file by adding a switch in order to force the computer to use the PM_Timer instead of TSC. Also, it says that the boot.ini file can be manually modified.

So, to manually modify boot.ini file follow the following steps:

• Log on to the computer by using an account that has administrative credentials.
• Click Start, click Run, type notepad c:\boot.ini, and then click OK.
• In the Boot.ini file, a line that starts with "default" is located in the "[boot loader]" section. This line specifies the location of the default operating system. The line may appear as follows:

  multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003 Enterprise x64 Edition" /fastdetect /NoExecute=OptIn

• At the end of the line, add a space, and then type /usepmtimer. The line should now resemble the following.

  multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003 Enterprise x64 Edition" /fastdetect /NoExecute=OptIn /usepmtimer

• Save the file, and then exit Notepad.
• Restart the computer

This resolved the connectivity problem, however I wanted to test one more thing. As DC2 where a virtual machine with 2 cores assigned, I changed it to use only one processor and modified the boot.ini file to its original state. After restarting the VM and monitoring the server for bout 20 minutes, looks like the problem went away. So this can also be a workaround. I used the first method as client preferred this one.

These are the articles I read carefully today and used now to write this post:

• Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP: http://support.microsoft.com/kb/895980
• Explanation for the USEPMTIMER switch in the boot.ini: http://blogs.technet.com/perfguru/archive/2008/02/18/explanation-for-the-usepmtimer-switch-in-the-boot-ini.aspx

Usually, extending the Active Directory schema is the last step I do when installing SCCM. This time, while installing SCCM in a virtual machine, you have to provide a path to a folder with SCCM updates or download these updates from the internet. Working in a virtual machine with a “Local only” network adapter, I couldn’t download those updates; so I switch the network adapter to an external one. After downloading the updates, next step is “Installation Prerequisite Check” and at this step I extend the AD schema.

Well, the following error was written in ExtADSch.log file:
Unable to connect to RootDSE - Cannot update Active Directory. Error code = 1355.
Failed to extend the Active Directory Schema.

Error 1355 is: ERROR_NO_SUCH_DOMAIN. That means that the specified domain could not be contacted or does not exist. The problem here is that I did not switched back to “Local only” network adapter and so the Active Directory could not be contacted. Setting the adapter to “Local only”, I could contact the Domain Controller and extending the schema was successful.

I don’t do this usually, but this time this is really interesting.

I want to recommend a very good blog post written by Kenneth Van Surksum about troubleshooting Task Sequences in Configuration Manager. Find it here http://www.techlog.org/archive/2009/03/01/troubleshooting_task_sequences.

He talks about the smsts.log file, where to find it during installation and what tool you can use to read the logs easily. Also, at the end, he wrote a list of helpful links to get you start troubleshooting.

Definitely I will add his feed to my “SCCM blogs I read” list.

Another very good resource I just found! The description of all log files in SCCM 2007. See bellow an example and follow the link for the full post: http://technet.microsoft.com/en-us/library/bb892800.aspx.

Management Point Log Files

If management points are installed in the site hierarchy, management point log files are stored in the SMS_CCM\LOGS folder on the management point computer. The following table lists and describes the management point log files.