As you already know with the release of SP3 for SMS 2003 the Asset Intelligence integration is now included.  This means that you will get better data for software inventories, no more Visio v 3.445.3452134.4634.a and Microsoft Visio v 3.445.3452134.4634.b, it will just be Microsoft Visio v 3.445.3452134.4634...I kid...You reports should be much more readable and all those executables that have sat dormant in your software inventory database will now come to life because of the correlation between the new data included in Asset Intelligence.  As you have also likely heard the size of your SMS database will grow as well, this can be a big deal for some, and not so for others, depending on your hierarchy and servers.  This will also be dependent on your configuration of the new SMS_DEF.mof file included in SP3. 

So a quick recap for those who may not be modifying the SMS_DEF.mof file.  This is the file that controls what data you pull from your clients and put into your SMS database.  You can modify this file in two particular ways, by enabling or disabling a class or by adding a class.  If you simply enable or disable a class that means you do not have to recompile it for all your clients, you simply make a backup of it, modify the class to your liking, and then you save your changes, your clients will get the new file on their next inventory cycle and then report the data back, or stop reporting the data if you disable a class.  When you add a class to the file you have to recompile it and distribute it to your clients, this will cause them to do an inventory and report the new data, a little more traffic and work on the client than the other way but you do what you have to do. 

Now that is over let get back to SP3.  In SP3 several new classes are added to the SMS_DEF.mof file for not only the Asset Intelligence software correlation piece but also USB devices, Browser Helper Objects, the AutoRun registry key, and outside of Asset Intelligence they added support for Add or Remove Programs for 64 bit clients, and changes to class names.  So what does all of this mean?  Well as I pointed out earlier this could lead to some client processing, as well as some network traffic reporting all this data back, not to mention the load on your MP and SQL database. 

So what can you do to help with this situation, you can - and should -

  • Modify the SMS_DEF.mof to your liking before you implement it, if you have made changes prior to SP3, you will want to make those same changes to this file as well as long as they do not conflict with the new classes,
  • also make sure that your edits do not make use of any of the class names that have been changed in the SP3 version.
  • Only enable the classes that you need, if you do the full install of SP3 but don't really need all those classes then change them to FALSE first.
  • DO NOT enable the SMS_SoftwareShortcut or SMS_InstalledExecutable classes.  I know they sound so cool and you can't wait to find out what they do.  For one if you have multi-language machines you will probably get a flood of calls to your helpdesk as the users start to call in and complain that their computers lost its mind.  The CPU pegged at 100%...Don't believe me?
  • Finally, calculate the impact your are going to have on your network by estimating the amount of traffic you will get back when the clients begin to report their new inventories.

For the calculations this is where we get into that Trig I took! 

SMS_InstalledSoftware per instance will send 1047 bytes, so each listed application will send 1047 bytes.

SMS_InstalledSoftwareMS comes in at 290 bytes per instance, so each app listed that is also a Microsoft app will send 290 bytes each.

SMS_SystemConsoleUsage 330 bytes, event viewers security log console usage.

SMS_SystemConsoleUser 294 bytes, same as above but per user.

SMS_AutoStartSoftware 681 bytes, for each app that runs at startup you will get 681 bytes sent.

SMS_BrowserHelperObject 589 bytes, for each piece of spyware your users have installed you can expect to get 589 bytes detailing their every move.

Win32_USBDevice 606 bytes, come on...you know what this reports.

SMS_Processor 496 bytes, this is the CPU information but with new properties added to the class.

SMS_InstalledExecutable 739 bytes, guess...

SMS_SoftwareShortcut 775 bytes, guess again...

SoftwareLicensingService 813 bytes, Vista licensing.

SoftwareLicensingProduct 401 bytes, and Vista licensing.

The last two are Vista only and unless you have Vista client you should disable them in the SMS_DEF.mof file, and the two above them should not be enabled but I already covered that.  In Microsoft's own example scenario they estimate that SMS_InstalledExecutable would typically return 500 instances, or 369500 bytes.

You can see more specific details here, where Microsoft explains the new SMS_DEF.mof.

Regards,
Anthony

Anthony Clendenen | Systems Engineer | 1E Inc.


We are considered a premier SMS Solution Provider by Microsoft. See us at http://www.microsoft.com/smserver/partners

 

"1E's tools add significant value to SMS in particular, around patch management, simplified branch designs and desktop migration. Having been a trusted Microsoft partner for five years, 1E's track record in consultancy and software solutions comes highly recommended."
- Bill Anderson, Lead Product Manager, Enterprise Management Division, Microsoft

 

No Comments 21:41 - Jun 25, 2007



Trackbacks

No Trackbacks

Comments

No Comments