Upgrade Configuration Manager client

Recently I reinstalled ConfigMgr server in my company and was looking for an easy method to upgrade all Configuration Manager clients to 4.00.6487.2000 version.
Put some notes on the table and finally made the following plan:

  • Create a report that counts all client versions. (This is optional, just for informational purposes).
    Report query is:SELECT TOP (100) PERCENT Client_Version0 AS [ConfigMgr client version], COUNT(Client_Version0) AS Total
    FROM dbo.v_R_System GROUP BY Client_Version0, Client0 HAVING (Client0 = 1)
    ORDER BY Total DESC, [ConfigMgr client version]
  • Create a collection (“Older Clients” for example) with all system resources with a client version not 4.00.6487.2000.
    Collection query is:SELECT SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name, SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client
    FROM SMS_R_System
    WHERE SMS_R_System.ClientVersion != "4.00.6487.2000"

    This way, system resources with older client version will be members of this collection.

  • Created a package and program with ConfigMgr client upgrade with custom command line parameters.
    Program command line is:CCMSETUP.EXE /noservice SMSSITECODE=CFM SMSCACHESIZE=1024 SMSSLP=BLAH.DOMAIN.COM SMSMP=BLAH.DOMAIN.COM RESETKEYINFORMATION=TRUE
  • Advertised it to “Older Clients” collection.

Now, as system resources with older client version are members of this collection they will receive the advertisement and will silently install the latest ConfigMgr client.

When the collection will have no system resources, I will know that all clients are upgraded. Also, I can check this by opening the same report from any browser on any computer.

Problem installing WSUS on a remote SQL server.

Today I again learned 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 DB. He said “yeah, sure!”. 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'.

One specific line says it all… “Cannot create file … because it already exists”

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

How to create a Windows Image (.wim) file

Depending on what you need the .wim file for, you can create it manually or automatically.

– To manually create a .wim file (capture image) you need a bootable CD with Windows PE (with ImageX.exe included) that you can create using Windows Automated Installation Kit.

The basics steps are:

  1. Boot your computer using Windows PE disk.
  2. In the Windows PE command prompt navigate to the folder with ImageX.
  3. To capture the C: partition, use the following example:
    imagex.exe /capture C: D:\CapturedImage.wim “My captured image”Where: C: is the partition to be captured; D:\CapturedImage.wim is the place of the captured file; “My captured image” is the name of the file.
    More switches can be found on the ImageX Command-Line Options page.

If you need the image for deployment, do not forget to run sysprep before capturing the image!

– To automatically create a .wim file you can use a capture media created using Configuration Manager.

If you want to capture a Windows XP OS, copy sysprep files to C:\sysprep. Newer operating systems have sysprep files installed by default.

To use capture media:

  1. Insert the CD into your CD/DVD drive and shortly autoplay will open Image Capture Wizard.
  2. Clicking Next will show you Image Destination page. Select where to save the wim file.
  3. On the next page enter some information about the image.
  4. On the Summary page click Finish. The task sequence will start sysprep and restart the computer. After restart, the computer will boot to Windows PE and will capture a image of the machine.

Windows cannot obtain the domain controller name error

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 was 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 during troubleshooting and used now to write this post:

Install software using Task Sequence

Besides using Software Distribution to install software, you can do this using a Task Sequence too. This can be done during and Operating System Deployment process or not.

Usually, I install software during an OSD. For this, you must have a package for that software product (of course) and at least one program that runs silently. If the program  requires user intervention, you will not have the possibility to add it to your TS. I hope you know the fact that the package should exist on a Distribution Point.

This is how one of my simplest TSs looks like:

To add an Install Software step, in your TS click Add from the menu and select GeneralInstall Software.


Then, type a name for this step and using the Browse button select a package to add the TS. Remember that you can only add packages that has a program to run without user intervention.

I find it useful to have a step to install latest updates after all install software steps.

One more way to install software using a TS, is to have only Install Software steps. This way, you can install multiple software products using one advertisement instead of advertising every package. I use this only when I have an OS installed and I want to install software on it.

This is how such a TS looks like:

WMI query for processor manufacturer

Following the post regarding how to install drivers based on computer model using WMI query, here is another query you can use in your task sequences to install some processor specific software for example.

To find the processor manufacturer during a task sequence, insert a condition for the step you need, and select Query WMI. Then, for WMI Namespace use root\cimv2. For WQL Query use SELECT * FROM Win32_Processor WHERE Manufacturer like “%GenuineIntel%” or SELECT * FROM Win32_Processor WHERE Manufacturer like “%AuthenticAMD%” depending on what you need.

To find the processor manufacturer of your computer, open a command prompt and type the following: WMIC CPU GET Manufacturer.

How To: Operating System deployment with MDT 2010 and ConfigMgr 2007 SP2

Johan Arwidmark, Setup & Deployment MVP, just finished working on his Version 2.0 Deployment CD. It contains the following step-by-step guides and video tutorials:

MDT 2010 Lite Touch Deployments (deployment without ConfigMgr 2007 SP2 R2, just the free tools)

  • LTI01 – Installing the server for MDT 2010 Lite Touch
  • LTI02 – Creating a Windows 7 reference image using Lite Touch
  • LTI03 – Deploying a Windows 7 image using Lite Touch
  • LTI04 – Dynamic Settings, creating and using the deployment database

MDT 2010 Zero Touch Deployments (deployment with ConfigMgr 2007 SP2 R2)

  • ZTI01 – Installing the server for MDT 2010 Zero Touch and ConfigMgr 2007 SP2
  • ZTI02 – Creating a Windows 7 reference image using ConfigMgr 2007 SP2
  • ZTI03 – Deploying a Windows 7 image using ConfigMgr 2007 SP2
  • ZTI04 – Dynamic Settings, creating and using the deployment database

Additional Presentations

  • E01 – New features in MDT 2010
  • E02 – Upgrading MDT 2008 to MDT 2010
  • E03 – Migrating Windows XP to Windows 7

And guess what? He’s offering the CD for free to everybody who needs and wants it. You can register for a free download at www.deploymentcd.com.

All reports with links to other reports

Last month, after restoring the only ConfigMgr site and importing new reports, I saw that none of the reports I’m using have a link to another report.

To be sincere, this was a problem I didn’t know where to start troubleshooting. Thanks to guys from Microsoft’s ConfigMgr forum, who helped me identify the problem and recommended some troubleshooting steps.

So, the problem was due the fact that none of my reports had a link to another report. Don’t know how this happened… Anyway, to resolve this issue, I quickly installed a ConfigMgr site in a virtual machine and using Tom Watson’s advice, created a query that lists all reports with links to other reports. The query is something like this:
SELECT     TOP (100) PERCENT ReportID, Name, Category, DrillThroughReportID
FROM       dbo.v_Report
WHERE      (NOT (DrillThroughReportID IS NULL))
ORDER BY   ReportID

and the result looks like this:

DrillThroughReportID tells the ReportdID of the linked report. Basically, in a default configuration, I know the original ReportID and the linked ReportID.

Now, knowing these info, I’m manually creating the links in my production environment. This is a long process indeed, but I couldn’t find a way to automate this.

Create collection with all Windows XP SP 1-2-3 systems

To create a collection with all Windows XP SP1 systems, use the query bellow:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows XP%" and SMS_G_System_OPERATING_SYSTEM.CSDVersion = "Service Pack 1"

Similarly, to create a collection with all Windows XP SP2 systems, just change the Service Pack version number:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows XP%" and SMS_G_System_OPERATING_SYSTEM.CSDVersion = "Service Pack 2"

And the same for all Windows XP SP3 systems:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like "%Windows XP%" and SMS_G_System_OPERATING_SYSTEM.CSDVersion = "Service Pack 3"

During OSD, format first partition only

Our helpdesk asked me to make a task sequence that can be used on computers with more than one partition. In this case, I had to make sure that the operating system will install only on first partition and will not touch the data on other partitions.

To achieve this, I copied another TS and modified the following 2 steps:

  • removed any “Format and Partition Disk” step
  • in the “Apply Operating System Image” step, under “Select the location where you want to apply this operating system” made the following modifications:
    • Destination: Specific disk and partition
    • Disk: 0 (if all computers are installed on first hard disk)
    • Partition: 1 (if all computers have OS installed on first partition)

This way, when TS runs, it automatically wipes partition 1 from disk 0 and will not touch any other partition or disk.

Wiping volume C:\