Picture the following:
You upgrade an SMS 2.0 Child Site server to SMS2003, this sites Parent Site server is already SMS2003. A few days later you notice on the Parent Site server that there are still SMS 2.0 components present in the Site Status \ Site Component list for the Child site.
Two Components that might be shown are:
LICENSE_METERING (Part of Software Metering)
SMS_NT_LOGON_SERVER_MANAGER (Part of SMS Logon Points urgh)
Opening an SMS Administrator Console on the Child Site server shows that these components are no longer listed under it's Site Status \ Site Component list.
Several days after the upgrade, these components are still listed on the Parent, but no new status messages have arrived since the upgrade took place.
To summarise: The Parent Site server shows Components that are definately no longer present on the Child Site Server. And, the last message date for the offending Components have not changed since the upgrade date, confirming that the Child Site server is no longer replicating Status Messages up to the Parent for this Component.
The problem is that the Summarizer (or whatever mechanism would do this) on the Parent has not removed the entries in the Summarizer_Components and Summarizer_ComponentTallys tables. Why this has not happend I cannot determine. The Parent is pretty much up to date on everything else about this newly upgraded SMS 2.0 site, and the site itself is fully operational with no errors being reported.
Before you begin working magic on the SMS Database, ALWAYS make a backup as your “Get out of Gaol free card”.
Ideally you should take the SMS Backup and restore it in to a Dev environment then perform these steps before taking the proverbial blade to the Prod environment instance.
If at any time you encounter any issues I’d suggest stopping, reviewing what you are doing and if it makes no sense then thinking twice about proceeding. Although these steps in themselves are not adversely destruction, the SQL Delete clause is quite powerful and can be used to great effect in hosing an SMS Site server down.
Use at your peril. Use only if you are comfortable with everything discussed below, and feel confident that your problem is identical to that described in the introduction above.
Let’s start with the procedure.
We will remove the SMS_NT_LOGON_MANAGER component entry from the SUMMARIZER_COMPONENTS and SUMMARIZER_COMPONENTTALLYS tables on the Parent Site server for the Child Site server.
1. Open SQL Query Analyzer, and connect to the SMS database on the Parent Site server
2. Run the following Query, and record the details in Notepad:
Select sitecode, machinename, componentname, componentdataid from summarizer_components where machinename = ‘<SERVER>’ and sitecode = ‘<SITECODE>’
<SERVER> and <SITECODE> should be replaced with the Child Site servers identity information
3. Note the COMPONENTDATAID listed for the SMS_NT_LOGON_SERVER_MANAGER component
4. Now run the following query to determine that the COMPONENTDATAID value exists in the SUMMARIZER_COMPONENTTALLYS table:
Select * from SUMMARIZER_COMPONENTTALLYS where componentdataid = ‘<COMPONENTDATAID>’
5. Before you continue beyond this point, are you getting the right information back, are you ready to perform deletions?
6. Run the following query to delete the SMS_NT_LOGON_MANAGER component from the SUMMARIZER_COMPONENTTALLYS table on the Parent Site server:
Watch for how many rows are deleted (16 rows from my experience)
Delete from SUMMARIZER_COMPONENTTALLYS where componentdataid = ‘<COMPONENTDATAID >’
7. Now, Delete the COMPONENTDATAID for the SMS_NT_LOGON_SERVER_MANAGER component from the SUMMARIZER_COMPONENTS table on the Parent Site server:
Watch for how many rows are deleted (1 row from my experience)
Delete from SUMMARIZER_COMPONENTS where machinename = ‘<SERVER>’ and sitecode = ‘<SITECODE>’ and componentdataid = '<COMPONENTDATAID>'
8. Restart the SMS_EXECUTIVE service on the Parent site once you have completed the above steps
9. Perform a refresh of the SITE STATUS \ COMPONENT STATUS
If after performing the above tasks the component is no longer present, then you’ve performed the operations successfully. If not, then I’d suggest restoring the database and retrying (you are doing this in Dev aren’t you?), or having another go with the Select Queries above to determine if the Deleted rows are still present. Also, if these components reappear then it means the Child site is replicating the information back up to the Parent, in which case this article is not the solution for you, and you need to figure out why these components are still present on the Child site.