[ADSM-L] Windows client CPU information

2012-03-19 16:01:08
Subject: [ADSM-L] Windows client CPU information
From: Thomas Denier <Thomas.Denier AT JEFFERSONHOSPITAL DOT ORG>
Date: Mon, 19 Mar 2012 15:48:02 -0400
I decided to post the material below because there has in the past been
significant interest in methods of using TSM facilities to determine
client licensing requirements.

I sometimes have difficulty getting information about processor
configurations for TSM clients, and end up using 'define clientaction'
commands with 'action=command' to obtain the information directly from
the client system OS. I have never had any trouble doing this with
Linux or Unix; I have the system send e-mail containing the contents of
/proc/cpuinfo (Linux) or the output from the appropriate command (Unix).

Windows systems at our site generally don't have any sort of command
line mail facility. Up until now, I have ended up creating a file on
the client system when I needed to fetch processor information for a
Windows client. This is both nerve-wracking and politically sensitive.
I finally figured how to avoid creating client files by using a series
of commands that pass information back to the TSM server by way of the
Windows error level. The error level can be obtained using the 'query
event' command. The default output format will show a non-zero error
level after the word 'Failed' in the 'Status' column. The 'f=d' format
will show the error level after the 'Result:' field label.

It is easy to obtain the total number of hardware threads using:

object='exit %NUMBER_OF_PROCESSORS%'

It is also necessary to obtain the processor brand and model in order
to distinguish between:
* Brands with different licensing rules
* Different sub-categories of Xeon processors
* Multi-core processor chips and multiple single core chips
* Processors with and without Hyper-threading

In most cases, the first step in determining brand and model is to find
out whether the system uses Xeon processors with the current style of
model designation (letter and four digits, such as 'E5540'). This can
be done with:

object='reg query
/v ProcessorNameString|findstr
/r /c:" Xeon([TMR]*)  *CPU  *[ELX][0-9][0-9][0-9][0-9] "'

In order to improve readability I have inserted line breaks in some of
the places where the actual object string has spaces. I have done the
same in other object strings show below. The command will return an
error level of zero for Xeon processors with the current style of model
designation, and an error level of one otherwise.

In the latter case, one would have to follow up with similar commands
using other regular expressions to distinguish among the remaining
possibilities: Xeon with four digit model number but no initial letter,
Xeon with no model information, or various sorts of non-Xeon processors.
Note that the Windows 'findstr' command supports an unusually limited
subset of the conventional regular expression syntax.

If the command returns an error level of zero, the final step is to
obtain the numerical part of the model number, using:

object='for /f "tokens=6 usebackq" %x in (`reg query
/v ProcessorNameString`) do set model=%x & call exit %model:~1%'

Tests show that this object string will pass a four digit error level
into the results of a 'query event' command (this would not be possible
with Linux or Unix clients). If the model designation turns out not to
have an initial letter, the part after the 'do' keyword can be
simplified to 'exit %x' (as in the object string shown below for
obtaining the processor family). Model designations are sometimes
available for brands other than Xeon. For example, the Core 2 Duo chip
in my desktop PC is an E8500. Commands similar to the one above could be
used to retrieve the numeric portions of such model designations. Note,
however, that the token number (6 in the object string above) for the
model will vary between brands, and sometimes vary within a brand. Web
searches for examples of processor name strings indicate that a Core 2
name string may contain either 'Core(TM)2' or 'Core(R) 2'.

If a model designation is not available, the processor characteristics
will have to be determined from the the family, model, and stepping
values. The family can be obtained using:

object='for /f "tokens=5 usebackq" %x in (`reg query
/v Identifier`) do exit %x'

The model and stepping can be obtained using similar object strings with
token numbers of 7 and 9. In my experience, the easiest way to figure
out what processor characteristics go with a specific combination of
values is to search the Web for a posted example of a /proc/cpuinfo file
from a Linux system with the same type of processor. Linux distinguishes 
among multiple chips, multiple cores per chip, and multiple threads per
core with a clarity rarely seen in discussions of Windows systems. There
seem to be cases where a family, model, and stepping combination used
before the advent of explicit model designations has been recycled for
use with a newer processor that has a model designation. Watch out for
this when reviewing the results from Web searches.

The method outlined above has some limitations. It will give incorrect
results for clients on which BIOS settings have been used to disable
Hyper-threading on processors that normally support it. The method has
no provision for detecting empty processor sockets, which may affect
licensing requirements for processors from the Nehalem-EX branch of the
Xeon family.
<Prev in Thread] Current Thread [Next in Thread>