locked
SQL Server MP Upgrade to Version 6.1.4000.00 Experiences RRS feed

  • Question

  • Hi All,

    I am planning on upgrading the SQL Server MP to the latest March 2011 release so as to enable monitoring of SQL Server 2008 R2 systems and would like to ask forum members how they proceeded in doing this?

    In particular, my issue is with the section of the SQL Server MP guide that addresses the issues of upgrading from an earlier version of the MP as follows:

    "To avoid monitoring noise:

    1. If you are upgrading from a previous version, export and save your current management pack with any customizations so that you can roll back the installation if needed.

    2. Import the library file.

    3. Define Run-As accounts.

    4. Import the discovery file.

    5. Make sure that the required objects are discovered.  In case of security alerts, adjust Run As accounts.  If the list of discovered objects is not as expected, enable or disable discovery for management groups.

    6. Import the monitoring file.

    7. Customize the management pack.

    I understand that in point 1 I would be using the Administration > Management Packs view to export both the sealed SQL Server MP Files as well as my unsealed override MP (xml) file for the sake of re-importing them if I need to roll-back the monitoring configuration to the pre 6.1.4000.00 version of the Management Pack along with our customizations.

    My question is that the above 7 steps make it sound like after exporting the current SQL MP files that I would essentially be starting from scratch as far as SQL server monitoring is concerned -to the point of having to define Run-As accounts for the latest version of the SQL Server MP to use once it is imported.  I may be misunderstanding the process but it seems like "exporting" the original MP files is in effect removing or deleting them from SCOM whereas I was under the impression (misguided perhaps) that exporting an MP (sealed/or unsealed) merely saves it as an XML file to a location on the filesystem as a way to backup the MP but the original sealed MP is still actively a part of the monitoring configuration. 

    I am confused as to why there should be any need to re-defineRun-As accounts  or anything of that sort since I would have thought that the process of upgrading the MP was just a matter of importing the latest version of the SQL.Library.MP followed by the SQL.Discovery.MP and SQL.Monitoring.MP files for both SQL 2005 and 2008 in order to update to the latest version and then perform any overrides to monitoring as required for our environment saving them to our pre-existing SQL overrides MP.

    Part of my concern with the above 7 steps is that implementing it would mean that monitoring of our SQL servers is going to be unavailable for a period which is not ideal and so I would like to hear from others what process they followed to upgrade this MP that minimized the impact of the upgrade.  Is it possible to simply import the files and then deal with any "noise" from the new MPs (especially as regards SQL Server 2008 R2 systems) but at least have monitoring continue as before without having to reconfigure Run-As account etc.  If so, I would prefer that then having to re-invent the wheel entirely. 

    Thanking you for your considered replies,

    Michael

    Sunday, July 10, 2011 9:51 AM

Answers

  • Hi

    There is no point in exporting the sealed Management Packs as this breaks the seal - you won't be able to reimport them and use them:

    http://systemcentersolutions.wordpress.com/2010/04/14/unsealing-sealed-management-packs/

    It is good practice to download the MSFT management packs prior to import so that you can keep a copy of the various management packs.

    Also useful to automate the export of unsealed management packs:

    http://blogs.technet.com/b/jonathanalmquist/archive/2009/03/30/export-a-management-pack.aspx

    SQL Run As Profiles \ Accounts info:

    http://blogs.technet.com/b/kevinholman/archive/2010/09/08/configuring-run-as-accounts-and-profiles-in-r2-a-sql-management-pack-example.aspx

    The one thing to note on the new MP is that it does seem to allow for low-privileged monitoring to a much better degree than previous Management Packs (which effectively required local windows admin & SQL SysAdmin):

    http://technet.microsoft.com/en-us/library/dd767431.aspx

    Cheers

    Graham

     


    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    • Proposed as answer by Vivian Xing Tuesday, July 12, 2011 6:15 AM
    • Marked as answer by Nicholas Li Friday, August 5, 2011 7:37 AM
    Monday, July 11, 2011 11:51 AM
  • exactly, only export the unsealed mp's. The sealed ones are just downloadable. But when just importing one mp its no big worry. As Graham says I also always automate the export (backup) of unsealed mps. You can also implement the unsealedmpbackup management pack from the systemcentercentral site as another example. For the rest that procedure will work.
    Bob Cornelissen - BICTT (My BICTT Blog) - Microsoft Community Contributor 2011 Recipient
    • Marked as answer by Nicholas Li Friday, August 5, 2011 7:37 AM
    Monday, July 11, 2011 12:31 PM
  • Hi Bob and Graham,

    Yes, we are using the export/backup unsealed mp powershell script from the SCOM Unleashed book together with a nightly scheduled task to export the unsealed MPs to disk in order for nightly backup to tape etc.  But even with this I always like to manually export the overrides MP to a location on the RMS where I know I can find it and that it is current - just in case.

    Graham, thanks for the pointer about not trying to export the sealed SQL Server MPs from within the Console to prevent breaking the seal. 

    The usual procedure I follow is to download the Managment Pack .msi file from the catalog site and extract it to a temporary location on the RMS so I can import from disk all the core library, discovery and monitoring MP files that are appropriate.  This method seems to take care of any dependencies.

    Thanks for reminding me of Kevin's SQL Run As Accounts article.  I had read this in-part when it originally appeared and then forgot about it.  I expect it will shed light on the remaining grey areas I still have for this MP.

    Thanks again,

    Michael

    • Marked as answer by Nicholas Li Friday, August 5, 2011 7:37 AM
    Wednesday, July 20, 2011 2:18 PM

All replies

  • always good to at least save your unsealed management packs (by command or export function or unsealedmpbackup mp). That takes care of the overrides.

    Next what I always did was to just import the newer sql mp.
    Depending on the time available to you at the time of import you would either do it step by step as suggested or just import the whole lot of them at once. I dont think I had to first remove the older version (if there is this need it would tell you at the point of import). In any case make sure to after the import check the runas profiles!! Thats the most important at this point as you might get errors otherwise. But in most environments thats a few minutes work if you know certain runas profiles and runas accounts need to run somewhere in order to work.


    Bob Cornelissen - BICTT (My BICTT Blog) - Microsoft Community Contributor 2011 Recipient
    Sunday, July 10, 2011 4:16 PM
  • Hi Bob,

    Thanks for the feedback, it is much appreciated.

    Based on what you have said I will do the export of the overrides MP and of the previous sealed MP files from the console (just in case) and then proceed with importing the latest version of all the SQL MP files via the Import management Packs option as per normal.

    I will talk to my DBAs prior to this to make sure that any SQL server specific service accounts have not changed between the old and new SQL Server 2008 R2 environment or even just to confirm that I have these account details at hand in case  I start seeing security alerts for missing credentials or need to re-enter these in the Run As Profiles.

    Kind Regards,

    Michael

     

     

     

    Monday, July 11, 2011 7:28 AM
  • Hi

    There is no point in exporting the sealed Management Packs as this breaks the seal - you won't be able to reimport them and use them:

    http://systemcentersolutions.wordpress.com/2010/04/14/unsealing-sealed-management-packs/

    It is good practice to download the MSFT management packs prior to import so that you can keep a copy of the various management packs.

    Also useful to automate the export of unsealed management packs:

    http://blogs.technet.com/b/jonathanalmquist/archive/2009/03/30/export-a-management-pack.aspx

    SQL Run As Profiles \ Accounts info:

    http://blogs.technet.com/b/kevinholman/archive/2010/09/08/configuring-run-as-accounts-and-profiles-in-r2-a-sql-management-pack-example.aspx

    The one thing to note on the new MP is that it does seem to allow for low-privileged monitoring to a much better degree than previous Management Packs (which effectively required local windows admin & SQL SysAdmin):

    http://technet.microsoft.com/en-us/library/dd767431.aspx

    Cheers

    Graham

     


    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    • Proposed as answer by Vivian Xing Tuesday, July 12, 2011 6:15 AM
    • Marked as answer by Nicholas Li Friday, August 5, 2011 7:37 AM
    Monday, July 11, 2011 11:51 AM
  • exactly, only export the unsealed mp's. The sealed ones are just downloadable. But when just importing one mp its no big worry. As Graham says I also always automate the export (backup) of unsealed mps. You can also implement the unsealedmpbackup management pack from the systemcentercentral site as another example. For the rest that procedure will work.
    Bob Cornelissen - BICTT (My BICTT Blog) - Microsoft Community Contributor 2011 Recipient
    • Marked as answer by Nicholas Li Friday, August 5, 2011 7:37 AM
    Monday, July 11, 2011 12:31 PM
  • Hi Bob and Graham,

    Yes, we are using the export/backup unsealed mp powershell script from the SCOM Unleashed book together with a nightly scheduled task to export the unsealed MPs to disk in order for nightly backup to tape etc.  But even with this I always like to manually export the overrides MP to a location on the RMS where I know I can find it and that it is current - just in case.

    Graham, thanks for the pointer about not trying to export the sealed SQL Server MPs from within the Console to prevent breaking the seal. 

    The usual procedure I follow is to download the Managment Pack .msi file from the catalog site and extract it to a temporary location on the RMS so I can import from disk all the core library, discovery and monitoring MP files that are appropriate.  This method seems to take care of any dependencies.

    Thanks for reminding me of Kevin's SQL Run As Accounts article.  I had read this in-part when it originally appeared and then forgot about it.  I expect it will shed light on the remaining grey areas I still have for this MP.

    Thanks again,

    Michael

    • Marked as answer by Nicholas Li Friday, August 5, 2011 7:37 AM
    Wednesday, July 20, 2011 2:18 PM