Default Profile Data - OS

[NealC804]

I enabled the collection of default profile data as an experiment. I log into the update manager web site to see the results and it's working, however, can you PLEASE decipher the OS "version numbers" you are recording to actual OS's????? The idea here is for you to make things easier for us. It's great to have the version, and yes, there is a table "somewhere" that can translate the cosmic version to the Operating System "friendly name" and it sure would be nice if you could categorize the data for us by the OS "friendly name." I'd much rather see numbers/percentages of Windows XP vs. Windows 98 rather than 4.x.x.x vs. 5.x.x.x.x.

Thank you.

[NealC804]

I'll also add that the IP address is the machine IP as it says and NOT the external address we would prefer. Getting a 192.168. number does nothing for me. But a public IP tells me a whole lot more.

Lastly, am I going to see a monster spreadsheet/grid of all these installs or is there going to be a nice way to group by OS, etc.?

I think these feedback items fall into another area of "not thought all the way through" but a start I suppose.

[KellyF]

neal007 wrote:
I'll also add that the IP address is the machine IP as it says and NOT the external address we would prefer. Getting a 192.168. number does nothing for me. But a public IP tells me a whole lot more.

The IP address piece was initially created solely for the purposes of the CMP (multi-tier), however, it was later brought into the overall set. I'm not sure of the exact mechanism used by the installer to determine the client's IP address. However, your code can get the external interface and use it to update the profile value on next communication. This may constantly be changing if you have users on dialup or DHCP.

neal007 wrote:

Lastly, am I going to see a monster spreadsheet/grid of all these installs or is there going to be a nice way to group by OS, etc.?

At one point I believe there was a sorting mechanism, then someone mentioned that persons may actually prefer to just get the data and tweak it in their favorite spreadsheet. (Yes, I was that person because I prefer the raw data so I can mark it up and analyse it as I please and not rely upon pre-canned ways)


KellyF

[NealC804]

KellyF,

Can you shed any light on the OS "version number" instead of the "friendly name"?

[KellyF]

Again it was a case of passing the value directly up to the server that was set during install, though you can override any of the values via the API. We basically wanted to provide persons with some default values that the systems could collect and not be "filtered" by us... as how I would filter the data may not appeal to other developers. So why should my style (influenced by *nix) be imposed upon others.

Based on this thread thus far, I get the feeling that rather than manage it via your APIs, you'd like some mechanism for translating it in the reporting section rather than a raw-data perspective?

KellyF

A side effect of this is: if person A is having problems with your app, and persons B and C are ok, you may see something in terms of the build they're using.

[NealC804]

My goal is to do this fast and easy, and by the fact the option in the Update Service portion of 10.5 has a bit to choose the collect default data, I would like it to be easily displayed with minimum effort. I would also venture that in the case of someone not using the Pro edition, i.e. API control not available, they don't have this luxury. Just like component vendors, the goal here is RAD. I would hope you could adopt the same and not require me to code in version number deciphering to see how many of my users are on Windows XP vs. Windows 98. That would be something to greatly improve the face value of your reports. Version numbers are worthless to me as you have them now, may as well not have them as I'm not going to do hours of work to export from your system (which I assume can be done), import into a program I had to write, and then view the stats again I had to write. I'm paying for ISUS for a reason, otherwise every one of us here has the talent to write this ourselves. We are here to SAVE time, not create more work.

Thank you.

[Marcel_NL]

Is there going to be a simple tool on the website where we can choose between raw-data O.S. versions and user-friendly O.S. versions?

Or do we have to do a manual translation of the build numbers into the user friendly numbers after the report has been created?

Or perhaps translate the build numbers to user-friendly numbers ourselves before uploading them to the US database? (Which I don't prefer....)

[KellyF]

I'm afraid it's probably too late for me to wriggle this into the project plan for the next release, however, I will attempt to write up something. If both of you could submit it as a feature request via the website or eService, they may deem it worthy of trying to fit into an earlier release.

My working assumption is that you care nothing about the actual build their running (ie. WinXP SP2 plus hotfixes 1, 2, and 5 would be just WinXP)

Regards,
Kelly

[Marcel_NL]

KellyF, thanks for your information.

Maybe it's nice to have a gradation level for this.
E.g. level 1 = O.S. name (only WinXP, Win98 etc.)
level 2 = O.S. name plus applied service packs (Win98SE, W2K SP4 etc.).
level 3 = pure build numbers (raw data).

And in order to understand the level 3 (raw) data, one could lookup the translation table used for displaying the level 2 data ?

(But) starting with just a choice between level 1 and 3 would be fine....

Regards,
Marcel

[KellyF]

Marcel,

Sorry for taking so long to reply, but I've been caught up in other things. The value which is returned will vary depending upon the agent you use (Universal vs. Windows).

The Universal agent will return "nice" values such as:
AIX, Digital Unix, FreeBSD, HP UX, Irix, Linux, Mac OS, MPE/iX, Netware 4.11,
OS/2, Solaris, Windows 2000, Windows 95, Windows 98, Windows NT, Windows XP. These come from the "os.name" property of Java.

The Windows agent will return values based upon the Windows API GetVersionEx. The format is "{%i.%i.%i}", osinfo.dwMajorVersion, osinfo.dwMinorVersion, osinfo.dwBuildNumber. Microsoft docs for it are at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/osversioninfo_str.asp

Given the differences, we'll need to create a translation layer when pulling data from the database.... but I want to be careful about how we do it.... according to the docs from Microsoft, we will not be able to easily distinguish Windows 2003 from Windows 2003 R2 except by build number which can change was OS patches are applied. Also, a Windows XP 64-bit would look like Windows 2003, differing only in build numbers.

Regards,
Kelly

[Marcel_NL]

Kelly,

Thanks for your reply.
I submitted this issue as a feature request like you proposed.

If I understand you correctly, the US Web Site will perform the translation of the build numbers into the O.S. friendly names? And therefore all I have to do, is to modify my program to upload the O.S. version info (in "{%i.%i.%i}" format) using the API function CollectDefaultProfileData() ?

Do you know when this feature will be implemented on the web site?

Regards,
Marcel

[KellyF]

Seems you're online so these responses will be quick.... 🙂
Yes, we will attempt a translation at the publisher side. I cannot promise which release, but I have a feeling it will be a little while yet.

Using the CollectDefaultProfileData() will pull the version information for you, without you needing to pull it yourself. That is, it'll call the Windows API and set the value to {x.x.x} for you with minimal effort.

In the meantime, since you're discussing the Windows agent, here's a rough translation
Version number Operating system
{6.0.x} Windows Vista Server
{6.0.x} Windows Vista
{5.2.x} Windows Server 2003 R2
{5.2.x} Windows Server 2003
{5.2.x} Windows XP 64-bit
{5.1.x} Windows XP
{5.0.x} Windows 2000
{4.90.x} Windows Me
{4.10.x} Windows 98
{4.0.x} Windows NT 4.0
{4.0.x} Windows 95

Regards,
Kelly

[Marcel_NL]

OK. Thanks for the information.

Regards,
Marcel

[bwknight]

Given the differences, we'll need to create a translation layer when pulling data from the database.... but I want to be careful about how we do it.... according to the docs from Microsoft, we will not be able to easily distinguish Windows 2003 from Windows 2003 R2 except by build number which can change was OS patches are applied. Also, a Windows XP 64-bit would look like Windows 2003, differing only in build numbers.

I need to determine when my installer is running on Windows Server 2003 R2, and I found this info from the Microsoft webste:

To determine whether the current operating system is Windows Server 2003 R2, use the GetSystemMetrics function with SM_SERVERR2.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdkintro/sdkintro/windows_server_2003_r2.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/getsystemmetrics.asp

and SM_SERVERR2 = 89

Thought I'd post this since it might come in handy for anybody working with Windows Server 2003 R2.