May 2009 - Posts
I found a nice post about enabling Asset Intelligence within SCCM and thought I should reference it here and expand upon it for those who prefer a little more detail. The post is by Kenny Buntinx and can be found here:
Within the post, Kenny mentions the two files which need adjustment for this to work. Knowing that I've seen multiple posts in the past where individuals do not know the locations of these files, here are the paths:
Now for a deeper dive into the classes needing enabling within the SMS_DEF.MOF file, here is the listing: (As Kevin states in his post, there are eleven classes.)
The section of the Configuration.MOF to which Kevin refers is near the bottom of the file and reads as such: (CALCollectionType is at the top of the section - default value is 0)
instance of CCM_CALTrackConfig
CALCollectionType = 3; //0-Disabled, 1-User CAL, 2-Device CAL, 3-All
CALCollectionFrequencyDays = 1;
CALCollectionFrequencyMinutes = 60;
CALCollectionTimeWindow = 90;
CALCollectionSupportedWindowsVersions = "5.0,5.2,6.0";
Thanks to Kevin for a very helpful post!
Asset Intelligence was on the agenda this week and after enabling the classes within the MOF (Thanks to Brian Mason for having me double check that I go them all - I had not.) I was lightly entertained to see that the following error is still around:
"Warning: cannot get SMS_Class_ID of SMS_Win32ProviderEx"
As I recall, this error cropped up with the SP3 upgrade and the workaround was to ignore it. At this time, I'm going to employ that workaround and hope that it holds true with SCCM. If not, I'll edit and post the resolution.
While creating a training video for our Desktop Support team, I was going over some messages in an execmgr.log file of one of the workstation clients on the lab network. Considering the log section was of a successful advertised deployment, I was a little perplexed when I saw a yellow highlighted line in the log stating:
GetFileVersionInfoSize failed for the file C:\Windows\...stuff...\msiexec.exe, error 1812
Microsoft has information on this function at: http://msdn.microsoft.com/en-us/library/ms647005(VS.85).aspx
The warning message itself seems to have no connection to a success or failure of this advertisement - it seems more like an error code which is pointing to some missing items within the .exe.
Microsoft has information on this and other error codes at: http://msdn.microsoft.com/en-us/library/ms681386(VS.85).aspx
If anyone has any other information as to why this warning would crop up in various advertisements within SCCM, please feel free to comment.
As I leap into the upgrade of our environment from SMS 2003, I'm confident that I will encounter errors, problems and/or messages of which I will find references scattered about the web. In order to help others out in the future, I will be consolidating my findings here and crediting those sources where I find resolutions and/or explanations.
First off, my disclaimer:
This is not a solution for every scenario in which you may encounter the described problem, but it is one solution which has helped me on many occasions.
So, onto my issue. We have, on occasion, encountered workstations which would pull down some advertisements, but not all of them. There were no consistent factors between the advertisements being omitted, but there was one common factor among the workstations - the Computer Browser Service would shut down without reason. Event ID 7023 was logged in the System logs of the affected machines:
This is an easy find in Microsoft's sites and the fix is located: (And our workstation profile fits this description to a tee - XP SP2 and firewall being turned off via GPO)
Once this fix is applied, the machines exhibiting the issue begin pulling down advertisements again. Something to note, if you apply SP3 to your XP machines, this problem does not occur. Unfortunately, if you have a machine which is not pulling down advertisements, you cannot apply the hotfix, nor SP3... sneaker net time.