System Center Operations Manager 2007: Blog

OpsMgr by Example: Server 2008 POC - Part 2 (Database Server)

Mon, 18 Aug 2008 08:15:23 GMT

http://ops-mgr.spaces.live.com/Blog/cns!3D3B8489FCAA9B51!710.entry | Comments

This is the second of a five part series discussing lessons learned when installing System Center Operations Manager onto a fully Windows 2008 environment (DC, RMS, SQL, and Reporting servers). Since we now have a functional Windows 2008 domain controller (see Part 1 of this series at http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!695.entry), our next step is installing and configuring the Operations Manager database server.

SQL Installation

Installation prerequisites for the Operations Manager database components included first performing a standard SQL 2005 installation, and then installing SQL 2005 SP2.

Windows Server 2008 adds the Web Server as a role. If you have not the Web Server and the asp.net option, this shows as a warning during the SQL Server installation. Since this server will not provide reporting services or other web based features, we can ignore those warnings during our installation process. We installed SQL Server using default configurations, with the exception of choosing a domain user account to be the SQL Server service account.

Hotfixes for OpsMgr 20007 – Windows 2008 Servers with Agents

Each of the servers in this configuration needed to have three hotfixes applied:

After applying these hotfixes, you will need to reboot the system.

Additional OpsMgr Prerequisites

The database server for this environment will host both the Operations Manager database and the Data Warehouse functions. After installing SQL 2005 and patching it with SQL 2005 SP2, a prerequisites check indicated the server was ready for installing both the Operational Database and Data Warehouse OpsMgr components.

The next step was installation of the Operations Manager database. We used the default configurations, as shown in the video below.

Firewall change

To allow the SQL Server to communicate on the default port we need to create a new inbound rule to allow SQL Server port TCP port 1433. This assumes of course that you are using the default port, if you use a different port (such as installing a second instance), you will need to change the firewall to allow that port to communicate.

After installing this rule, log into another system in your environment and validate that telnet can connect to the SQL server on port 1433. Windows Server 2008 does not install the telnet client by default in Windows Server 2008, so you must add that feature prior to testing the ability to connect to the SQL Server.

Lessons Learned

Installing the Operations Manager database components is straightforward as long as you remember to install the appropriate hotfixes and create a firewall rule to allow inbound communication to port 1433.

Some great blogs have been covering information on Windows 2008. Definitely look into:

http://blogs.technet.com/kevinholman/archive/2008/08/05/my-experience-installing-a-scom-management-server-on-windows-server-2008.aspx - a great write-up on installing OpsMgr on Windows Server 2008
http://blogs.technet.com/kevinholman/archive/2008/07/29/how-do-i-know-if-i-have-all-the-required-hotfixes-on-windows-server-2008-to-be-supported-for-a-opsmgr-agent.aspx - write-up on required hotfixes

Quick Access to OpsMgr Agent Information

Sun, 17 Aug 2008 13:21:20 GMT

http://feeds.feedburner.com/~r/techlog/~3/367136069/quick_access_to_opsmgr_agent_i | Comments

Derek Harkin writes: Sometimes you need access to some information from Opsmgr in a hurry and you really do not want to open up the Ops Console and wait for it to load. Here is a powershell script that extracts information from OpsMgr and drops it into several HTML files so it can be added to a website. Download Script

The pages created are the following:

· AgentsCounts.html - This gives give you a count of the number of agents per management group and breaks this down also by per management server

· MonitoredServers.html - This page gives a complete list of all the agents being monitored by Opsmgr.

· ServersDown.html - This gives a list of servers that may be down. It is actaully a list of servers where the heatlth service watcher is in an "Error" state.

· AgentsLast7days.html - This is a list of all agents installed in the last 7 days, when they were installed and includes their health state

The script does require some configuration before it can be used:

1) At the very start of the script you have to enter the name of the Root Management Server. You can uncomment the next lines lines and define multiple RMS's if you want to pull the information from more than 1 management group.
2) $outpath = "c:\" - Change this to where you want the script to write the html files.
3) If connecting to more than one managemet group you need to comment out line 17 an uncomment Line 19

OpsMgr 2007 Unleashed Errata - the EnableAdIntegration Registry Key

Fri, 15 Aug 2008 21:50:58 GMT

http://ops-mgr.spaces.live.com/Blog/cns!3D3B8489FCAA9B51!697.entry | Comments

Page 390 of System Center Operations Manager 2007 Unleashed discusses modifying the Registry settings for the EnableADIntegration key on the RMS and management servers. This information was based on our own experiences and testing during earlier versions of OpsMgr 2007, as well as recommendations from Microsoft. Microsoft has since changed the behavior such that this Registry key hack is no longer recommended, and can actually cause problems.

We will be changing the information in the next printing of the book and the errata to say:

To complete the proces of activating OpsMgr integration with AD, validate that the registry key HKLM\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\ConnectionManager\EnableADIntegration is set to 0.This is the default setting.

There has been some confusion regarding how to configure this setting on management servers. However, do not change it to 1; the value should actually be the default configuration of 0. Changing the value to 1 is not required and actually may cause issues on the management servers.

How to change the credentials for the OpsMgr SDK Service

Fri, 15 Aug 2008 12:21:33 GMT

http://feeds.feedburner.com/~r/PontusOperationsManagementBlog/~3/331691358/how-to-change-credentials-for-opsmgr.html

While doing some Lab work on the VMM 2008 PRO integration with Hyper-V and VMM 2008 and Operations Manager 2007 I needed to change the SDK Service account to Local System for the VMM 2008 to Operations Manager 2007 connection to work properly. I found a very good KB article that maybe someone else also has a need for. The article describes how to change the service accounts for Operations Manager 2007 in "any direction" to or from Local System.

You find all information in the KB936220 here.

OpsMgr by Example: Server 2008 POC - Part 1 (Domain Controller)

Fri, 15 Aug 2008 12:19:18 GMT

http://ops-mgr.spaces.live.com/Blog/cns!3D3B8489FCAA9B51!695.entry | Comments

This is the first of a five part series that discusses lessons learned when installing System Center Operations Manager in a Windows 2008 environment. Windows Server 2008 introduces some features that impact how applications are deployed and configured. Specific areas that affect application deployment and configuration are server roles and the Windows 2008 firewall.

Windows 2008 Server Roles

Windows 2008 uses server roles to simplify the process of installing and to minimize the maintenance and potential security vulnerabilities of the system. Windows 2008 Server initially installs without activating any of these server roles. Examples of server roles include:

Active Directory Certificate Services
Active Directory Domain Services
Active Directory Federation Services
Active Directory Lightweight Directory Services
Active Directory Right Management Services
Application Server
DHCP Server
DNS Server
Fax Server
File Services
Hyper-V (64-bit OS only)
Network Policy and Access Services
Print Services
Terminal Services
UDDI Services
Web Services
Windows Deployment Services

The Windows 2008 Firewall

The Windows 2008 firewall, by default, is active on Server 2008. As you install various roles, the Operating System adapts the firewall rules so that the new roles will function. As an example, port 80 is opened inbound to the server if web services are activated.

Since Windows 2008 does not define SQL Server as a server role, firewall rules are not automatically configured when you install SQL Server. http://cameronfuller.spaces.live.com/blog/cns!A231E4EB0417CB76!1427.entry includes a discussion on how SQL Server needs to have firewall rules changed so the configuration manager can access the SQL Server databases.

Server Roles for our OpsMgr Configuration

The servers involved in the configuration we will be discussing in this series include a domain controller, database server, Root Management Server (RMS), data warehouse, and reporting server. We will discuss them in the following order:

OpsMgr by Example: Server 2008 POC – Part 1 (Domain Controller)
OpsMgr by Example: Server 2008 POC – Part 2 (DB)
OpsMgr by Example: Server 2008 POC – Part 3 (RMS)
OpsMgr by Example: Server 2008 POC – Part 4 (DW)
OpsMgr by Example: Server 2008 POC – Part 5 (Reporting)

Installing the Domain Controller

The first step to build our Windows 2008 environment was installing a Windows 2008 domain controller using default configurations. Each server in our configuration was installed within Windows 2008 Hyper-V (a good discussion on installation of Hyper-V is available as part of http://cameronfuller.spaces.live.com/blog/cns!A231E4EB0417CB76!1273.entry, look at the first step). The following video shows the steps involved in the installation of a new domain controller into a new forest/new domain.

Once the domain controller reboots, validate that Active Directory Users and Computers shows the new DC appearing in the Domain Controllers container. You will want to validate DNS by verifying that the DNS Server role is installed and the forward lookup zone is created correctly.

With the domain controller installed and DNS functional, we can start installing prerequisites on the various Operations Manager components. The first step in this process is the Operations Manager database, which we will discuss in part 2 of this series.

Lessons Learned:

Windows 2008 affects how you install and configure applications; through using server roles and configuration changes required to the Windows 2008 firewall.

Monitoring a service for State and StartMode

Fri, 15 Aug 2008 12:17:53 GMT

http://blogs.technet.com/jimmyharper/archive/2008/08/10/monitoring-a-service-for-state-and-startmode.aspx | Comments

I recently had a customer that wants to get an alert when a specific service is not Disabled and/or not Stopped. I used the following steps to accomplish this using a "Timed Script Three State Monitor". Even if you do not have this specific need, these steps can be used as a template for creating a monitor that uses a script to query WMI and change state or generate alerts based on the results. If you don't have a need for three states (Critical, Warning, Healthy), there is a Two State Monitor that can be used for this.

aCreate a new Monitor, select Scripting\Generic\Timed Script Three State Monitor

Give it a name, target, etc. (I targeted the Windows Computer class, but Windows Operating System may be a better choice). I try to make a habit of unchecking "Monitor is enabled" and enabling it with an override later....at least while testing it:

Set the schedule...this just depends on how quickly you want to know if the service gets changed:

Next, I used a basic VB script which accepts a service name as a parameter, queries WMI for the service, and puts the Service Name, State (Running, Stopped, etc.), and StartMode (Disabled, Manual, Automatic) into property bag values. The full text of the script is below the screenshot:

---------------------------------------------------------------------------------------------------

Dim oAPI, oBag,strComputer
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()
set oArgs=wscript.arguments
strComputer="."
ServName=oArgs(0)

Set namespace=GetObject("winmgmts:\\"& strComputer & "\root\cimv2")
set servinfo=namespace.ExecQuery("select * from win32_service where name =" & """" & servname & """")

for each objservice in servinfo

Call oBag.AddValue("ServiceName",ServName)
Call oBag.AddValue("State",objservice.State)
Call oBag.AddValue("StartMode",objservice.StartMode)
Call oAPI.Return(oBag)

---------------------------------------------------------------------------------------------------

For the script parameter, I just enter "ServiceName"....this will be replaced by an override later, or you can just enter your service name here:

Next, I set the "Unhealthy", "Degraded", and "Healthy" expressions for the monitor. My goal is to set the state to Warning when the service is Stopped but NOT Disabled , Critical when it is NOT Stopped, and Healthy when it is Stopped AND Disabled. I used the following expressions:

Unhealthy Expression:

Parameter Name: Property[@Name='State']

Operator: Does not equal

Value: Stopped

Degraded Expression:

Parameter Name: Property[@Name='StartMode']

Operator: Does not equal

Value: Disabled

AND

Parameter Name: Property[@Name='State']

Operator: Equals

Value: Stopped

Healthy Expression:

Parameter Name: Property[@Name='StartMode']

Operator: Equals

Value: Disabled

AND

Parameter Name: Property[@Name='State']

Operator: Equals

Value: Stopped

Next, I used the default settings for Health State, since they already match what I want to do:

Next, I configure the alert settings. The settings in the screen shot below will generate a Warning alert when the monitor is in a Warning state (service is not Disabled), and a Critical alert when the monitor is in the Critical state (service is not Stopped). The Alert Description will have the service name (using the ServiceName property created by the script):

Now that I have the monitor created, I need to enable it and set the Override for the Service Name:

I'm using the Alerter service for my test:

To test the monitor, I first set the Alerter service to Manual Startup and leave it stopped:

Then I verify that I get the Warning alert:

Health Explorer correctly shows the "Degraded" Warning state:

Now I want to test the Critical state, so I start the Alerter Service:

Now the alert is changed to Critical:

And Health Explorer shows the "Unhealthy" Critical state:

When I stop the service and disable it, the alert is auto-resolved and the state is changed back to Healthy:

I've attached my sample MP which includes the following monitors:

Service disabled and stopped - two-state monitor:

If the specified service is not Stopped AND Disabled, the computer will be put in a Warning state and a Warning alert will be generated. When the service is stopped and disabled, the computer will be put in a Healthy state.

Service disabled and stopped - three-state monitor:

If the specified service is Stopped and is not Disabled, the computer will be put in a Warning state and a Warning alert will be generated. If the specified service is not Stopped, the computer will be put in a critical state and a Critical alert will be generated. When the service is stopped and disabled, the computer will be put in a Healthy state.

Usage:

Both monitors are targeted at the Windows Computer class and roll up to the Configuration Health. Both monitors are disabled by default. They are configured to check the service every 1 minute. To enable one of the monitors, add an Override for the Computer or Group you wish to monitor and set the following Override parameters:

Enabled=True

Script Arguments = <Service Name>

Enjoy!!

This post contained the following enclosures and/or attachments:

http://blogs.technet.com/jimmyharper/attachment/3103036.ashx

NewsGator Inbox can be configured to automatically download attachments if you wish. For more information, please refer to the NewsGator Inbox help file (NewsGator Inbox > Help)

Set SPN Warning

Fri, 15 Aug 2008 12:17:11 GMT

http://ianblythmanagement.wordpress.com/2008/08/13/set-spn-warning/ | Comments

You may have seen this alert come up in OpsMgr 2007 SP1 if you used a domain account for the SDK and Configuration service account rather than Local System.

SDK SPN Not Registered

If you click on the View Additional Knowledge it tells you how to fix it.

In the Resolution area of the alert and the Knowledge it tells you the same thing - setspn needs to be run for MSOMSDK. But in the Alert Description it says it is MSOMSDKSVC. This is a mistake that was picked up by a customer and Jeanie Decker has posted that it is going to be fixed.

Use the details in the Alert Description. That is use MSOMSdkSvc. It tells you the correct SPN, the RMS NetBios name, the RMS FQDN and the SDK account to use. All you have to do is get them in the right order after setspn.exe -A.

OpsMgr BlogCasts for Free

Fri, 15 Aug 2008 12:13:26 GMT

http://myitforum.com/cs2/blogs/adominey/archive/2008/08/13/opsmgr-blogcasts-for-free.aspx | Comments

Later today, my OpsMgr blogcasts on the Blogcast Repository site will be free for all to access so you can take a look and see if you like them.

I'll be adding at least 1 video a month starting this month so please check out the guides here: http://blogcastrepository.com/level5/scom/default.aspx

Enjoy!

Andy

Maximizing Performance with User Roles

Mon, 11 Aug 2008 21:21:40 GMT

Objective

The purpose of this document is to explain how operational performance can be maximized through the implementation of User Roles*[1].

I still can't figure out images so if they are disturbingly distorted, check out http://www.opsmanjam.com/default.aspx in a few days, it will have the word doc version.

NOTE: This is not a technical document on how to deploy User Roles. It is intended to explain how User Roles, when deployed correctly, can boost performance. For information on how to implement User Roles, please see the System Center Operations Manager Deployment Guide.

Introduction

Performance, as it pertains to System Center Operations Manager 2007, is measured by the user experience while working in the operations console. Performance can also be measured as a function of alert latency, the time elapsed from when a condition is detected which requires the generation of an alert and the actual time the alert appears in the console.

Imagine a situation where alert latency is performing as expected, even exceeding operational performance requirements. Additionally, notifications are being generated and received in near real-time. If the operational console is performing poorly: refresh rates excessively slow, creation, modification and rendering of views also excessively slow; then now how to you describe the performance of the management group?

At the end of the day, the user experience in the operations console is the most important facet of performance in Operations Manager 2007. No matter how perfect the functionality of the management group, its value is destabilized if users can’t seamlessly navigate in the operations console.

The most common solution for ensuring performance in the operations console is to engineer the optimal infrastructure to host the management group. This primarily centers on the SQL 2005 database hosting the OperationsManager database and secondarily the RMS.

Assumptions

Maximizing performance with User Roles is only effective if all other infrastructure components are optimally configured. Be sure to resolve any resource deficiencies prior to implementing User Roles. The improvement in performance through the implementation of User Roles is terrific but only if there are no existing resource issues.

How It Works

The left side of the equation must equal the right side of the equation. Traditionally, ensuring performance in a management group would be accomplished by adding more resources to the management group. However, what if you could reduce the resource requirement of the management group without reducing the functional requirements? One technique for achieving this is through the implementation of User Roles; maximizing the efficiency of the operations console by authoring surgical scopes to only display the exact objects required by a user. The default operations console returns all objects defined by all management packs. In an enterprise environment the resource hit on the OperationsManager database is expansive. User Roles are used to define explicit views and are associated with their login. A user, regardless of where they login would always receive their view. This includes the web console too. The roles would be authored to contain only the objects and views required by that person’s technical role. So an Active Directory SME would have an entirely different view than an Exchange SME. By removing all ancillary views and objects, non-essential data, the resource requirements are drastically reduced thus requiring less power resulting in improved performance in the operations console. This is illustrated by a resource triangle.

Figure 1: Resource Triangle

Planning

Before deploying User Roles, it is vital to have an administrative plan[1] in place. Simply, this is document describing who does what in Operations Manager 2007. The objective is to explicitly describe the role and responsibility of the IT administrators, those who will be using the operations console, then translating into a specific set of Views and Tasks, necessary to allow them to fulfill their monitoring and diagnostic duties. This will provide all information necessary to author the appropriate User Role. Lastly, deploy the User Role via the web console if there is no reduction in functionality.

Profiles

System Center Operations Manager 2007 comes with several built-in profiles. The most common is the administrator profile which is typically generously used in most environments. This profile should be reserved for as few IT administrators as possible. The operations model I tend to favor in large environments is that of a centrally managed Management Group. A single person / team (OpsMgr Administrators) are responsible for the Management Group. They are responsible for everything pertaining to Administration, Authoring, Monitoring and Reporting. They are the only persons with Operations Manager Administrator privileges. The other users to access the operations console / web console are subject matter experts (SMEs). The SMEs then work with the OpsMgr Administrators to ensure management packs are deployed and performing properly, all custom reports are created correctly and lastly, all views are authored and functioning correctly. As I noted above, unless there is a piece of functionality needed in the Operations Console and not available in the web console, all SME should leverage the web console.

Scenario

The scenario described below is simple but provides the framework to build any User Role to meet even the most demanding administrators. This scenario will demonstrate how to create a USER Role for an Active Directory SME whose primary responsibility is to monitor their entire Active Directory environment.

In Operations Manager 2007, views, like other monitoring objects, are contained in Management Packs. If a view is contained in a sealed Management Pack, you can open the properties of the view but you cannot save any changes to it. Instead, you can change the display options of the view and then save it as a personalized view. So before serving up views with User Roles, the views must first be created.

1. Create a new management pack to contain all authored views. You have much flexibility. You can create one management pack for all views served up through User Roles or perhaps, one management pack per User Role. This all depends on the administration model decided upon. For the purpose of this document, I created a single management aptly named User Roles. After its creation, you will see a new folder in Monitoring.

2. Create a new folder under User Roles named Active Directory Support.

3. Insert / create all desired views. You can use the views in the Microsoft Windows Active Directory management pack to get started. In OpsMgr 2007 SP1, you can now Copy / Paste various objects, including views, from one sealed management pack to an unsealed management pack.

In addition, the user can create his or her own views by going to My Workspace.

4. Now that the desired view has been created, it now must be added to a custom User Role. For this demonstration, the User Role will be named ‘Active Directory Support’.

5. Create a new Global Group named Active Directory Support. It will contain all domain users who will have access to this User Role.

6. In the operations console, go to Administration / Security / User Role. Right-click User Role and select New User Role / Operator

7. Add the global group created in step 5 and name the User Role

8. Click Next, deselect all Groups. Select AD Doman Controller Group

9. Click Next, select which Tasks, if any, the User Role has access to.

10. Select Views:

11. Click Create

So now, when any domain user, who is a member of the global group ‘Active Directory Support’ launches the Operations Console, they will be presented with:

The above is simply a sample and can be modified as needed.

Conclusion

User Roles are instrumental in maximizing performance. In addition to reducing the performance impact of the operations console, they also provide a concise view of all objects only applicable to a users’ technical role. They will enjoy a speedy console while not being distracted by any ancillary views, alerts or events.

[1] Having an administrative plan is half the easy part, enforcing it will likely prove a bit more challenging.

[1] For information on how to maximize performance as a function of infrastructure, please see “Performance - The Criticality of Disk Subsystems”

Implementing High Availability Reporting

Sat, 02 Aug 2008 19:16:53 GMT

Objective

This document will provide the information required to deploy a highly available System Center Operations Manager 2007 Reporting solution. Before embarking on this, be sure to spend some time considering the true value in having a highly available reporting solution. Primarily the cost of implementing a high availability solution vs. the relatively short period of time you would be without reporting if you did not configure for high availability: If you lost the reporting server completely, restoring reporting services is very easy and very fast.

Introduction

The Reporting role in System Center Operations Manager 2007 (OpsMgr) presents a unique challenge. There currently exists no ‘official’ solution for configuring it for high availability. The primary challenge is reporting is comprised of two separate applications:

1. Reporting Data Warehouse – The Reporting Data Warehouse stores monitoring and alerting data for historical purposes.

2. Reporting Server – Operations Manager Reporting Server is installed into an instance of Microsoft SQL 2005 Reporting Services SP1. It is responsible for building and presenting the reports from data queried from the Reporting Data Warehouse.

The reporting data warehouse is a SQL 2005 database and therefore can benefit from database high availability solutions such as clustering. The reporting server is also a SQL 2005 service and generally speaking, can also benefit for SQL high availability solutions. The challenge is presented by the web service component used for communication between the operations manager console and the reporting; how is that service configured for high availability?

Recently I had time to explore possible solutions and was able to successfully create a highly available reporting solution. This document is not officially sanctioned by the product group although I hope to get there feedback soon however the solution works and does not involve any “proprietary” efforts.

Assumptions

There are three assumptions about the environment where this highly available reporting solution will be deployed:

1. Distributed management group. Each role has a dedicated server rather than an all-in-one deployment.

2. SQL environment is not shared with other applications. It is dedicated to OpsMgr, this includes the reporting server.

3. You have the appropriate service accounts, data warehouse read and write accounts.

4. DNS works correctly.

Architecture Overview

Scenairo

It is safe to assume a highly available reporting solution would only be deployed if the entire management group is configured for high availability. The above reference architecture is that of one configured for high availability. You may notice I did not specify what type of load balancer. Optimally, you would want an intelligent solution capable of balancing the load as well as automatically taken a failed node off-line.

Deployment

Second Report Server

1. Provision an additional SQL 2005 SP1 (or 2) server and join it to the same domain as the management group resides in.

2. Run the ‘Prerequisite Checker’ for 'Reporting' only. The assumption is the data warehouse is already on a highly available SQL server. Make any necessary changes.

3. Install Operations Manager 2007 Reporting. Deselect ‘Data Warehouse’.

4. When prompted for the name of the RMS, be sure to enter the FQDN.

5. When prompted for the SQL Server / Instance which hosts the data warehouse be sure to the FQDN.

6. Since this new server is dedicated to the ‘Reporting Service’, when asked for the ‘SQL Server Reporting Services Server’, simply select this server. It will appear in the drop down.

7. Enter data warehouse write account and the data warehouse read account when prompted. In the tested scenario, these were the same accounts used in the deployment of the first reporting server.

8. After installation is completed, launch the ‘Operations Console’ and go to ‘Administration / Settings / Reporting’ and verify the ‘Reporting Server’ URL correctly reports to the new server. It will have been changed during the installation.

9. On the RMS, restart the SDK and Config as well as the Health services. Then restart the reporting services on the new reporting server. Lastly, execute ‘IIS Reset’. If you went straight to Reporting in the operations console there would be no reports available. It takes a few minutes before it synchronizes. By executing the above mentioned services seems to speed it up. In the test environment, modestly sized, it took 20 minutes. Once all reports appear in the operations console you will have successfully deployed a second reporting server. Actually, all you have accomplished is replace the original reporting server. At this point you can leave as is or change the reporting server URL to that of the original server.

Load Balancing

These steps are generic and high level since there are many ways to implement load balancing. I will detail the solution implemented in the test lab. Feel free to free-style it.

1. Create two new host records in DNS. DNS best practices apply. In the test environment, the new FQDN for the primary reporting server was reporting-a.opsmgr.com and configured to resolve to the primary reporting server while the second reporting server was reporting-b.opsmgr.com and configured to resolve the newly provisioned reporting server.

2. Create a new ‘Reporting Server URL’ (reporting.opsmgr.com). This will be used in the ‘Reporting Server URL’ field in Administration / Settings / Reporting. Additionally, it needs to be configured to point to the Load Balancer.

3. In the test environment, an F5 load balancer was used. It was configured to evenly distribute incoming requests to http://reporting.opsmgr.com to reporting-a.opsmgr.com and reporting-b.opsmgr.com. Additionally, the F5 was configured to continually test both reporting-a.opsmgr.com and reporting-b.opsmgr.com and ensure they are alive. Use whatever method you think is best.

Configure Management Group

1. Launch the operations console and go to Administration / Settings / Reporting and enter the new reporting URL, in this case, http://reporting.opsmgr.com

2. On both Reporting Servers, restart the SQL Reporting service.

One area I need to do a little more testing is what services truly are required to be restarted. As you can see, I restarted all services for simplicity.

At this point, should either reporting servers fail, service will not be disrupted. You may have noticed this is very much like implementing a highly available, load balanced web solution. SQL 2005 Reporting Server, at a simple level, is just that, a web service. If the data warehouse fails, it already resides on a cluster.

Script: List all Performance Monitors & their Thresholds

Wed, 23 Jul 2008 16:35:16 GMT

Courtesy of Brain Wren: http://blogs.technet.com/brianwren/

Initiate Maintenance Mode from an Agent (no extras installed)

Wed, 23 Jul 2008 16:33:26 GMT

Courtesy of Derek Harkin: http://derekhar.blogspot.com/2008/02/initiate-maintenance-mode-from-agent-no.html

OpsMgr 2007: The Operations Manager 32-bit agent is supported on 64-bit Operating Systems

Wed, 23 Jul 2008 12:40:37 GMT

http://blogs.technet.com/smsandmom/archive/2008/07/22/opsmgr-2007-the-operations-manager-32-bit-agent-is-supported-on-64-bit-operating-systems.aspx | Comments

I get asked this every once in a while and since I couldn't find it mentioned anywhere I thought it might be a good idea to post it here. Under certain circumstances it may be necessary to install the OpsMgr 32-bit agent on a 64-bit operating system to monitor a 32-bit application. This is a supported configuration but the 32-bit agent must be installed manually and both the 32-bit and 64-bit OpsMgr agent cannot be installed simultaneously. It may also be necessary to install the OpsMgr 32-b

SQL Reporting Services error browsing localhost/reports "The XML page cannot be displayed"

Wed, 23 Jul 2008 12:39:08 GMT

http://CameronFuller.spaces.live.com/Blog/cns!A231E4EB0417CB76!1416.entry | Comments

SQL Reporting Services error browsing localhost/reports “The XML page cannot be displayed”

I ran into a new issue during a recent installation of System Center Operations Manager 2007 on Windows 2003 with SQL 2005 SP2. I’m not sure if it was the order of what prerequisites were applied, or some other spatial anomaly, but the end result was an inability to install the reporting components for Operations Manager 2007. As a background, checking to make sure that the two sql reporting services websites function is a really good idea before attempting to install the OpsMgr reporting components. Checking the likely issues I browsed to http://localhost/reportserver and http://localhost/reports on the server I was trying to install the OpsMgr components.

The reports website was failing with a new error: “The XML page cannot be displayed”.

After digging through search engines and trying a variety of different methods to resolve the problem, I found that the following fixed the website:

· From the command prompt, moved into the c:\windows\microsoft.net\framework64\v2.0.50727 directory (this was occurruing on a Windows Server 2003 x64 platform so the framework was in the framework64 directory versus the framework directory for x86 systems)

· Ran an aspnet_regiis –u (to remove the v2 version of asp.net)

· Ran an aspnet_regiis –i (to re-add the v2 version of asp.net)

· Ran an iisreset to reset the websites, and re-browsed to the http://localhost/reports and http://localhost/reportserver directories.

The reports virtual was now working correctly. I ended up also needing to use the Reporting Services Configuration tool to apply the default settings to the Report Server Virtual directory to get the http://localhost/reportserver virtual working. Within the Reporting Services Configuration tool check for any errors. It should be green for the Server Status, Report Server Virtual Directory, Report Manager Virtual Directory, Windows Service Identity, Web Service Identity, Database Setup, Initialization and Execution Account. It was blue for my SharePoint Integration and Encryption Keys, and yellow for my Email Settings.

Once this was done, the installation of the reporting components for Operations Manager 2007 installed without an issue.

Windows Server 2008, Windows Firewall and SQL 2005

Wed, 23 Jul 2008 12:38:38 GMT

http://CameronFuller.spaces.live.com/Blog/cns!A231E4EB0417CB76!1427.entry | Comments

Windows Server 2008, Windows Firewall and SQL 2005

Several of us were building out a POC Configuration Manager 2007 environment which had a single ConfigMgr server and a separate SQL 2005 database (shared with Operations Manager). The ConfigMgr server was running on ConfigMgr 2007 SP1/Windows Server 2008 and the SQL Server was running SQL 2005 SP2/Windows Server 2008. ConfigMgr server would not pass the prerequisite checks because it could not connect to the SQL Server.

Prior to making any changes, the ConfigMgr server could ping the SQL Server but we could not connect via the SQL Administration tools. Debugging on this consisted of pinging the SQL server and trying to telnet (we had to install the feature through the Server Manager application on the ConfigMgr server so that we could use the telnet to test this connectivity). We were unable to connect on port 1433 via telnet from the ConfigMgr server, and validated that the SQL server could connect to itself with “telnet localhost 1433”.

So, logically enough it looked like the Windows Firewall was blocking the connection to the SQL Server from the ConfigMgr Server. As a background, the Windows Firewall on Windows Server 2008 is activated by default as shown below.

To attempt to get communication, we did a stop of the Windows Firewall service on the SQL Server (net stop “Windows Firewall”). Little did we know what a mistake this was. Once this change was made we could no longer ping from the ConfigMgr server to the SQL Server. The SQL Server could however ping other systems on the network. So communication to the SQL Server was restricted (inbound) but communication from the SQL Server was not restricted (outbound). Once we started the Windows Firewall service on the SQL Server, we could ping from the ConfigMgr server to the SQL Server.

With the Windows Firewall service running on the SQL Server we did a port scan against the SQL Server (using the Advanced Port Scanner which is a great tool). The results were five open ports which were detected as shown below (ports 53, 88, 135, 139 and 445).

After we started the Windows Firewall service on the SQL Server we re-ran the port scan against the SQL Server. The results confirmed a sinking suspicion. No open ports were detected as shown below when the Windows Firewall service was shut down.

When we changed the firewall state to off (see the first graphic for where this is turned on/off), we could then successfully ping from the ConfigMgr server to the SQL Server and we could now connect on port 1433.

As additional roles are added in Windows 2008, changes are made to the firewall rules to allow the new role to function. SQL 2005 is not a role, and doesn’t make firewall changes so this makes sense. One of the big benefits to Windows Server 2008 is the new firewall functionality, so it is not a optimal to shut down this function. To get SQL 2005 to be able to be remotely connected to via the ConfigMgr server we created a new Inbound rule which allowed port 1433 access for TCP as shown below (the new rule is highlighted below).

Once the new rule was in place, we could connect from the ConfigMgr server to the SQL server on port 1433 even when the Windows Firewall was running.

Lessons learned:

1) Do NOT stop the Windows Firewall service either via commandline (net stop “Windows Firewall”) or via the services (services.msc). Stopping this service while the firewall is still active locks down all inbound communication. If you need to disable the Windows Firewall use the Server Manager application –> Configuration –> Windows Firewall with Advanced Security, right-click and go to properties. Change the firewall state to Off.

2) For SQL 2005 Servers running on Windows 2008, either disable the Windows Firewall (not preferred) or add a rule which allows inbound access to port 1433 (recommended) so that remote servers can communicate with the SQL Server database. If instances are used, a rule will need to be defined for the port of each instance.

Auditing on Alerts from the Data Warehouse

Tue, 22 Jul 2008 01:45:34 GMT

http://blogs.technet.com/kevinholman/archive/2008/07/21/auditing-on-alerts-from-the-data-warehouse.aspx | Comments

Do you want auditing information on how many alerts are being closed or modified by your OpsMgr users?

You can use the following queries to get this information from the data warehouse, and I have attached some reports below as well:

To get all raw alert data from the data warehouse to build reports from:

select * from Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.alertguid = adt.alertguid
inner join Alert.vAlert alt on ars.alertguid = alt.alertguid

To view data on all alerts modified by a specific user:

select ars.alertguid, alertname, alertdescription, statesetbyuserid, resolutionstate, statesetdatetime, severity, priority, managedentityrowID, repeatcount
from Alert.vAlertResolutionState ars
inner join Alert.vAlert alt on ars.alertguid = alt.alertguid
where statesetbyuserid like '%username%'
order by statesetdatetime

To view a count of all alerts closed by all users:

select statesetbyuserid, count(*) as 'Number of Alerts'
from Alert.vAlertResolutionState ars
where resolutionstate = '255'
group by statesetbyuserid
order by 'Number of Alerts' DESC

In the reports I have attached, you can pick a date and a time window, and run these same basic queries

Files attached below:

This post contained the following enclosures and/or attachments:

http://blogs.technet.com/kevinholman/attachment/3092141.ashx

NewsGator Inbox can be configured to automatically download attachments if you wish. For more information, please refer to the NewsGator Inbox help file (NewsGator Inbox > Help)

Windows PowerShell in System Center Operations Manager

Mon, 21 Jul 2008 11:50:25 GMT

http://www.systemcenterforum.org/windows-powershell-in-system-center-operations-manager/ | Comments

Powershell MVP Marco Shaw has written an excellent article on the Command Shell in Operations Manager 2007. Of particular interest are his review of agent deployment from the Command Shell in SP1, as well as the bulk installation of management packs from the Command Shell.

Read the full article at

http://technet.microsoft.com/en-us/magazine/cc671178.aspx

Sealing a Management Pack

Sun, 20 Jul 2008 13:16:23 GMT

http://wmug.co.uk/blogs/aquilaweb/archive/2008/07/03/sealing-a-management-pack.aspx | Comments

By default when you create a new management it is created as unsealed so it has a .xml extension and allows for the management pack to be edited. Within the support tools of Operations Manager there is a tool called mpseal.exe which can be used to seal the management pack so it can not be edited but still allow for customization of the applied settings with the use of overrides in seperate management packs. This can be very useful if distributing out to third parties. To seal a management pack i