system center operations manager 2007 management pack lifecycle management

1. System Center Operations Manager 2007Management Pack Lifecycle Management

2. Agenda Review stages of the Management Pack (MP) Lifecycle Vendor Management Packs (overrides) Custom Developed Management Packs Information Technology Infrastructure Library (ITIL) processes as they relate to the Lifecycle (Change, Configuration & Release Management) Authoring Tools Version Control Slide Notes: Review the lifecycle of a given management pack, including the methodology and framework necessary to support the foundation of the process. Vendor management packs – review the scope of what it monitors, how to identify the default configuration settings, approach to tuning, etc. Custom developed management packs – understand the requirements, align resources, determine which tools are appropriate for the task, etc. ITIL – Information Technology Infrastructure Library and how ITSM (IT Service Management) is concerned with supporting and delivering IT services it relates to this effort. Understand the authoring tools that are available and which one is appropriate based on the level of development or customization that needs to be performed. Versioning – the fundamental ability to track the changes and releases of a MP over a period of time.Slide Notes: Review the lifecycle of a given management pack, including the methodology and framework necessary to support the foundation of the process. Vendor management packs – review the scope of what it monitors, how to identify the default configuration settings, approach to tuning, etc. Custom developed management packs – understand the requirements, align resources, determine which tools are appropriate for the task, etc. ITIL – Information Technology Infrastructure Library and how ITSM (IT Service Management) is concerned with supporting and delivering IT services it relates to this effort. Understand the authoring tools that are available and which one is appropriate based on the level of development or customization that needs to be performed. Versioning – the fundamental ability to track the changes and releases of a MP over a period of time.

3. MP Development Lifecycle Slide Notes: The following diagram shows the lifecycle of a given management pack or custom rule set. This is displayed to help you understand the basic workflow and the foundation, not to intimidate or scare you. I cannot stress enough the importance of creating your own structured approach to the development and management of MP’s within your implementation of Operations Manager. This lifecycle is applicable if your team is only going to be responsible for working with Vendor provided management packs & overrides, and not developing any custom management packs (some customers draw a line in the sand with the policy “only services or applications that have a vendor provided management pack will be monitored by our team.” This is to be a simple, effective framework and not intended to create additional bureaucracy that impedes progress and alienates your internal customer – the IT service owner or business. I’ll summarize the four stages for you now. Review Phase: Bring in all the relevant role participants to review the scope, expected work tasks and deliverables, and the desired time-lines for this phase. High-level breakdown required to complete this phase are: Review the monitoring requirements/intent for Operations Manager (i.e. the management pack). Establish team membership Prepare the environment (if required) Establish goals, COS, timeline Test in an isolated environment Move to a QA or pre-production environment to validate alerts and actionable nature Tune appropriately based on test results Determine if final results meet scope/requirements established Implementation Phase: Import the MP into production in a controlled manner, begin the evaluation of real-time data collected such as alerts and accurate health model. High-level breakdown required to complete this phase are: Can successfully import the MP Data collected (health model and alert) do not exceed projections. Test alert notification via require channel from the SME/SO – email, pager, connector into a third-party management solution that cuts tickets, etc. Assessment Phase: Conduct any additional fine-tuning of the MP and validation of alert notification paths (alerts are distributed to the right groups/individuals) as this is considered “production” as it passed the Implementation Phase. High-level breakdown required to complete this phase are: Validate results of the alerts generated, verify scope of monitoring against intended targets (servers and/or services), health model is accurate, etc. Validate alert notification paths. Sustaining Phase – Primary goal is to maintain the MP at the appropriate level established, collect feedback on gaps, enhancements, bugs, etc. This information will be used as input into the development of the next release of the MP. Slide Notes: The following diagram shows the lifecycle of a given management pack or custom rule set. This is displayed to help you understand the basic workflow and the foundation, not to intimidate or scare you. I cannot stress enough the importance of creating your own structured approach to the development and management of MP’s within your implementation of Operations Manager. This lifecycle is applicable if your team is only going to be responsible for working with Vendor provided management packs & overrides, and not developing any custom management packs (some customers draw a line in the sand with the policy “only services or applications that have a vendor provided management pack will be monitored by our team.” This is to be a simple, effective framework and not intended to create additional bureaucracy that impedes progress and alienates your internal customer – the IT service owner or business. I’ll summarize the four stages for you now. Review Phase: Bring in all the relevant role participants to review the scope, expected work tasks and deliverables, and the desired time-lines for this phase. High-level breakdown required to complete this phase are: Review the monitoring requirements/intent for Operations Manager (i.e. the management pack). Establish team membership Prepare the environment (if required) Establish goals, COS, timeline Test in an isolated environment Move to a QA or pre-production environment to validate alerts and actionable nature Tune appropriately based on test results Determine if final results meet scope/requirements established Implementation Phase: Import the MP into production in a controlled manner, begin the evaluation of real-time data collected such as alerts and accurate health model. High-level breakdown required to complete this phase are: Can successfully import the MP Data collected (health model and alert) do not exceed projections. Test alert notification via require channel from the SME/SO – email, pager, connector into a third-party management solution that cuts tickets, etc. Assessment Phase: Conduct any additional fine-tuning of the MP and validation of alert notification paths (alerts are distributed to the right groups/individuals) as this is considered “production” as it passed the Implementation Phase. High-level breakdown required to complete this phase are: Validate results of the alerts generated, verify scope of monitoring against intended targets (servers and/or services), health model is accurate, etc. Validate alert notification paths. Sustaining Phase – Primary goal is to maintain the MP at the appropriate level established, collect feedback on gaps, enhancements, bugs, etc. This information will be used as input into the development of the next release of the MP.

4. Methodology & Framework

5. Where to start? Identify ownership for development, review, management, testing, and implementation of Management Packs. Identify roles and responsibilities. Develop the process, build the infrastructure (Dev & QA), documentation, templates, etc. Identify tools to help support the process. Slide Note: Development of the process and the tasks involved will require the infrastructure to support development and qualification, document the process (again – repeatable and consistent), define templates where appropriate, and so forth. Lastly, identify the tools that will help support the process – project based version control system, authoring tools, etc. End by stating that this can be a simple process for IT organizations that do not need to consistently develop custom Management Packs, or full use of the entire lifecycle process for those that do. Slide Note: Development of the process and the tasks involved will require the infrastructure to support development and qualification, document the process (again – repeatable and consistent), define templates where appropriate, and so forth. Lastly, identify the tools that will help support the process – project based version control system, authoring tools, etc. End by stating that this can be a simple process for IT organizations that do not need to consistently develop custom Management Packs, or full use of the entire lifecycle process for those that do.

6. Roles and Responsibilities Service Owner and Subject Matter Expert – develop & evaluate technical accuracy and quality of a MP. MP Development Team – Two or more individuals tasked with managing, developing, testing, and review of Management Packs. Engineering Team – Members who are responsible for the Operations Manager infrastructure. Operations Team – Involved so they have awareness of new monitoring requirements. Slide Note: The Operations Team may not have the time/resources to be fully involved in the process. Therefore it is important that they are kept in the loop throughout the entire process, so communication is important. This is dependant on the environment and their level of responsibilities, as well as if the customer has a dedicated Operations Team. Ideally since they are the first level of support and have an understanding of the behavior patterns of an application/service, their input is valuable.Slide Note: The Operations Team may not have the time/resources to be fully involved in the process. Therefore it is important that they are kept in the loop throughout the entire process, so communication is important. This is dependant on the environment and their level of responsibilities, as well as if the customer has a dedicated Operations Team. Ideally since they are the first level of support and have an understanding of the behavior patterns of an application/service, their input is valuable.

7. Relationship Between Roles & Phases Slide Notes: Within each of the roles of the process, participants have a level of responsibility for particular tasks. Some roles may be engaged throughout all phases, as you can see by the MOM Engineering Team, while others may only be involved in one phase such as the MP Development Team. This diagram provides you with an insight into the relationships between the roles defined and phases of the lifecycle.Slide Notes: Within each of the roles of the process, participants have a level of responsibility for particular tasks. Some roles may be engaged throughout all phases, as you can see by the MOM Engineering Team, while others may only be involved in one phase such as the MP Development Team. This diagram provides you with an insight into the relationships between the roles defined and phases of the lifecycle.

8. Ownership of process Consider a central team within the Engineering team to be responsible for the process. In the enterprise scenario, this has been a common approach. Effective when IT is structured like silo for each service/application. Ensures you coordinate with them to identify monitoring scope (functional spec) and as they develop, you manage it as a project. Slide Notes: I must underscore the importance of identifying responsibility and ownership in order for this to be successful. Too often have I witnessed customers which I have engaged with, struggle to manage the effort. By going through this exercise in your organization, you can get your “hands around it” and effectively manage the process.Slide Notes: I must underscore the importance of identifying responsibility and ownership in order for this to be successful. Too often have I witnessed customers which I have engaged with, struggle to manage the effort. By going through this exercise in your organization, you can get your “hands around it” and effectively manage the process.

9. Methodology Author the Management Pack or tune vendor provided MP with custom MP (includes the overrides). Test the MP in a lab environment and tune appropriately. Export when complete. Import into production and monitor closely. Fine-tune as necessary. Slide Note: We have two paths to follow depending upon the requirements for monitoring the system, application, or IT Service. If it is a commercially available solution, then we would determine if the vendor/partner provides a Management Pack for Operations Manager. However, if this is an in-house developed application, then it would require custom development of the MP. It is important that when undertaking the responsibility of developing a Management Pack, you need to ensure you understand the requirements from the business and the application/service owner in order to model it correctly. When we talk about the model, we are referring to the health model (this is defined by the application/service owner and not the business). Another important point when developing a management pack are special requirements around security delegation be required, user experience, notifications, reporting, etc. The last two bullet points fall under the Implementation and Assess phase respectively of the lifecycle diagram.Slide Note: We have two paths to follow depending upon the requirements for monitoring the system, application, or IT Service. If it is a commercially available solution, then we would determine if the vendor/partner provides a Management Pack for Operations Manager. However, if this is an in-house developed application, then it would require custom development of the MP. It is important that when undertaking the responsibility of developing a Management Pack, you need to ensure you understand the requirements from the business and the application/service owner in order to model it correctly. When we talk about the model, we are referring to the health model (this is defined by the application/service owner and not the business). Another important point when developing a management pack are special requirements around security delegation be required, user experience, notifications, reporting, etc. The last two bullet points fall under the Implementation and Assess phase respectively of the lifecycle diagram.

10. Microsoft & 3rd Party Partner Management Packs

11. Vendor Management Packs Will be released sealed so you will not be able to modify directly. Requires storing overrides in a custom Management Pack. Best practice is not store your overrides in the “Default Management Pack” that is installed with Operations Manager 2007. Slide Note: Some vendor MP’s are/may not be sealed, but this is an exception to the rule. An example is the Microsoft Deployment Toolkit Management Pack. I would like to make one important note about the Default Management Pack. This MP, which is installed by default when you setup the first management server in your management group (RMS), has the default views defined and any custom views (alert, state or otherwise) and contains references to some of the management packs installed during setup. If you store your overrides in this MP, it contains inter-dependencies and over time you wind-up in a situation where it becomes unmanageable. This won't cause problems during day-to-day operations, but it makes removing the Management Pack difficult later. In particular, it creates a dependency between your Management Pack and the Default Management Pack that is not removed even when you remove the overrides I have actually mucked with the default MP and caused my console to cease functioning by corrupting that management pack. Unfortunately customers find out after the fact, like watching this webcast, where it is not recommended to store any overrides in this MP. This is something we are tracking and looking to address in a future release.Slide Note: Some vendor MP’s are/may not be sealed, but this is an exception to the rule. An example is the Microsoft Deployment Toolkit Management Pack. I would like to make one important note about the Default Management Pack. This MP, which is installed by default when you setup the first management server in your management group (RMS), has the default views defined and any custom views (alert, state or otherwise) and contains references to some of the management packs installed during setup. If you store your overrides in this MP, it contains inter-dependencies and over time you wind-up in a situation where it becomes unmanageable. This won't cause problems during day-to-day operations, but it makes removing the Management Pack difficult later. In particular, it creates a dependency between your Management Pack and the Default Management Pack that is not removed even when you remove the overrides I have actually mucked with the default MP and caused my console to cease functioning by corrupting that management pack. Unfortunately customers find out after the fact, like watching this webcast, where it is not recommended to store any overrides in this MP. This is something we are tracking and looking to address in a future release.

12. Overrides Performed directly in the Operations Console. Two approaches to consider: Create a custom Management Pack that has a direct relationship with the Management Pack you are overriding. Use a logical name that maps to the vendor MP. Example: Custom – Windows Server 2003 Operating System Slide Note: There are other options available for performing overrides. The most common approach when only having to perform a select few would be from within the Operations Console. However, if you need to perform many (i.e. in bulk) this can be tedious, therefore leveraging Silect MP Studio or Override Creator from Boris Yanushpolsky is more appropriate. In addition, OverrideExplorer allows you to view what overrides exist in a management group and move, change the target, or delete the override.Slide Note: There are other options available for performing overrides. The most common approach when only having to perform a select few would be from within the Operations Console. However, if you need to perform many (i.e. in bulk) this can be tedious, therefore leveraging Silect MP Studio or Override Creator from Boris Yanushpolsky is more appropriate. In addition, OverrideExplorer allows you to view what overrides exist in a management group and move, change the target, or delete the override.

13. Overrides Approaches (cont): Another strategy is to group according to internal application or support group When complete you can export your custom MP from the Operations Console. Must match the sealed Management Pack overrides are made against. Slide Note: Slide Note:

14. Overrides Advantages of creating custom override MP directly related to the MP you are overriding: Can be imported/exported separately or all at once Each uniquely versioned Important - do not use the “Disable” command in the override menu! Slide Note: Slide Note:

15. Demo

16. Internally Developed Management Packs

17. MP Development Development of Management Pack depends on requirements. Typically they are: 1) Basic MP: making use of event and performance rules, but no custom classes. 2) Advanced MP: evaluating health state, running scripts, and provides tasks. 3) Sophisticated MP: making use of all capabilities provided with Operations Manager 2007. Slide Note: With the three development types, the first bullet point can be performed from within the Operations Console. The second and third development type will require using an advanced authoring tool such as the Authoring Console or via native XML (if you are comfortable after learning the schema of our MP XML). Slide Note: With the three development types, the first bullet point can be performed from within the Operations Console. The second and third development type will require using an advanced authoring tool such as the Authoring Console or via native XML (if you are comfortable after learning the schema of our MP XML).

18. Management Pack Authoring Author may utilize: Operations Console Authoring Console XML editing Programmatic authoring 3rd Party Authoring Product Personal preference of the MP Author based on requirement complexity. Slide Note: Here are the common approaches highlighted for authoring a Management Pack. For the more complex scenarios, the Authoring Console or XML Editor is most appropriate. Performing authoring in the Operations Console is for those quick easy wins, and should not be used for a MP that needs to be developed from the “ground up.” Silect Software’s MP Studio for OpsMgr 2007 comes with many benefits and should be considered, as it exceeds the capabilities of the Authoring Console.Slide Note: Here are the common approaches highlighted for authoring a Management Pack. For the more complex scenarios, the Authoring Console or XML Editor is most appropriate. Performing authoring in the Operations Console is for those quick easy wins, and should not be used for a MP that needs to be developed from the “ground up.” Silect Software’s MP Studio for OpsMgr 2007 comes with many benefits and should be considered, as it exceeds the capabilities of the Authoring Console.

19. Guides Operations Manager 2007 Management Pack Authoring Guide Blogs Brian Wren - http://blogs.technet.com/brianwren/default.aspx OpsMgr Product Team Blog - http://blogs.technet.com/momteam/default.aspx Marius Sutara - http://blogs.msdn.com/mariussutara/ Sam Patton - http://blogs.msdn.com/sampatton/default.aspx Authoring Guide and Tools Slide Note: Slide Note:

20. Authoring Guide and Tools Part of main product MP Verify MP Seal MP Convert Authoring tools MP Diff (MOM 2005 Reskit tool) Resultant Set of Rules (OpsMgr Reskit tool) Authoring Console (includes Verify and BPA) 3rd Party Authoring tools Silect Software MP Studio Slide Notes: Slide Notes:

21. Demo

22. Test Plan Develop your test plan with input from the team. Factor: Globalization (such as different languages) Versions of different Management Packs Signed & un-signed MP’s Perform testing against the test plan and document the results. Schedule meetings with team to review results and prioritize remediation plan. Slide Note: The test plan should be developed in either case – working with a vendor provided Management Pack, or working with a custom developed Management Pack. The importance of having a test plan is realized when developing your own MP - consideration of agent\agentless, multiple management groups, service packs, platform (x86/x64), OS Type, clustering and NLB, physical/virtualized, security (low vs. high priv).Slide Note: The test plan should be developed in either case – working with a vendor provided Management Pack, or working with a custom developed Management Pack. The importance of having a test plan is realized when developing your own MP - consideration of agent\agentless, multiple management groups, service packs, platform (x86/x64), OS Type, clustering and NLB, physical/virtualized, security (low vs. high priv).

23. The MP should be tested in a Dev/QA environment before implementation in your production Management Group. Ensures you identify issues, accuracy, and are addressed without impacting production (i.e. alert noise, overhead from perf data, etc.) Work with the SME and SO to verify during the test phase. Testing the Management Pack Slide Notes: I cannot stress enough bullet point 1. All too often have I witnessed customers who have simply imported a Management Pack into production without understanding the configuration requirements and its default settings , and then becoming overwhelmed with “alert noise.” Slide Notes: I cannot stress enough bullet point 1. All too often have I witnessed customers who have simply imported a Management Pack into production without understanding the configuration requirements and its default settings , and then becoming overwhelmed with “alert noise.”

24. Once the core monitoring objectives are solidified & validated, seal the MP. Work with business owner to match SLA requirements against the core MP in a custom MP (overrides). Package both in preparation for import into the production Management Group. Testing the Management Pack Slide Note: Can be tested using Silect MPStudio: Without importing the MP into the MG via the file system Or already imported into the MG Using the Resultant Set of Alerts feature.Slide Note: Can be tested using Silect MPStudio: Without importing the MP into the MG via the file system Or already imported into the MG Using the Resultant Set of Alerts feature.

25. Converts XML to a binary file. Ensures that predefined settings cannot be modified directly and is tightly controlled (read only). Overrides would have to be saved in a custom Management Pack. Unsealed management packs cannot be referenced by another Management Pack. Strong identity Sealing the Management Pack Slide Note: Make note that this slide is specific to a in-house developed Management Pack, and not for an Override Management Pack.Slide Note: Make note that this slide is specific to a in-house developed Management Pack, and not for an Override Management Pack.

26. Valid certificate required in order to seal the Management Pack using MPSeal.exe. This can be found in the SupportTools folder on the Operations Manager 2007 CD. Create the certificate using Visual Studio 2005/2008 Strong Name Utility (SN.EXE) Certificate Slide Note: Make note that this slide is specific to a custom in-house developed Management Pack, and not for a custom Override Management Pack. Slide Note: Make note that this slide is specific to a custom in-house developed Management Pack, and not for a custom Override Management Pack.

27. Demo

28. These actions ensure that the alerts effectively and accurately monitor for a given service. Each rule should be evaluated according to the following criteria: Actionability: An alert is actionable if it tells you what went wrong and how to fix it. i.e. accurate alert text and knowledge. Validity: An alert is valid if the issue that generated the alert can be confirmed & it actually occurred at the moment the alert was generated. Suppression: There should be one and only one alert generated stating the issue occurred by the one rule. Alert Tuning

29. Plan the pilot scope and don’t target the Management Pack to all applicable systems from the beginning. How do I do this? Dual-home agents in production to the test Management Group. Monitor alert noise using the Most Common Alerts built-in report. Document pilot results and evaluate to remediate as necessary. Pilot Slide Notes: The pilot would be performed against production agent managed systems, but you don’t import the custom developed MP or the vendor provided MP w/override just yet. Make sure the test MG is up-to-date with the production ready MP, and dual-home production agents against the test MG. This is one way you can control the scope of your pilot without having to use “creative” methods to manage that in a production MG. Once the pilot is complete and any remediation is performed, the custom developed MP may require some changes and therefore it will need to be edited and resealed. Then you can confidently import into the production Management Group. Don’t import into production until this phase of the workflow is completed, to avoid redundant administration (import then find issues, then delete and then re-import, etc.)Slide Notes: The pilot would be performed against production agent managed systems, but you don’t import the custom developed MP or the vendor provided MP w/override just yet. Make sure the test MG is up-to-date with the production ready MP, and dual-home production agents against the test MG. This is one way you can control the scope of your pilot without having to use “creative” methods to manage that in a production MG. Once the pilot is complete and any remediation is performed, the custom developed MP may require some changes and therefore it will need to be edited and resealed. Then you can confidently import into the production Management Group. Don’t import into production until this phase of the workflow is completed, to avoid redundant administration (import then find issues, then delete and then re-import, etc.)

30. ITIL Service Management Processes for MP Lifecycle Management Slide Note: The Information Technology Infrastructure Library (ITIL), designed by the UK Gov’t Office of Government Commerce (OGC), is an IT Service Management framework of best practices, which is now in version 3. ITIL gives a detailed description of a number of important IT practices with comprehensive checklists, tasks and procedures that can be tailored to any IT organization. It was developed in the 1980’s but not widely adopted until the 1990’s. Slide Note: The Information Technology Infrastructure Library (ITIL), designed by the UK Gov’t Office of Government Commerce (OGC), is an IT Service Management framework of best practices, which is now in version 3. ITIL gives a detailed description of a number of important IT practices with comprehensive checklists, tasks and procedures that can be tailored to any IT organization. It was developed in the 1980’s but not widely adopted until the 1990’s.

31. Important to ensure consistent, repeatable, and structured approach. Change Management should be utilized to control changes being performed to production Management Group: Importing Management Packs (sealed/unsealed) Implementing overrides to a sealed MP. ITSM Process

32. Release Management should be followed for development, testing, and release of Management Packs. Definitive Software Library (DSL) should be established to store each version of the MP developed and approved for implementation in production. Maintain configuration items in the CMDB (documents, change requests, etc.) ITSM Process

33. Change Management Change Request Change Classification Category Urgency Priority Change Authorization Change Initiation Review (CIR) Change Development Change Release Change Review Slide Notes: Here we are highlighting the activities as part of the Change Management process. Change request can be as simple as filling out a web-form and submitting for review and approval by management, or more formalized depending on your organization. If you already have a Change Management process, then leveraging it is encouraged. Change Classification – is this an urgent(emergency) or normal request, is this a minor or major change of a management pack, etc. End result – only implementing approved changes into production and you follow standardized method and procedures to minimize the impact of Change-related incidents.Slide Notes: Here we are highlighting the activities as part of the Change Management process. Change request can be as simple as filling out a web-form and submitting for review and approval by management, or more formalized depending on your organization. If you already have a Change Management process, then leveraging it is encouraged. Change Classification – is this an urgent(emergency) or normal request, is this a minor or major change of a management pack, etc. End result – only implementing approved changes into production and you follow standardized method and procedures to minimize the impact of Change-related incidents.

34. Release Management Release Planning Release Building Acceptance Testing Release Readiness Review Rollout Planning Rollout Preparation Rollout Slide Notes: Here we are highlighting the activities commonly conducted during the Release Management Process. Procedures, templates and guidance should be planned to enable the central Release Management staff to take the management packs, and then to release the them efficiently and effectively. Rollout planning extends the Release plan produced so far to add details of the exact installation process developed and the agreed implementation plan for the management pack. End result – Quality and high success rate introducing changes into your management group.Slide Notes: Here we are highlighting the activities commonly conducted during the Release Management Process. Procedures, templates and guidance should be planned to enable the central Release Management staff to take the management packs, and then to release the them efficiently and effectively. Rollout planning extends the Release plan produced so far to add details of the exact installation process developed and the agreed implementation plan for the management pack. End result – Quality and high success rate introducing changes into your management group.

35. Change, Config, & Release Relationship Slide Notes: There is a close relationship between the three service management functions (Change Management, Configuration Management, and Release Management) Change management Provides the authorization and tracking processes (RFC, change log, and reviews) to ensure only approved changes are deployed. Needs configuration management to assess the impact of change on all potential CIs. Needs release management to package the changes for successful deployment with minimal disruption to production. Configuration management Provides a managed database (CMDB) for the change logs, RFCs, definitive software library (DSL), definitive hardware store (DHS), release package, and all CIs. Needs change management to ensure that only approved changes are deployed and all tracking of the authorization process is complete. Needs release management to update the CMDB with the release package after deployment. Release management Provides a packaged release for all changes deployed into production. Needs change management to approve changes and track them throughout the release process. Needs configuration management to assess the impact of changes to CIs and to provide a definitive store for the release package. Slide Notes: There is a close relationship between the three service management functions (Change Management, Configuration Management, and Release Management) Change management Provides the authorization and tracking processes (RFC, change log, and reviews) to ensure only approved changes are deployed. Needs configuration management to assess the impact of change on all potential CIs. Needs release management to package the changes for successful deployment with minimal disruption to production. Configuration management Provides a managed database (CMDB) for the change logs, RFCs, definitive software library (DSL), definitive hardware store (DHS), release package, and all CIs. Needs change management to ensure that only approved changes are deployed and all tracking of the authorization process is complete. Needs release management to update the CMDB with the release package after deployment. Release management Provides a packaged release for all changes deployed into production. Needs change management to approve changes and track them throughout the release process. Needs configuration management to assess the impact of changes to CIs and to provide a definitive store for the release package.

36. Release Management Slide Notes: This diagram displays the release lifecycle for testing, packaging, and deploying management packs into production. The objective is to ensure a predictable and consistent schedule for releasing changes into production. This avoids the situation of someone “tapping” you on the shoulder or e-mailing you with the request “we need this implemented into production today.” Down the road, those situations only create stability and reliability issues that come back to haunt you.Slide Notes: This diagram displays the release lifecycle for testing, packaging, and deploying management packs into production. The objective is to ensure a predictable and consistent schedule for releasing changes into production. This avoids the situation of someone “tapping” you on the shoulder or e-mailing you with the request “we need this implemented into production today.” Down the road, those situations only create stability and reliability issues that come back to haunt you.

37. Documentation A Deployment Guide outlining the configuration and functionality for the Operations/Admin team to follow. A Release Plan & Policy to ensure the process is predictable & repeatable (ensuring consistency). Override changes in custom MP should be documented as well.

38. Override Change Log Document all overrides implemented in your Custom Management Pack. Use MPViewer, Override Explorer utilities or Command Shell Get-Override command. Provides an audit trail and avoids confusion in the future. Spreadsheet format a good starting point, but SharePoint is also good candidate. Slide Note: Other formats could be used, such as SharePoint, a custom Web front-end with database back-end, etc. The spreadsheet format is a good starting point. Also make sure that the fields in the Change Log matches the Override Report, to avoid any confusion and maintain consistency from a logical perspective. Outside of simply documenting the override change for each override defined, you can also do a cross-check of your Change Log by running MPViewer or OverrideExplorer utility by Boris Yanushpolsky. You can also execute the CommandShell Get-Override command and pipe to a file (HTML or other format). I mentioned the Overrides report and this was something that was provided with Service Pack 1 and can be found under the Microsoft Generic Report Library.Slide Note: Other formats could be used, such as SharePoint, a custom Web front-end with database back-end, etc. The spreadsheet format is a good starting point. Also make sure that the fields in the Change Log matches the Override Report, to avoid any confusion and maintain consistency from a logical perspective. Outside of simply documenting the override change for each override defined, you can also do a cross-check of your Change Log by running MPViewer or OverrideExplorer utility by Boris Yanushpolsky. You can also execute the CommandShell Get-Override command and pipe to a file (HTML or other format). I mentioned the Overrides report and this was something that was provided with Service Pack 1 and can be found under the Microsoft Generic Report Library.

39. Versioning Version Control (aka Revision Control aka Source Control) lets you track your files over time. Why do you care? So when a mistake is made, you can easily revert back to a previous working version. Version number format – Major.Minor.Build. Example: 1.0.2100 Important when an MP references other MP’s that are dependencies.

40. Versioning Versions are enforced by Operations Manager where an older version cannot overwrite newer version of the same MP. It is not possible to run different versions of the MP side-by-side. Apply the version control model to both the internal developed Management Pack and the custom Management Pack that stores the overrides.

41. Silect MP Studio/MP Studio Lite – http://www.silect.com/solutions/opsmgr_Sol/opsmgr_Sol_studio.html Alert Tuning Solution Accelerator - http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smc/sts05.mspx Templates to support this process – http://blogs.technet.com/mgoedtel Boris Yanushpolsky MP Tools - http://blogs.msdn.com/boris_yanushpolsky/default.aspx OpsMan Jam Site – http://www.opsmanjam.com Additional References Slide Note: Slide Note:

42. Questions?