The CM07 client cache directory is specified as:

<LOGICAL_DRIVE>:\<CCM_CACHE_FOLDER>\<PackageID>.<Package_Source_Version>.<System|[User_SID]>\<FolderName|FileName>

This is built up from:
<LOGICAL_DRIVE> - the logical drive of the volume where the Cache directory is stored-> <LOGICAL_DRIVE> will be 1 character from A till Z-> 3 characters in total.

<<CCM_CACHE_FOLDER> - the folder where the CM07 Client stores Package Data that was downloaded from DP -> <CCM_CACHE_FOLDER> by default is: Windows\System32\CCM\Cache-> the actual folder may be different from the default, is user configurable-> 28 characters in total: Windows\system32\CCM\cache

<PackageID> - the SMS PackageID-> the PackageID has a fixed size of 8 characters in format + the dot (“.”)-> 9 characters in total: CM70017A.

<Package_Source_Version> - the Source Version Number of the package-> a number between (1 .. xxxx), may be 1 to 4 characters in size + the dot (“.”)-> 5 characters in total: 9999.

<System|(UserSID)> - is either 'System' if package is executed in Local System context OR the Security Identifier (decimal formatted) of the user that downloaded the package source -> System is a fixed size of 6 characters + “\” -> <UserSID> is in decimal format and may be 51 bytes or less in size + “\” -> 7 characters in total when targeting to the system: SYSTEM-> 52 characters maximum when targeting to a user: S-1-5-21-1046319769-833967741-3563887046-8288-> the 52 character maximum is the maximum that a SID can be.

The path length of the CM07 client cache folder is 3 + 28 + 9 + 5 + 53 = 98 characters.

<FolderName|FileName> - a folder or file that makes part of the Package folder structure or files
The maximum allowed path length for the package is the maximum allowed path length for the OS minus the path length of the location of the cache folder.

The maximum allowed path length for the OS is 255 characters.

The maximum allowed path length for the package is 255 - 98 = 157 characters.

Everything above 157 characters in path length on the DP can be a problem for downloading a package to the CM07 client cache. Everything above 167 characters in path length will almost certainly fail with a too long path.

        How can I find the package hash value in WMI on a BDP:

1. Open Webemtest and connect to root\ccm

2. Select Enum Classes, click the recursive radio button press OK

3. Scroll down to ccm_peerdpagent and double click

4. select ccm_peerdp_job and click instances.

5. click a package packageID listed.

6. Scroll Down to the hash value.

Compare this value in WMI to the Hash value that you find on the Distribution Point for the same package. To get the hash value for the distribution point content use a tool called hashdir.exe. (This is an internal tool so you would need to contact your PFE DSE for it). Compare the two hashes above with the 40 character Sha1 hash that is listed in the “NewHash” column of the SMSPackages Table of the database. Obviously these should all be the same.

What is the BDPTmpWrkFldr?

There are three folders that come into play here, they are listed below in this order:

Needs Folder

Assemble Folder

Content Folder

The flow from one folder to the next is like this:

Flow----->Needs Folder----->Assemble Folder---->Content Folder

1. BDPTmpWrkFldr\PDP5DB1.tmp - AKA "Needs" folder used by the Content Transfer Manager where deltas and needs files are downloaded and saved to, before being compiled and sent to the Assemble folder, this folder is deleted after it has been utilized.

2. BDPTmpWrkFldr\PDP5D91.tmp - AKA "Assemble" folder, Delta and needs files are brought in to the Assemble folder once downloaded to the Needs folder and then merged (or assembled). Once we have hash successes here we then copy to SMSPKG$.

3. SMSPKG$ - AKA “Content” folder, this is where the content is actually stored for client retrieval after the deltas have been merged and hash has been verified from content in the Assemble folder.

In this Short example from CTM log we will find the Needs folder is referenced first then the Assemble folder. The merge delta operation occurs in the next log entry in the Assemble folder. Both folders are created with a naming convention of PDP****.tmp

What's the difference between "Hash failed for package" and a "PDPHashMismatchEvent"?

"Hash failed for package" is shown when the current version of the ALREADY LOCALLY stored package does not match the stored package hash. If we get this message it indicates for the BDP to NOT download a delta but instead download the full current needed version of the package. Redownloading content is not so much as a "retry" but instead an indicator that we need the full content and not just the deltas.

Example of Hash Failed for Package:

Note the version number above is "3" Before we update the package above from 3 to 4 we rehash the content. The Hash failed for content so instead of grabbing a Delta update we download the full 4 content.

A "PDPHashMismatchEvent" is shown when the content that we downloaded from the DP fails the hash match immediately after the content was downloaded. In the example below we did in fact attempt to redownload the package however the hash once again failed.

Here is an example of "PDPHashMismatchEvent":

We did in fact retry again and failed the hash again at 10:40:51

Why we still do MD5 hash in Config Manager as the SHA1 hash has not been used for content security since SMS 2003 RTM?

We use this value as a quick integrity check as it's very fast. Something to note is that the older MD5 Hashes are always 32 characters in length and corresponds to the "Hash" column in the SQL Database. Newer (as of SMS 2003 SP1 and Config Mgr) and more secure SHA1 hashes are always 40 characters in length and correspond to the "New Hash" column in the SQL DB.

Have you run into an issue where you send out a normal software distribution but the clients never see the pop up balloon in the systray informing them that they have a program that will run?  You know that this should work because you have the “Display Notification” checkbox check in the admin console but no matter what you try the client still will not display the notification in the systray. 

The New Program Notification for clients is controlled by two Policy entries and if either entry is set to FALSE then the new program pop up notification will not show in the systray.  These two Policies are found in the following WMI locations and can be viewed with Wbemtest:

1.  Root\CCM\Machine\Policy, once there then look at the CCM_SoftwareDistributionClientConfig item.  Look at the instances and then choose “Show Mof”.  You will see a box similar to this:

2.  Root\CCM\Machine\Policy, once there then look at the CCM_ClientAgentConfig item.  Look at the instances and then choose “Show Mof”.  You will a box similar to this: 

Notice how one box says True and one says False.  This will cause the Notification to fail.  You can manually change this setting in WMI and it will work for a while but policy will change it back to a False setting causing notifications to once again fail.

Once a Client is in this state it is fairly easy to get them out of it.  Follow the steps below to fix this issue:

1.  Verify that the Display Program Notification checkbox is checked in the admin UI.  If it is not checked, check it and wait for the policy to update on the client.

2. Go into the “Computer Client Agent properties” for this clients parent, choose the Customization tab and make a change to the “Organization Name” field.  Click OK to keep the change.

3. Wait a couple of minutes for the policy provider on the server to write the policy into the database

4. Force the client to refresh policy or wait for the normal policy refresh

That should flip the above bits to True and allow Notifications to happen on the client.  This has been filed as a bug.

One additional note is that this is a Per Site setting so you will need to change this at each site where clients are having the issue.  Making the change at the central site will not fix the problem.  You can use the console connected to the central site to make the change at each site but you will need to allow time for the changes to flow from the central site to the child sites.  I would recommend that you make the change at each site and then let the changes flow up to the central site.

The way Software Updates in ConfigMgr work is that the Central site syncs with WSUS and pulls in the update data into various CI_ tables. That in turn triggers those updated data objects to be sent down the hierarchy to child sites. So the child sites do not sync directly with their WSUS servers but instead inherit the software update data from the Central (their local WSUS servers are still used by their clients for scanning though). This is also why only the Central has the option to 'Run synchronization' on the Updates Repository context menu. These Software Updates can also be linked to other data items, for example updates they rely on, or updates they supersede, or are superseded by etc. In other words there can be multiple interdependencies involved.

New updates arrive at the child through the regular site replication data processes and Replmgr moves them to objmgr.box\incoming for processing. In simplified terms the .cid files have information on an update, for example a Windows Defender signature update, or a SQL fix, or Win2003 update etc. The SDM files are xml data files that have the information linking updates with other data. For example, updates superseding another, or that rely on another, or bundles of updates. You can see the data by opening these files in notepad.

You may see a great many .sdm, or .cid etc. files processing through in the objreplmgr.log. For example, when a new .cid arrives its object data is inserted into the db and the various relationships are checked. If a related bit of data is missing the CI insertion is rolled back and file goes into retry. The idea is that as more data arrives it fills the holes until the CIs can be inserted on retry. It's not unusual to see stacks of retrying files, and it can take a *long time* before they all process through (think in terms of several hours, or days for the initial data transfer).

Here's a .cid at a child site failing and going to retry:

Referenced configuration items are not available yet: https://schemas.microsoft.com/systemsmanagementserver/Site_9D7E5B47-34D4-4F30-B8B6-DCEE435896D6/SUM_424b67ab-ad7c-4501-ad67-c6e23bf2861e/2(2)(6); Failed to insert Object bb62de3b-38c5-409d-8c26-dacb3d91e9ae from replication file c:\CM07\inboxes\objmgr.box\INCOMING\Retry\ORG_24277.CID.

So this tells us that object bb62de3b-38c5-409d-8c26-dacb3d91e9ae from file ORG_24277.CID (ORG being my Central site) couldn't get into the db because it relies on the object 424b67ab-ad7c-4501-ad67-c6e23bf2861e(/2 means version 2)

which is not yet in the db.

If we run the SQL query below at the Central site we can see this is a bundle of updates:

select * from ci_configurationitems where CI_Uniqueid = 'bb62de3b-38c5-409d-8c26-dacb3d91e9ae'

Looking at the xml data of the SDMPackageDigest column will tell you more about the updates. I can see that bb62de3b-38c5-409d-8c26-dacb3d91e9ae is really an update to 424b67ab-ad7c-4501-ad67-c6e23bf2861e and it also supersedes that object , so I would think that the 424b67ab-ad7c-4501-ad67-c6e23bf2861e object needs it to be there in order to flag it as superseded.

The files cannot keep retrying forever, so if after 100 retries the CI still cannot be added then it goes into 'bad', with a log entry like this:

Replication file c:\CM07\inboxes\objmgr.box\INCOMING\Retry\ORG_21864.CID has been retried 100 times and has reached the maximum retry limit, give it up

Once the other data actually shows up and gets processed into the database and we then retry the failed update above it does process correctly. Here is the log file:

Processing replication file c:\CM07\inboxes\objmgr.box\INCOMING\Retry\ORG_24277.CID. Successfully inserted Object bb62de3b-38c5-409d-8c26-dacb3d91e9ae from replication file c:CM07\inboxes\objmgr.box\INCOMING\Retry\ORG_24277.CID. Successfully updated CIXML body for CI 424b67ab-ad7c-4501-ad67-c6e23bf2861e Successfully processed Object bb62de3b-38c5-409d-8c26-dacb3d91e9ae

Let’s take a closer look at this object with the SQL query below.

select CI.CI_UniqueID, UCI.CI_ID, UCI.BulletinID, UCI.ArticleID, UCI.RevisionNumber,CI.ModelName, CI.IsBundle, CI.IsHidden, CI.IsTombstoned, CI.IsEnabled, CI.IsExpired, CI.sdmpackage_id, CI.DateLastModified as CIDateLastModified,

CISDM.SDMPackage_ID, CISDM.SDMPackageName, CISDM.DateLastModified as SDMDateLastModified

from CI_UpdateCIs as UCI

Join ci_configurationitems as CI on UCI.CI_ID = CI.CI_ID

Join ci_sdmpackages as CISDM on CI.sdmpackage_id = CISDM.sdmpackage_id

where ci.CI_Uniqueid = 'bb62de3b-38c5-409d-8c26-dacb3d91e9ae'

It’s MS09-002, KB number 961260. You won’t always get a KB article that get returned. It could be part of a bundle, a hidden update, an expired update, or something else. The point is that with the above queries you should be able to link this together and get an idea of what the object is.

Troubleshooting

So a child site is missing updates in the UI. We need to determine whether the problem is that the child sites never received the updates, or that it did receive them but cannot process them. Not always an easy question to answer, but here are some points to consider when looking at the child site:

1. Looking at objreplmgr.log at the child site. Are different updates processing through OK? Software Updates replicates vast amounts of data, especially when a child site is added and first receives all the updates data (I've seen it take 2 days to send and process it all!). You may just need to be more patient.

2. Also, a .cid may be retrying for perfectly legitimate reasons, i.e. it is waiting for more data to arrive. So a retrying cid is not indicative of a problem per se.

3. Check the log for patterns; is it the same .cid files persistently retrying again and again over a long period of time when other data has processes through OK?

4. Is objreplmgr.log not doing anything, in which case it may be the processing has finished, or data never arrived, or the 100 try limit is reached and the .cid files have gone bad. So do check the bad folder.

5. Are there many retrying or bad .cid files at the child? This should tie up with the log, and just to stress the point, are the same files repeatedly retrying?

So let's say you find there are a number of .cid files in the ..\inboxes\objmgr.box\incoming\retry folder on the child site, and the log shows them retrying over and over again without success. As we saw earlier ObjReplMgr.log should tell you why it does not like them, along the lines of :

1. Processing replication file ... in retry.

2. Referenced configuration items are not available yet...

Now that could mean either:

1. Related CI_ConfigurationItems have not yet arrived at the child site.

-OR-

2. Data for the associated SDMPackage is incorrectly flagged and does not show as 'IsDeleted = 1'. As such the child site is trying to locate non-existent CI_ConfigurationItems linked to that SDMPackage (which the .cid links to).

There are really two methods to fix the above issues:

Resend all updates. This can be done by dropping a <childsitecode>.sha file into the Central site objmgr.box folder. This replicates *all* the CI data back down so that should fix any missing updates. However, this does mean a lot of data will be re-sent, most of which will be unnecessary. I do mean an awful lot. Plus it make take a very long time before you know if it worked or not. When I ran this test in my lab 93,000+ objects were sent down to the child site. The number depends on the number of items you are syncing with MS Update. I call this the Shot Gun approach. While it does work there is a lot of unneeded data sent down.

Resend just the missing updates. Individually update the DateLastModified on the specific CI_ConfigurationItems at the Central site. This is a more granular approach; by modifying this date it will cause just that record to resend. Of course you must identify the correct row by its ci_uniqueid for this to work. So let's say we have a .cid failing to insert and the log tells us it is because the referenced configuration items are not available yet:

https://schemas.microsoft.com/systemsmanagementserver/Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_5ad7a514-0e96-499c-b0e2-41e86b742ddd/1(1)(6);https://schemas.microsoft.com/systemsmanagementserver/Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_c7f8ad7a-6530-4109-a57a-996548d564d9/1(1)(6);https://schemas.microsoft.com/systemsmanagementserver/Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_e1288ee2-7d60-4045-bde0-46b68be56cea/1(1)(6);

Those are 'missing' entries this new update is expecting to be present (but aren't). So check they really do not exist at the child. Note that these ids are taken from the above log entry, with the site specific GUI ('Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_' in this case) chopped off. Run the query below at the child site to verify that the entries do not exist and then run the query at the central site to verify that the entries are there.

Select * from ci_configurationitems where ci_uniqueid in ('5ad7a514-0e96-499c-b0e2-41e86b742ddd', 'c7f8ad7a-6530-4109-a57a-996548d564d9','e1288ee2-7d60-4045-bde0-46b68be56cea')

If they exist at the central we can use the query below to update the time value on them which will cause us to resend them to all child sites:

Update ci_configurationitems

set datelastmodified = getdate()where ci_uniqueid in ('5ad7a514-0e96-499c-b0e2-41e86b742ddd', 'c7f8ad7a-6530-4109-a57a-996548d564d9', 'e1288ee2-7d60-4045-bde0-46b68be56cea')

See if they process through at the child. If not why not? Perhaps they have a further dependency missing which you need to repeat this process for. If they exist at Central site and you resend and they should process OK, then the retrying .cid should as process correctly and disappear from the retry folder.

When the problem remains?

If the above (including a .sha as a Shot Gun approach) does not work then things can get nightmarish as untangling the problem can be horrible. However, the cases I've had (so far) that the above did not fix were solved as follows:

It may be that these referenced CIs don't even exist at the Central! So the child site has an update that relies on another update that does not exist at the Central. That does not make sense until you look at the SDMPackage. As mentioned

earlier this ties together updates, and it may be that an SDMPackage is flagged as 'IsDeleted' at the Central but the child site missed this fact and still has the SDMPackage as an active one (IsDeleted = 0). So the Central never worries about

these referenced CIs because they are referenced from a dead SDMPackage, but the child site thinks it is active so on object insertion the SP follows the links to these other CIs (which don't exist). So presuming the earlier query shows the referenced CIs do *not* exist at the Central then we then need to compare the SDM entries at the Central and child (plus any sites in between). Use the same ids (but including the site part) to check the SDMPackageName:

SELECT * FROM ci_sdmpackages where SDMPackageName in ('Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_5ad7a514-0e96-499c-b0e2-41e86b742ddd','Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_c7f8ad7a-6530-4109-a57a-996548d564d9','Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_e1288ee2-7d60-4045-bde0-46b68be56cea')

Compare the results from running the above at the Central and the child, in particular check the 'IsDeleted' value. Be careful as a row might look the same but be a different *version*. In other words SDMPackageName is not unique, but

SDMPackageName & SDMPackageVersion together are. For example at the child site we see:

SDMPackageName	SDMPackageVersion	SourceSite	IsDeleted	IsDigest	DateLastModified
Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_5ad7a514-0e96-499c-b0e2-41e86b742ddd	3	CNT	0	1	14/05/2008 03:11

...but at the parent site we see:

SDMPackageName	SDMPackageVersion	SourceSite	IsDeleted	IsDigest	DateLastModified
Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_5ad7a514-0e96-499c-b0e2-41e86b742ddd	3	CNT	1	1	26/06/2008 14:18

Note the IsDeleted value is 0 at the child and is 1 at the parent. Somehow the child site 'missed' updating these entries so we still check them. The real problem then is not with other missing configuration items then, but rather with SDMPackages not being correctly flagged as deleted. If the SDMPackage details are different then there is little point re-replicating them from the Central as that does not update them. You need to manually fix the IsDeleted values by running the SQL query blow at the *child* site:

update ci_sdmpackages

update ci_sdmpackages

set IsDeleted = 1

where SDMPackageName = 'Site_E667A12A-772A-4896-9B46-A2D496CA6880/SUM_5ad7a514-0e96-499c-b0e2-41e86b742ddd'and SDMPackageVersion = '3’

Once the tables are corrected the retry file should go back through (if it has gone bad in the meantime drop it back into retry, or resend it from the Central with a date change on the row).

I ran into an issue where a customer needed to move the WSUS Database to a different SQL server.  In my research I found most of the information below.  In testing I added a few pieces to it since my customer was using a remote SQL server.  To move your WSUS Database to another SQL  server just follow these steps, this should work with SQL 2005 or SQL 2008:

1. In the Services tool Right-click IIS Admin Service, and then click Stop.  It will stop other services (WWW Publishing, Windows Remote, and HTTP SSL).

2. In the Services tool, Right-click Update Services, and then click Stop.

3. On the old SQL server, DETACH the SUSDB database.  You can do this by right clicking the SUSDB, choosing Task and then choose detach.  You get the "Detach Database" wizard.  You should be able to just choose "OK" and it will start the detach process.  You may need to choose the "Drop Connections" box.

4. Copy the database files (MDF and LDF) from the old SQL server to the new SQL server. (Make a backup copy of these files as well.)  Most of the time these files will be in the MSSQL\Data directory.

5. Attach the database files as SUSDB to the new SQL server.  Right click Databases and choose Attach.  Point to the place where you copied the files and choose "OK".

a. Verify permissions on the SQL Server instance. In SQL Server Management Studio, open the instance and select Security, then Logins. The NT AUTHORITY\NETWORK SERVICE account should be listed as a login. If not listed, add the account as a login.  If the SQL server is a remote box then add the WSUS server's machine account to the permissions.

b. Verify permissions on the database. Right-click the database, select Properties and then click Permissions. The NT AUTHORITY\NETWORK SERVICE account should be listed as a login. If not listed, add the account as a login.  If the SQL server is a remote box then add the WSUS server's machine account to the permissions.

c. Verify members of the webService role. Under the WSUS database, select Security, select Roles, select Database Roles, then right-click webService and select Properties.  The NT AUTHORITY\NETWORK SERVICE account should be listed as a member of this role. If it is not, it should be added.   If the SQL server is a remote box then add the WSUS server's machine account to the permissions.

6. Back on the WSUS server, open the registry editor: Click Start, click Run, type regedit, and then click OK.

7. Browse to HKLM\SOFTWARE\Microsoft\UpdateServices\Server\Setup\SqlServerName, and in the Value box, type [ServerName]\[InstanceName],and then click OK. If the instance name is the default instance, then simply type [ServerName].

8. Click Start, point to Programs, point to Administrative Tools, and then click Services.

9. Restart the following services:   IIS Admin, HTTP SSL, WWW Publishing, and the Updates Services.

10. To verify that everything is working run the Update Services Console.

Run the following SQL query in against the SMS Database:

select v_FullCollectionMembership.CollectionID As 'Collection ID', v_Collection.Name As 'Collection Name', v_R_System.Name0 As 'Machine Name' from v_FullCollectionMembership
JOIN v_R_System on v_FullCollectionMembership.ResourceID = v_R_System.ResourceID
JOIN v_Collection on v_FullCollectionMembership.CollectionID = v_Collection.CollectionID
Where v_R_System.Name0='ClientMachineName'

You will need to replace ClientMachineName with the name of the Client Machine in question.

Here is the output of SQL when I ran the query for one of my clients:

Additionally, you can also make a Custom Report to get this information if you intend to use this frequently:

The SQL Statement For this Report would be as follows:

select v_FullCollectionMembership.CollectionID As 'Collection ID', v_Collection.Name As 'Collection Name', v_R_System.Name0 As 'Machine Name' from v_FullCollectionMembership JOIN v_R_System on v_FullCollectionMembership.ResourceID = v_R_System.ResourceID JOIN v_Collection on v_FullCollectionMembership.CollectionID = v_Collection.CollectionID Where v_R_System.Name0=@Comp

Click on Prompts while providing the SQL Statement, and Create a new prompt named 'Comp' without the quotes. Provide a SQL Statement for the prompt as follows:

select Name0 from v_R_System

Make a backup before you try this to be on the safe side.  All my statements below reference a 7 in the name, that’s because once I figured out how to clean it out I added it all back in again to verify my tests so it changed the table name.  Just replace the 7 with a 6 or whatever your number is and you should be good to go.

1. Stop the SMS_Executive and SMS_Site_Component Services on the site with the Database that has the issue.

2.  Delete the entry out of the wbem repository.  Use wbemtest and connect to root\sms\site_sitecode.  Once connected click on the Enum Classes button and then find the class that you need to remove (in this case it was called SMS_R_STRMetrics) and highlight like this screen shot:

Next hit the Delete button and that should remove it

3.  Verify the name of the table that the custom architecture is in.  For me it is called Cust_Arch_7_Disc.  For you it is most likely Cust_Arch_6_Disc.  Once you have the table name then you need to drop the table using this SQL command:  Drop table Cust_Arch_7_Disc

4. Next we need to do the same thing with the view.  Mine was called v_R_Cust_Arch_7.  Once you get that view name then drop it using this SQL command:  Drop view v_R_Cust_Arch_7

5. Now is where the fun comes in.  In my tables I had a reference to a table and it would not let me delete the entries related to the Custom Architecture until I cleaned that out.  Here is more information.  I was trying to run this SQL command:  delete from DiscPropertyDefs where DiscArchKey = '7'.  When I run this command I get this error: 

Msg 99951, Level 16, State 1, Procedure DiscPropertyDefs_del, Line 1

Cannot delete row because referenced table exists in database.

Msg 3609, Level 16, State 1, Line 1

The transaction ended in the trigger. The batch has been aborted.

If you run a Select * from DiscPropertyDefs where  DiscArchKey = '7' then you will see this in the results:

It is those entries in the ArrayTableName that is causing the issue.  Run this SQL command to fix that:  update DiscPropertyDefs set ArrayTableName = '' where DiscArchKey = '7' Once this complete do another Select * from DiscPropertyDefs where  DiscArchKey = '7' to verify that all rows in the ArrayTableName column are blank.  Once that is the case then you are ready for the next step.

6.  Run this SQL query to clean up the DiscPropertyDefs table:  delete from DiscPropertyDefs where ArrayTableName = '' and DiscArchKey = '7’

7. Run this SQL query to clean up the DiscoveryArchitectures table:  delete from DiscoveryArchitectures where BaseTableName='CUST_ARCH_7_DISC'

8. Run this SQL query to clean up the DiscItemAgents table:  delete from DiscItemAgents where DiscArchKey = '7’.  You may get a 0 rows affected on this statement as there is a trigger when a delete statement is issued on the DiscoveryArchitectures table that will delete entries in this table as well.  Go ahead and run the delete statement on this table just in case.

9. Restart the SMS Services on the box

10. In the console delete any collections and queries that referenced this custom architecture.

If you have looked at your AIUpdateSvc.log file lately you may have notice a few errors in there showing that you are not syncing with the System Center Online Catalog.  The errors may look something like this:

In Service Pack 2 for CM07 we removed the need for customers to have a certificate to connect with System Center Online.  This was only partly true.  We still require an internal certificate to connect.  This certificate is built into Config Manager and is require to verify that it is a valid Config Manager Site that is connecting to us to upload and download information.  In late April this internal certificate expired and that is causing the error shown above.  Take a look at KB article 2483225.  This article will provide more information about the error and also include a link to a hotfix that will take care of this issue.  Once the hotfix is install I had to restart all my SMS Services and then the next sync cycle connected correctly.

Since most folks create the AI sync point and then forget about it this is something that can go undetected for a while.  Take a look at your log as soon as possible to see if you are having this issue.  Everyone should run into this when the certificate expires.

On Server 2008/Vista and Server 2008R2/Windows 7 machines you will not find the patch information in Resource Explorer like you will for other OS’s.  This is due to a change in the way that those OS’s store their patch information.   Let me explain more.

Remember that Config Manager only gathers this information from WMI and then carry’s that information back to the database where you can then use resource explorer to see it.  With XP SP3 Windows stores the patch information in the Add Remove section of WMI.  You can view that by using wbemtest.  Connect to root\cimv2 and then run this query:   Select * from Win32Reg_AddRemovePrograms

As you can see in the above screen shot that WMI value has a lot of the patches stored there as well as installed programs.  Config Manager uses the information in the SMS_Def.mof file to collect this information automatically and it then appears in the Resource Explorer for each client.

In Server 2008 (Win 7) the patches are no longer stored in the Add Remove section of WMI.  They are in the Win32_QuickFixEngineering section.  In Wbemtest you can run this query:  Select * from  Win32_QuickFixEngineering

You then get a list of all the hotfixes that have been installed on that Server 2008 (Win 7) box.  You can also collect this same information via the SMS_Def.mof file.  We have that section in the mof already but it is turned off.  Here is what it looks like in the default SMS_def.mof file:

//===================================================================
// W A R N I N G        W A R N I N G        W A R N I N G
//   DO NOT: Enable the Win32_QuickFixEngineering class unless you have
//         installed the QFE for Q279225.  Enabling this class without
//         the QFE will result in inventory cycles taking a very long
//         time to complete on the client and the WINMGMT service
//         using 99% to 100% CPU time and leaking memory.
//
//===================================================================
[ SMS_Report     (FALSE),
  SMS_Group_Name ("Quick Fix Engineering"),
  SMS_Class_ID   ("MICROSOFT|QUICK_FIX_ENGINEERING|1.0") ]
class Win32_QuickFixEngineering : SMS_Class_Template
{
    [SMS_Report (FALSE)     ]
        string     Caption;
    [SMS_Report (FALSE)     ]
        string     Description;
    [SMS_Report (FALSE)     ]
        string     FixComments;
    [SMS_Report (FALSE), key]
        string     HotFixID;
    [SMS_Report (FALSE)     ]
        datetime   InstallDate;
    [SMS_Report (FALSE)     ]
        string     InstalledBy;
    [SMS_Report (FALSE)     ]
        string     InstalledOn;
    [SMS_Report (FALSE)     ]
        string     Name;
    [SMS_Report (FALSE), key]
        string     ServicePackInEffect;
    [SMS_Report (FALSE)     ]
        string     Status;
};

Note the warning at the top.  If you have older OS’s like Windows 2000 then make sure you have that Hotfix installed before turning this on for those clients.  Once you do get it turned on and clients start sending in the information you will see it in the Resource Explorer like this:

This is on my Windows 7 box.  The hotfixes are listed there now.  All you need to do is change all the FALSE to TRUE in the above section of the SMS_Def.mof file on each site and once the clients get the policy change they will send in the new hotfix information.

When the client finds the SLP he sends an LDAP query to the SLP service running on the IIS server hosting the SLP.  You can run this same query by using the commands below in your IE Browser:

Find a Site:
https://<SLP Server Name>/sms_slp/slp.dll?site&ip=12.19.86.0

Find a Management Point (MP):
https://<SLP Server Name>/sms_slp/slp.dll?MP&ip=12.19.86.0

You will need to replace the ip= part with the IP Subnet that you are looking for.   Each of these can be added to the URL separated by '&'.

ad= <Active Directory site name>
ip= <IP Subnet>
ir= <IP Address>

When running the above in IE you should get back something like this:

The MP Query will return a list of the MP’s for the client:

This information can be very helpful when troubleshooting why a client can’t get policy or why the client is not finding a MP.  Most of the time it is a boundary related issue but it could also be an issue with the MP or with SQL.