Archive

Archive for the ‘Operations Manager Design’ Category

Underscore character not supported in SQL named instances

March 15, 2011 Leave a comment

This came up on the forums recently and the original poster got this information back from PSS – “The Microsoft engineer found that my SQL Server 2008 R2 named instance contains an underscore (_) character which is NOT supported. After I re-install the SQL Server 2008 R2 and create a named instance without the underscore (_) character, I was able to install the System Center Operations Manager 2007 R2 Reporting component.

Advertisements

Regular Checks of OpsMgr

November 8, 2010 Leave a comment

A recent question on the Technet Forums was how to best do regular health checks of OpsMgr – here is a reliability worksheet to get started (along with the usual collection of articles that Kevin Holman has on his blog).

SQL 2008 R2 support for OpsMgr databases

September 28, 2010 Leave a comment

A new KB article has been released which details support for installing a new OpsMgr environment based on SQL 2008 R2 – http://support.microsoft.com/kb/2425714/en-gb

Note that upgrades to SQL 2008 R2 are not supported (this is listed as phase 2) and that there are “known issues” which are listed at the bottom of the KB article.

Good Luck … think I’ll wait a while 😉

Operations Manager 2007 R2 sizing guides

January 12, 2010 Leave a comment

A useful spreadsheet to help determine sizing:
http://blogs.technet.com/momteam/archive/2009/08/12/operations-manager-2007-r2-sizing-helper.aspx

Also, a technet article which includes different deployment scenarios with hardware recomendations:
http://technet.microsoft.com/en-us/library/bb735402.aspx

Data Gathering

January 12, 2010 Leave a comment

Below are some ideas, by no means exhasutive, on some basic considerations around gathering accurate data about what you want from an Operations Manager deployment.

The first process as part of a design is to fully and accurately identify the requirements of the monitoring solution and prepare a document which details the scope of any subsequent implementation. This provides:
> A thorough understanding of what is required by the implementation
> A basis for a best practice design
> A measure of the success of the implementation

Ideally this should be signed off by all interested parties to ensure that everyone agrees to the scope and that expectations of deliverables are understood.

Confirm Scope and Constraints of Implementation
Getting an accurate inventory of the current environment helps you in two regards. First, it tells you about what Operations Manager will be monitoring, and it also tells you the restrictions or boundaries it must operate within. Be sure to include the following points:
> The approximate number of devices that will be monitored.
> The applications that will be monitored.
> The physical and network location of the devices that will be monitored.
> The physical and network location of the people who will use Operations Manager data.
> Firewalls and wide area network (WAN) links that define network boundaries.
> The Active Directory Trust boundaries. Trusts need to be 2 way Forest Trusts to support Kerberos authentication. Otherwise certificates will need to be used.
> Integration with other products that are used to perform monitoring, including ticketing systems.
> Method of Notification.
> Line of Business Applications (“Services”) that need monitoring.
> Availability/Recoverability requirements.
> Budget – anything is possible (almost!). Knowing and operating within the budgetary constraints is critical to the success of the project.
> Prioritise so that the key items of monitoring are covered first.

Who needs to see what?
Determine which people need to see what information and what privileges they need to have over that information. For example, who needs to be able to set overrides, run reports or just view alerts. This can be done within a spreadsheet.

Regulatory Compliance
Check to see if:
> Any regulatory Compliance monitoring is required. If so, what do the regulations state? Knowing this will help with determine Audit Collection Service (ACS) planning.
> What sort of data is the business process owner looking to IT to provide and for what time frames? This will help with reporting planning and data-retention planning.

Document current processes
If Operations Manager is being deployed to replace an existing monitoring solution then it is worthwhile looking at the current solution and adding to each of the questions below, “What is good and you want to replicate with Operations Manager and what needs to be done better?”
> How does your organization perform monitoring today?
> Who normally responds to issues or alerts that are raised by automated systems or helpdesk? Knowing this will help determine who needs direct access to the Operations console and what data the console should contain.
> Does the helpdesk usually resolve server issues, or are issues passed to the server support teams?
> How are desktop or client applications monitored currently?
> How is monitoring performed for non Windows devices?

This doesn’t mean that the scope of the implementation is set in concrete. It doesn’t mean that the scope of the implementation won’t evolve. Things change. People come and go and each will have different view on what is needed. Items might be missed. Environments change. But this process gives a basis from which all changes can be mapped.

References:
Operations Manager 2007 Design guide – http://technet.microsoft.com/en-us/opsmgr/bb498235.aspx?ppud=4
Operations Manager 2007 IPD guide – http://technet.microsoft.com/en-us/library/ee354213.aspx