SMS_MP_CONTROL_MANAGER Warnings 5416 & 5418

After extending the sms_def.mof and configuration.mof I noticed a large amount of 5416 and 5418 warnings in the SMS_MP_CONTROL_MANAGER with the text:

"MP could not find some class or property definitions when processing Hinv as they are apparently missing in sms_def.mof. Unknown classes and properties have been ignored and a MIF file generated with all the classes and properties that could be found.

Possible cause: This might indicate that the report has become obsolete due to a new HW inventory policy or that a customer's private definitions haven't been properly propagated to the sms_def.mof at the PSS.
Solution: See if the missing classes or properties are genuinely missing in the current sms_def.mof and find out why the client put them in the xml report."

Uh-oh!

So, I had to find out what was going on here, obviously something related to the changes made.
I had a look at DATALDR.LOG on the primary site, no errors there to speak of.

Checked out MP_HINV.LOG and found quite a few warnings..

"Hinv: property name not found in the mapping table: KeyName"

So looks like theres a problem with KeyName.

Comparing the sms_def to the configuration mof files I saw the problem:
sms_def.mof
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("ProvisioningMode", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("ProvisioningMode"),SMS_Class_ID("HEALTH|ProvisioningMode|1.0")]
Class ProvisioningMode: SMS_Class_Template
{
[SMS_Report(TRUE)] String ProvisioningMode;
};

configuration.mof
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("ProvisioningMode", NOFAIL)
[DYNPROPS]
Class ProvisioningMode
{
[key] string KeyName;
String ProvisioningMode;
};
[DYNPROPS]
Instance of ProvisioningMode
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\CCM\\CcmExec|ProvisioningMode"),Dynamic,Provider("RegPropProv")] ProvisioningMode;
};


See the problem? I had forgotten to add KeyName to the sms_def.mof, meaning it couldnt map this, in turn causing my warnings.

Added the missing line to sms_def ([SMS_Report(TRUE),key] string KeyName;) and the problem has now been resolved. No more warnings, and MP_HINV is processing inventory data very happily.

Sweet deal!

Config Manager and AppV Full Infrastructure Model - Config Manager Reporting

I have an App V setup that is a little unorthodox..(AppV in the Full infrastructure model alongside Configuration Manager). This was done to take advantage of the active upgrade and dedicated reporting/licensing features of the AppV Management Server.

We have multiple sites across two countries, but do not have AD Sites for each of these locations. This makes managing AppV a bit tricky, as we need clients in each site to go to their nearest streaming server (streaming server role has been installed on each Config Manager DP).

I have done this by a similar mechanism as Config Manager's Boundaries. A GPO was created, and a Group Policy Preference Registry collection was created for each site, specifying the Application Source Root and Icon Source Root to be the Streaming Server for that site. This was filtered to only the subnets in that site.

So this looks kinda like this:

Registry Collection
Site1 (targeted to subnet 192.168.1.x)
Application Source Root : Server1

Site2 (targeted to subnet 192.168.2.x)
Application Source Root : Server2
Etc etc.

While this may look cumbersome, it actually works very well and enables easy roaming of clients between sites if they need to.

The problem I had was actually having some way of checking the Application Source Root location.

This was quickly resolved by adding to Config Managers inventory to inventory reg keys.
This was done by adding the following to the SMS_DEF.MOF file:
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("AppVLocation", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("AppVLocation"),SMS_Class_ID("CUSTOM|AppVLocation|1.0")]
Class AppVLocation: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String ApplicationSourceRoot;
[SMS_Report(TRUE)] String IconSourceRoot;
};

And this to the Configuration.mof file:
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("AppVLocation", NOFAIL)
[DYNPROPS]
Class AppVLocation
{
[key] string KeyName;
String ApplicationSourceRoot;
String IconSourceRoot;
};
[DYNPROPS]
Instance of AppVLocation
{
keyname="SystemCenter.fr";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SoftGrid\\4.5\\Client\\Configuration|ApplicationSourceRoot"),Dynamic,Provider("RegPropProv")] ApplicationSourceRoot;
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\SoftGrid\\4.5\\Client\\Configuration|IconSourceRoot"),Dynamic,Provider("RegPropProv")] IconSourceRoot;
};

Hey presto, reg keys being collected.

Once I had kicked off inventory and one machine, and confirmed that the new table (dbo.AppVLocation_DATA) had been created, it was time to write a report to make use of these values:

select v_R_System.Netbios_Name0 , v_GS_AppVLocation0.ApplicationSourceRoot0 AS 'Application Source' from v_R_System inner join v_GS_AppVLocation0 on v_GS_AppVlocation0.ResourceID = v_R_System.ResourceID where v_R_System.Operating_System_Name_and0 LIKE 'Microsoft Windows NT Workstation%'

This gives me a nice, basic report telling me which machines are assigned to which streaming server, and also more importantly, any machines that do not have an Application Source Root set for any reason.

Choice!

Unable to edit Task Sequences - SCCM

Today it was discovered that any task sequences I tried to edit and save the changes to, were failing with a "Unable to Store Task Sequence" error. Neat.

Had a look in the TaskSequenceProvider log, and found the following :

[PID: 29436] Invoking method SMS_TaskSequence.SaveToXml TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Failed verifying schema version property in wmi sequence 0x80004005 (2147500037) TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)
Failed to store the WMI task sequence as XML 0x80004005 (2147500037) TaskSequenceProvider 5/17/2010 11:19:07 AM 21712 (0x54D0)

Seems WMI went belly up on the Primary Site Server.. A restart of the
Windows Management Instrumentation service fixed this right up, and task sequences are working once more. A real good start to the day..

State Migration Point failing to start

One of the many State Migration Points I have failed the install (due to the above certificate error). Also, as part of the initial role assignment, the wrong drive was specified.

The site role was removed, web cert added as per above, then readded with the correct path. As a result, the role installed successfully. However, I was then receiving messages about the State Migration Point starting, then stopping unexpectedly.

Checking the SMPMGR.LOG file, I found the following lines :

Creating directory "D:\USMT\SMPSTORED_378B856C$" SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)

Cannot create D:\USMT, Win32 Error = 3 SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)

ERROR: Failed to create directory "D:\USMT\SMPSTORED_378B856C$" SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)

HandleSMPRegistryChanges failed. error (0x80004005). SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)

SMPManager failed to start, Error = (0x80004005). SMS_STATE_MIGRATION_POINT 14/05/2010 5:41:31 a.m. 3184 (0x0C70)

So the SMP was trying to create the folder on the old path, the one specified before I removed and readded the role with the correct part. Damn!

I took a look at the reg key that has the SMP settings (HKLM\Software\Microsoft\SMS\SMP\StateStore) and found TWO subkeys, one for the incorrect path (D:\USMT) and one with the correct path (E:\USMT).
Seems it only reads the first key in here (which makes sense).. Remove the incorrect subkey, and start the SMS_STATE_MIGRATION_POINT component via the service manager.

Check the SMPMGR.LOG file, and bingo! path is created, and component is now ticking along nicely.

Configuration Manager - State Migration Point Install Failure

Just had an issue with the install of a SMP to one of our servers.

I received the below errors in the SMPMSI.LOG :

The state of web site "Default Web Site" is Started.
ERROR: Certificate is not configured on the website for SSL.
ERROR: Validate IIS failed with 0x80004005.
@@ERR:25055
Product: SMS State Migration point -- Internal Error 25055. 80004005

I took a quick look on the server, and lo and behold there was no server cert in IIS under secure communication.

Quick fix (for a change!) - Requested a web server cert, and attached it.
I then removed the State Migration Point role, and readded it.

SMP is now happy, sweet deal!

Inventory Data Loader warnings + more..

This blog is kind of a reference for myself, but if anyone else makes use of the random pieces I put here, then all the better, all about sharing information.

I don't know about anyone else, but now and then I receive warnings in my Inventory Data Loader component. These are normally in the format :

"SMS Inventory Data Loader failed to process the delta MIF file "BLAH" and has moved it to "D:\Program Files\Microsoft Configuration Manager\inboxes\auth\dataldr.box\BADMIFS\ucq33ee1.MIF."

These only appear to happen for some delta inventory info, and subsequent resynchs will produce the same message.
A full Inventory Resynchronization fixes these clients right up.

The Operations Management team wanted a way they could easily identify which clients were causing these warnings, and a way for our help desk to resolve them.

To do this, I took a two pronged approach.
1) Created a script that parses the computername from the BADMIF files and adds it to a spreadsheet. (you can download this here if you want, all normal disclaimers apply, im not responsible for anything going ka-boom, run at your own risk etc etc)
2) Added a function to the 'Client Management Tool' that I created for the help desk to perform a full HW Inventory.This way, the operations team knew which machines were causing these warnings, they can pass the spreadsheet to the service desk who can then run the full HW inventory to clear these up.