Troubleshooting the Data Warehouse: Management packs are stuck in “pending association”


This is the latest in “Troubleshooting the Data Warehouse” series. The goal of this series is to not only help you troubleshoot specific issues you may be experiencing but also teach you more about the data warehouse. For a complete list of posts in the series, check out Troubleshooting the Data Warehouse: An overview.



The symptom


After registering Service Manager to the Data Warehouse and several (4+) hours have passed some management packs are still stuck in “pending association” state. You can check this by opening the Console, clicking Data Warehouse > Data Warehouse Jobs > MPSync Job, and then click Details from the Tasks Pane


The troubleshooting steps


To troubleshoot this issue, investigate the following things in order.

1. Review each batch ID for the “stuck” MP via the MPSyncJob dialog box

In the MP Sync Job dialog, click on the Management Pack column name to sort the list according to Management Pack name.  Find those management packs with Pending Association status, check if in the later batch, the Pending Association management pack turns to Associated.

For example in the following figure I’ve highlighted:

·         In batch 136, Management Pack Microsoft.SystemCenter.ConfigurationManager is in Pending Association

·         In batch 207, Management Pack Microsoft.SystemCenter.ConfigurationManager is in Associated

This means the management pack is associated properly in batch 207 even though it ran into an error in batch 136. Because it recovered in batch 207, the management pack is correctly associated and the sync completed successfully. So even if a management packs is Pending Association in one batch, if in a later batch it is successfully Associated, then the management pack is correctly and completely deployed and synchronized.

If in the MP Sync Job dialog, the Pending Association status for a management pack repeats for every batch, you’ll need to dig a bit deeper to figure out what causes this management pack to fail to associate.


2. Look for deployment failures in management packs which this management pack depends on

Click on the Data Warehouse > Management Packs and then click the Deployment Status column header in the main pane.  If you see any management pack whose deployment status is Failed and some are Not Started this is usually due to a management pack dependency. Because management packs can depend on others, any failure can have a domino effect and cause other management packs not able to deploy. Any impacted management pack will have a status of Not Started (it’s not Failed, but because another did Fail it hasn’t yet started).


3. Find the deployment failures in the event log

 Go to the Data Warehouse Management Server, open the Operations Manager Event log, filter the event log to the events whose Event Source is Deployment and Event Level is Warning or Error. 

If there is error message similar to the below highlighted text you’ll need to unregister the Data Warehouse from Service Manager, reinstall the Data Warehouse and then re-register Service Manager to Data warehouse.

              Deployment Execution Infrastructure has retried the maximum number of times and is giving up on this execution step. 

       MP Element ID: DerivedManagementPack.SystemDerivedMp.ServiceManager.ActivityManagement.Library.Datawarehouse

       MP name: ServiceManager.ActivityManagement.Library.Datawarehouse

       MP version: 7.0.5826.0

       Operation: Install

                Error message: Cannot find resource with ID TransformActivityStatusResource,


Comments (3)
  1. Aleksandr says:

    Tell me please, Why is the problem that is not synchronized to the SCSM. In the list of tasks Data Warehouse Jobs in MPSyncJob appears that some of the Management Pack are able Pending Association c Batch ID 36. Others have a Management Pack Batch ID 58. Their condition and Associated Imported. Already spent several test installations, but it gives you the same thing. English SCSM placed and synchronized without any problems.

    In the logs was recorded following error:

    Error importing solutions. Error message: Management Pack [Microsoft.EnterpriseManagement.ServiceManager.Connector.AD, d43c3091-62c2-6404-607d-4376e592a89b] already imported.

    Management Pack [Microsoft.EnterpriseManagement.ServiceManager.Connector.Sms, f772aa89-b934-2fac-4f37-5e0165d390ec] already imported.

  2. Bryan DeYoung says:

    I wanted to extend this blog with a bit of information that may save folks a good bit of time and confusion when deploying management packs containing reports to the Service Manager system.  Our team has a fairly complicated set service process/model requirements that to implement requires an on-going development process extending and building on top of the out-of-the-box Service Manager system.  One of those necessities is that we needed to modify the out-of-the-box reports.  We wanted to leverage some of the nice work that the Service Manager product team did for the reports in the system.  So we elected to unpack the Reports Library management pack bundle that installs on the RMS and migrate the reports into a management pack that we can manage, seal and deploy.  This portion of the process was fairly simple and straight-forward (primarily a copy-and-paste effort).

    The major learning curve came on the deployment portion of the project.  And this is where I would like to shed a little light on a few considerations your team should remember before deploying.  Abiding the joke that developers only do things "by design", the lessons learned here were absolutely mistakes that I made and cost me a number of hard lessons learned.   Each of these mistakes can cause the deployment process to fail or to be confusingly imcomplete.  So, here they are:

    1) When you import a management pack containing report defitions into the RMS, the synchronization between the Data Warehouse and the RMS is not automatically kicked off.  The job responsible for synchronizing the management packs can be found under the "Data Warehouse" tab in the "Data Warehouse Jobs" folder and is called "MPSyncJob".  You can have this job kick off immediately by selecting the job (if it is in a status of "Not Started") and then selecting "Resume".  Bear in mind that this job will be slower to begin and complete its process if any of the other jobs (Extract/Transform/Load) are already running.

    2) A lot of good solid information is provided in the "Operations Manager" Event Log on the server hosting the Data Warehouse.  For your first go around on a deployment, I recommend that you watch the Event Log on the Data Warehouse server during the import/upgrade/install process so that you can become familiar with the steps or get a bird's eye view of any errors happening during the deployment.  Otherwise, you may be waiting a long time for the reports to show up on the report server or in the console only to find that errors caused the deployment to fail and you waited unnecessarily.

    3) The management pack deployment process/script resource deployment logic expects the encoding on any script files you pack into a MPB file to be ANSI encoded (that's "Western European (Windows) – Codepage 1252" in VS-speak).  Visual Studio will default to UTF-8 encoding for example if you create a text file/.sql file from the IDE.  This constraint does not seem to apply to other resources like the report .rdl files…..just the script/text files.  (Refer to #2 above as well)

    4) Absolutely, positively verify that the script in any text/.sql file that will be part of the management pack Data Warehouse script definitions executes on the SQL Server before packaging it in the MPB file and deploying.  A failed script execution in the Upgrade/Install portion of a management pack report deployment can cause an inconsistent state in the DWStagingAndConfig database that will render the MPSyncJob helpless (i.e.  it may cease to notice management pack changes in the RMS and require you to reinstall the Data Warehouse to address the issue).  (Refer to #2 above as well)  

    5) Absolutely, positive verify that any report/.rdl files execute against the SQL Server reporting server before packaging those in an MPB file.  A failed report upgrade/install can cause a half-mast deployment whereby portions of the deployment process complete and others do not.  This can be confusing and cost time in trying to discover where the actual issue was.  (Refer to #2 above as well)

    6) This is not specifically related to Service Manager report deployment but is a trinket that I discovered as a part of SSRS report development.  It is not uncommon for report parameters to have available and default values that are derived from stored procedures in the Data Warehouse (i.e. datasets).  A report parameter of the type "Text" can have a maximum single column character length of 2033 characters.  This popped up as a limitation for the reports in the Service Manager context because the reports utilize a stored procedure dbo.ReportStringGet to get display strings as an XML structured string from the DWDataMart.  These report strings are defined in the management pack (<ReportStrings>) and are used for labels, headers etc…  As soon as I defined too many <ReportString> definitions for one report in the management pack, the XML string I was getting back was truncated at 2033 characters and giving me an invalid XML document that could not be parsed by custom code.

    I hope this helps those of you out there working to get custom reports up and running in the Service Manager system.  When all is said and done, the report deployment process created by the Service Manager product team is a very nice end-to-end deployment solution.  It's awesome to watch it bolt all of the parts together from the import to synchronization to installation and for you to suddenly have reports showing up in the console.  

    Feel free to contact me with questions about the above noted items at  Thanks to the Service Manager product team for all of their help and support along the way.

  3. Bill says:

    You should also ensure that the Service Center Management service is running on the data warehouse server.  This service was somehow stopped on our installation and produced the same symptoms.  Starting the service 'unstuck' the process.

Comments are closed.

Skip to main content