Operations Manager: Operations Manager 2007

A question from Andy Howell regarding Synthetic Transactions

Mon, 06 Oct 2008 14:47:07 GMT

The following message was posted as an email to this blog last Thursday:

In Operations Manager 2007 Unleashed, you say that it is possible to create synthetic transactions using VBscript. You go on to work through a few examples of synthetic transactions based on pre-defined templates in Operations Manager. As part of this, you describe how to use watcher nodes to run these transactions.
Unfortunately I've not been able to find many examples of people who are actually doing this, so I'm turning to your site in desperation. I have an FTP server and need to prove that I can establish a connection and transfer a file to it. What I thought was the hard bit - I'm not a coder! - is done. A small VBscript establishes a connection, transfers a files and returns the status code to Operations Manager in a property bag.
What I'm struggling with is the simple bit: where to run it. I don't want to run it on the FTP server itself, as this wouldn't prove anything. Ideally I would like to use a watcher node, but I can't find a way to do this without using one of the pre-defined templates for synthetic transactions, none of which allow me to run my own VBscript. Am I missing something obvious?
By the way, and regardless of whether you can answer this post or not, System Center Operations Manager 2007 Unleashed is a truly excellent book. In my 12 year career I've read through many IT titles. This one really stands as an example of what a good IT book should be: it covers the theory, operation and real-life scenarios (for example database sizes) in just the right level of detail.
Andy

Unfortunately, Andy's communication preference settings don't allow us to respond to him, and we would like some additional details as we may need to have him try some things.

Andy, can you email ops-mgr@hotmail.com with an email address that we can reply to? Thanks!

X-Plat: The OpsMgr Gateway to Linux in the Datacenter

Mon, 06 Oct 2008 14:12:31 GMT

At MMS 2008 last May, Microsoft announced their direction to use Operations Manager to manage non-Windows systems (for more information, see Kerrie’s articles “Of Flying Pigs” at http://www.networkworld.com/community/node/27600 and “The Dynamic Datacenter” at http://www.networkworld.com/community/node/27354). This article discusses our experiences testing a beta version of the (Cross Platform) X-Plat software.

The Conventional OpsMgr Gateway Role

Let’s say you have computers at a branch office, in the offices of a partner or customer, or in a datacenter that resides on an untrusted and/or unconnected network. You put an OpsMgr gateway server on that remote network and connect it to your main OpsMgr management group with certificate-based authentication. Cool technology, and you are now monitoring those remote systems from your main location without standing up any new connectivity and potentially increasing the attack surface.

New OpsMgr/X-Plat Gateway Scenario

Before Microsoft introduced the Cross-Platform beta 1 refresh, you could not leverage that secure yet lightweight OpsMgr gateway service for monitoring any Linux computers at your remote location with anything more than a basic SNMP heartbeat. This article reviews this new feature of the Microsoft System Center Operations Manager 2007 Cross Platform Extensions Public Beta 1 Refresh. The software allows OpsMgr gateway servers to discover and fully manage non-Windows computers at remote network locations. This capability opens a new market for Operations Manager with a novel solution to extend management to Linux and other X-Plat systems such as HP-UX or Solaris and even AIX, which were previously out of reach of native System Center tools.

Note: We review here the second released beta for X-Plat. Features and function will change in the released product. Microsoft plans to release X-Plat as part of an update to OpsMgr in 2009.

Demo environment

An OpsMgr management group with Internet-facing gateway servers includes a gateway server at a remote datacenter. All gateway servers trust the same Certificate Authority (CA) and use unique identity certificates issued by the mutually trusted NOC CA for encryption and authentication. There is a Red Hat Enterprise Linux server (RHEL) at the remote site. We want to use the gateway server to monitor the Linux server from the NOC.

Here are the steps we took to discover and manage the RHEL box at the remote datacenter:

Install the X-Plat extensions on a selected management server and consoles. The official name of the installable is “System Center Operations Manager Cross-Platform Extensions.” Prerequisites include OpsMgr 2007 SP1 and WS-Management (WS-Man) 1.1.

Something we liked a lot is that you don’t need to touch the RMS or any high-value management servers to use X-Plat. You only need to install X-Plat extensions on the management server you will run the discovery wizard from.

There are 32-bit and X64 versions of X-Plat, and also full server and console only versions (a total of four .MSI files to select from). Install the console-only executable on other OpsMgr consoles you will use to monitor the cross-platform systems from.
Import the desired X-Plat management packs. The server X-Plat extensions setup defaults to dumping about 14 management packs (for all the operating systems supported by X-Plat) to the %programfiles%\System Center Management Packs folder. You only need to import the libraries and management packs needed to manage your target systems. To manage the RHEL 5 box, we imported these management packs:
- WS-Management Library
- Linux Operating System Library
- Unix View Library
- Red Hat Operating System Library
- Red Had Enterprise Linux Server 5 Operating System management packs
Run ImportXSLT.cmd on those computers where you installed the X-Plat extensions (management server and consoles). This small step changes how the task output and diagnostic and recovery messages generated by Health Explorer on Unix and Linux computers are displayed. This step has to take place after the X-Plat management packs are imported or you will receive an error.
Install the X-Plat extensions on the gateway server. Repeat the installation, similar to the management server. An additional step is that we create a UnixAgents folder in the AgentManagement folder of the gateway server. Extract the UnixAgents.zip that comes with X-Plat to that folder. When the gateway pushes the agent to the Linux server at the datacenter, the Linux bits will come from that folder.
Configure the management group Run As Accounts. There is some manual work for the OpsMgr administrator to let the X-Plat extensions on the gateway server know what the credentials are to access the Linux computer.
1. In the Administration -> Security -> Run As Accounts node of the Operations console, create two new Run As Accounts of the Basic Authentication type. One is a normal user account on the Linux computer and one is a privileged account. For the demo, we used the same root account and password for both Run As accounts. Name the accounts something that identifies them with the gateway server.
2. In the Security -> Run As Profile node, locate the Unix Privileged Account and associate it with the privileged Run As Account and the target of the gateway server with X-Plat Extensions. Similarly, associate the Unix Action Account Run As Profile with the normal user Run As Account and the target of the gateway server.
3. This beta release of X-Plat extensions only provides for a single pair of Run As Accounts per management server or per gateway server that performs the discovery and monitoring. To monitor other Linux computers with different sets of credentials requires an additional management server or gateway server for each set of credentials. This is a product limitation we hope is overcome in future releases.

Discover and accept the Linux server from the management server. This is just like using the Discovery Wizard from the Administration space of the Operations console, except you launch the X-Plat discovery process from the Overview page of the Cross Platform management pack in the Monitoring space. (In later releases X-Plat discovery is expected to migrate to the Administration space and integrate with Windows computer and network device discovery.)
- An issue with this beta release of X-Plat is that support for discovery of the most current versions of some Linux distributions isn't there. In our environment where the demo Linux computer is located, datacenter security polices require Linux distributions be kept current.
  While RHEL 5.2 is the current release, X-Plat only discovers up to RHEL 5.1. (Our hope and assumption is that the RHEL 5.1 agent will work on 5.2.) We expect that with future releases of X-Plat, there will be a community effort to keep X-Plat management packs updated with discovery support for more versions and releases.
  There is a manual install option for the X-Plat agent, which in this case would be as follows (the RPM file can be found in the UnixAgents folder on the gateway server):
  
  rpm -i scx.1.0.1-151.rhel.x86.rpm
  
  Another solution that enables use of the automatic discovery and integrated features of the X-Plat management packs is to 'trick' the discovery into thinking that the RHEL 5.1 version is installed on the target computer. We used this method, and pushed the version RPM file for 5.1 to the target computer running RHEL 5.2 with this command:
  
  rpm -i --force redhat-release-5Server-5.1.0.2.i386.rpm
  
  The --force switch is used since there is a file version downgrade. That RPM file is part of the RHEL 5.1 Server distribution. To later restore the RHEL 5.2 version file, it's enough to run the command "yum update redhat-release-5server" for the single package, or "yum update" to update any other pieces with patches since it was installed.
- Perform the discovery from the console of a management server where X-Plat Extensions is installed. You need privileged access to the Linux server to push the agent. If you don’t have a superuser account, you need to provide the root user password. After you specify the IP address and privileged account information for the target, if the computer is discoverable, it will shortly appear as seen in this screenshot of the Select Computers to Manage step in the Unix and Linux Computer Management Wizard:

After approving the discovered Linux computer, the gateway server uses SSH to push the System Center Cross-Platform (SCX) agent to the /tmp folder of the Linux computer. After a few minutes you can query the state of the two services that are started by the SCX agent. See this screen shot of an SSH session from the gateway server to the managed Linux server, confirming that the WS-Man daemon and the CIM server are up:

Managing Red Hat Linux with Operations Manager

Soon after completing these actions, the RHEL computer appeared in the Linux Servers state view of the OpsMgr console. Next, data started appearing in the memory and processor-related views. Some hours later, the disk and network views were populated. We received some alerts regarding invalid SSH authentication attempts, and we immediately had a solid feeling about our ability to really manage Linux boxes from Windows with OpsMgr.

Here is a screenshot of an alert related to security of the SSH services on the RHEL box:

An Internet-facing web server is going to get a lot of intrusion attempts against any open service. We secured the SSH services on the RHEL box with these host rules (and the alerts stopped!):

Edit /etc/ssh/ssh_config
1. “vi /etc/ssh/ssh_config”
2. Press “i” to allow modification of file contents

Modify line to restrict SSH protocol to version 2
1. Locate line “# Protocol 2,1”
2. Remove “#” from beginning of line, and “,1” from end of line.

Save the file

Modify hosts.deny file to deny all hosts access to SSH
1. “Vi /etc/hosts.deny”
2. Press “i” to allow modification of file contents
3. Add this to the next available blank line: “sshd: ALL”
4. Press “:wq” and press enter

Modify hosts.allow file to permit specific hosts to connect via SSH
1. “vi /etc/hosts.allow”
2. Press “i” to allow modification of file contents
3. Add this to the next available blank line: “sshd: <ip address of permitted host> <ip address of permitted host> …..” (…. = etc, not literal)
4. Press “:wq” and press enter

Monitoring Views

The next screenshot expands all the branches in the Cross Platform Servers view folder (left) created when you import the X-Plat management packs for Red Hat Linux. Focus (right) is on a 24-hour performance view of Physical Disk target “sda” in the RHEL server.

Reports

When you select a Linux server in the Linux Server State view folder, in the Actions pane you will see a dozen targeted Unix Computer Reports available for on-the-fly generation. Here is the 7-day Memory Performance History (Pages per Sec) report for the RHEL computer:

Distributed Application Possibilities

X-Plat Extensions creates OpsMgr objects for monitored components of discovered Linux computers. This expands the universe of objects available to create Distributed Applications (DAs) to include Linux disks, processors, network interfaces and the like.

We created a DA that contains two components of classes Windows 2008 Logical Disks and Linux Logical Disks. This DA represents the health of the logical disks of all the web farm members, regardless of their OS.
Relationships are defined as Web Server Farm Logical Disks Uses Linux Logical Disk and Web Server Farm Logical Disks Uses Windows 2008 Logical Disk. See the screenshot of the DA below, open in the Distributed Application Designer:

True Cross-Platform Performance Monitoring

By creating a Performance view that targets the DA we created, we can assess aggregated logical disk performance across Windows and Linux members of a web server farm in a remote data center. Now we have "apples to apples" metrics in the same pane of management glass! See this screenshot of X-Plat in full motion:

Remote Task Execution

A final systems management value-add we find in the current X-Plat release is a small collection of Unix Computer Tasks, which are available in both the Operations console and Web console. These tasks are:

Run VMStat (a short report on virtual memory statistics, paging block I/O, traps, system and CPU usage),\
Memory Information (paging and swap data)
Top 10 CPU Processes

In this screenshot we demonstrate listing the top 10 CPU processes on the Linux server:

Contributors: Thanks to Jacob Linscott, Linux Guru at datacenter provider Softlayer for help on the RHEL versioning; and to Kevin Clark, NOC Manager at managed services provider ClearPointe for the command list that secured the SSH service.

OpsMgr by Example: Server 2008 POC – Part 5 (Reporting Server)

Thu, 28 Aug 2008 16:30:03 GMT

This is the final of a five part series discussing lessons learned through installing System Center Operations Manager onto a fully Windows 2008 environment (DC, RMS, SQL, and Reporting servers). You can see previous posts in this series at:

http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!695.entry OpsMgr by Example - Server 2008 POC – Part 1 (Domain Controller)
http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!710.entry OpsMgr by Example - Server 2008 POC - Part 2 (Database Server)
http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!719.entry OpsMgr by Example - Server 2008 POC - Part 3 (Root Management Server)
http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!728.entry OpsMgr by Example - Server 2008 POC – Part 4 (Data Warehouse Server)

At this time, we have successfully completed all of the required pieces of the environment other than the reporting components. This post discusses installing the Reporting Server on Windows Server 2008. The Reporting Server installation is definitely the most error-prone part of the entire OpsMgr installation, be it on Windows 2003 or Windows 2008.

Hotfixes for OpsMgr 20007 – Windows 2008 Servers with Agents

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

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

OpsMgr Prerequisites

The .NET Framework 3.0 components are not installed by default. You can install these in the Server Manager by adding the Application Server role.

Prior to installing the reporting components for Operations Manager, follow the steps identified in KB article 938245 (http://support.microsoft.com/kb/938245/) to configure reporting services on Windows Server 2008.

Do not attempt to install the reporting components on a system until you can successfully browse to both http://localhost/reports and http://localhost/reportserver on the reporting server. Configuration is required within the Reporting Services Configuration. Browsing of either of the above URL’s will not work until the Reporting Services Configuration is working, we display a functional example below. During our configurations we needed to create a new Report Server Virtual Directory, configure the Database Setup section, and perform an IISReset of the website to get it to a green state for the first six items, as shown in this screenshot:

A successful browse of http://localhost/reports and http://localhost/reportserver will look like this:

Do not pass go, do not collect $200/We spent several hours trying to resolve issues that were actually related to configurations necessary for SQL 2005 Reporting Services to work on Windows Server 2008. Installing the reporting components on a system that does not already have functional reporting services will just make the situation worse.

The prerequisites for the Reporting Server component include SQL Server 2005 with Reporting Services (which in turn requires the Web role, etc) with SQL 2005 Service Pack 2 applied.

OpsMgr Reporting Server installation

The installation of Operations Manager’s Reporting Server worked just the same as on a Windows 2003 platform (once the prerequisites had been configured correctly).

What’s Next?

Validate reporting functionality both from the existence of the reports and the ability to get valid data from the reports (the Management Pack ODR report is a simple one to validate this with).
Deploy Operations Manager agents into the environment.
Integrate additional management packs.
Wait on official support for Windows Server 2008 as a platform for all of the Operations Manager components.

Lessons Learned

It is possible you will get an error "Unable to connect to the remote server" when browsing to http://localhost/reports or http://<servername>/reports. For steps on how to address this, check out http://r0nwilliams.spaces.live.com/blog/cns!62A0019E9E556103!190.entry.
Without question, getting SQL 2005 Reporting Services working on Windows 2008 was the most complex piece of the installation. Focus on getting a functional SQL Reporting server before continuing (see http://support.microsoft.com/kb/938245/ for details).

OpsMgr by Example: Server 2008 POC – Part 4 (Data Warehouse Server)

Mon, 25 Aug 2008 14:28:29 GMT

This is the fourth of a five part series discussing lessons learned through installing System Center Operations Manager onto a fully Windows 2008 environment (DC, RMS, SQL, and Reporting servers). You can see previous posts in this series at:

http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!695.entry OpsMgr by Example - Server 2008 POC – Part 1 (Domain Controller)
http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!710.entry OpsMgr by Example - Server 2008 POC - Part 2 (Database Server)
http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!719.entry OpsMgr by Example - Server 2008 POC - Part 3 (Root Management Server)

We previously installed and configured the Operations Manager database and the Root Management Server (see parts 2-3 of this series). The next step is installing the Data Warehouse server, followed in Part 5 by the series, which discusses the most difficult of the steps – the reporting server installation.

Hotfixes for OpsMgr 20007 – Windows 2008 Servers with Agents

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

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

OpsMgr Prerequisites

The prerequisites were checked for the Data Warehouse in part 2 of this article (http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!710.entry), since the same server is hosting both the Operations database and the Data Warehouse components in this environment.

OpsMgr Data Warehouse installation

The installation of Operations Manager’s Data Warehouse worked the same as on a Windows 2003 platform.

Firewall change

The SQL firewall change discussed in part 2 of this series (http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!710.entry) provides the documentation for the firewall rule change required to allow connectivity to the SQL Server.

Lessons Learned

There were no surprises when installing the Data Warehouse server on Windows Server 2008.

OpsMgr by Example: Server 2008 POC – Part 3 (Root Management Server)

Thu, 21 Aug 2008 13:31:40 GMT

This is the third of a five part series discussing lessons learned through installing System Center Operations Manager onto a fully Windows 2008 environment (DC, RMS, SQL, and Reporting servers). In this post, we will install and configure the Operations Manager Root Management Server (RMS), as we now have a functional Windows 2008 SQL Server (see Part 2 of this series at http://ops-mgr.spaces.live.com/blog/cns!3D3B8489FCAA9B51!710.entry).

Hotfixes for OpsMgr 20007 – Windows 2008 Servers with Agents

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

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

Additional hotfixes are required that are specific to the servers with installed OpsMgr components. These include:

OpsMgr Prerequisites

There are several prerequisites for installation of the Root Management Server (plus the console and the web console).

With Windows 2008, we need to add the Web Server role (including ASP.net, windows authentication, IIS 6.0 management compatibility and ASP). For background on this, we worked from the article on how to install and configure reporting services on Windows Server 2008 available at http://msdn.microsoft.com/en-us/library/bb839480.aspx.
Using the Application Server role adds the .Net framework components.
We ended up installing the Windows PowerShell via a command line (ServerManagerCmd –i Powershell).

OpsMgr RMS, Web Console, Console Install

Installing the Operations Manager’s RMS, Operations Console and Web Console components worked just the same as on a Windows 2003 platform. The only item to note is if the RMS cannot contact the OpsMgr database server, it will display this error:

Check out the video showing the installation steps:

Firewall change

The RMS installation made the required changes for the Windows 2008 firewall. These included the following ports:

Health Service (5723)
SDK (5724)
Web Console (51908)Application Error Monitoring (51906)
Connector Framework (51905)
Customer Experience Improvement Program (51907)

Lessons Learned

Windows Server 2008 now installs as roles several of the prerequisite components required for OpsMgr.
The Windows 2008 firewall creates the appropriate firewall rules to allow OpsMgr to function on the system.

OpsMgr 2007 - Its all about uptime

Wed, 20 Aug 2008 14:11:05 GMT

A while back, Kerrie wrote a post about downtime and managing IT Operations at http://www.networkworld.com/community/node/20187. As a follow-up to that, she just participated in a blog interview with StackSafe about IT Operations and how Operations Manager can help you in managing your downtime (and uptime!). Check it out at http://www.stacksafe.com/blog/kerrie-meyler-a-microsoft-mom-mvp-dishes-about-it-operations/08/19/2008/.

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

Mon, 18 Aug 2008 06:21:14 GMT

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

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

Thu, 14 Aug 2008 16:47:49 GMT

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.

Adding Network Devices with PowerShell - a question on the blog

Thu, 31 Jul 2008 13:03:12 GMT

We received a question from someone whose mail settings did not allow a reply (see http://ops-mgr.spaces.live.com/default.aspx?_c01_BlogPart=blogentry&_c=BlogPart&handle=cns!3D3B8489FCAA9B51!541). The question was:

I have a small question about "Adding Network Devices with PowerShell" that you write about in your book.
In your example you connect NetworkDevice to $agent add-remotelymanageddevice -proxyagent $agent -device $discovery_results.custommonitoringobjects
But how I can connect NetworkDevice to Management Server (it's not in get-agent output)?

The answer:

Adding a network device to management with PowerShell does not require that you furnish the name of a management server. If we understand your question correctly, you asked about 'connecting NetworkDevice to Management Server.'
Let's explain the PowerShell cmdlet used in the eighth and final cmdlet in a series of cmdlets in our Powershell script that together assemble an array of inputs, and feed those inputs to the last cmdlet.
The add-remotelymanageddevice cmdlet is fed only the inputs -proxyagent and -device.
The involved management server will be the primary management server associated with the proxy agent--but that is not part of the action of adding the network device to management. We only need the name of the proxy agent.

The Discover-and-Add-Network-Devices.ps1 is a PowerShell script for discovering and adding network devices. It was developed in conjunction with Chapter 17, "Monitoring Network Devices," of System Center Operations Manager 2007 Unleashed.

OpsMgr and Anti-Virus Configurations

Tue, 22 Jul 2008 03:17:11 GMT

SUMMARY

Most organizations run anti-virus (AV) software on their servers and workstations to detect and fix computer viruses. However, running antivirus software on server software systems such as Operations Manager can cause data corruption and have a detrimental effect on performance.

MORE INFORMATION

There are particular folders and files that should be excluded from anti-virus scanning.

These include the SQL Server database files used by Operations Manager components as well as system database files for the master database and tempdb.
You will also want to exclude queue and log files used by Operations Manager from anti-virus scanning.
These include but are not limited to files under %ProgramFiles%\System Center Operations Manager\Health Service State\ and its subdirectories.
Other areas to exclude from scanning is the OpsMgr install and wbem directories.
You will want to exclude the page file from anti-virus scanning and the Windows temp directory (%windirtemp%) as well.

If you use a firewall, you will need to open up the ports for installing the agent (135), client communication (5723), email communication (25), and potentially others. The ports used by Operations Manager 2007 are listed in Table 1.

Table 1. Communication Paths and Ports

From Component	To Component	Bidirectional?	TCP Port
Root Management Server (RMS) or Management Server (MS)	Operational Database (Ops DB) and Data Warehouse (DW DB)	No	OLEDB 1433 (SQL); in a cluster the second node requires a unique port number
RMS	MS or Gateway Server	Yes	5723
Operations console	RMS	No	5723
Agent	RMS, MS, or Gateway	No	5723
Reporting Server, Web Console Server	RMS	No	5724
Connector Framework Source	RMS	No	51905
Agentless Exception Monitoring (AEM) Client	AEM file share on RMS or MS	Yes	SMB 445, 51906
Software Quality Metrics (SQM) Client	SQM Endpoint	No	51907
Web console	Web Console Server	No	HTTP 51908
Audit Collection Services (ACS) Agent	ACS Collector	Yes	51909
ACS Collector	ACS DB	No	OLEDB 1433 (SQL)
Reporting Server	DW DB	No	OLEDB 1433 (SQL); in a cluster the second node requires a unique port number
Operations console	Reporting Server	No	HTTP 80

UPDATE 7/21/08: Rod Trent recently posted an article on recommended antivirus exclusions, see http://myitforum.com/cs2/blogs/rtrent/archive/2008/07/18/recommended-antivirus-exclusions-for-opsmgr.aspx.

OpsMgr Answer This: Do I use classes or groups?

Tue, 15 Jul 2008 15:07:09 GMT

We continue our "OpsMgr Answer This" series with a discussion on the new class-based architecture in Operations Manager 2007.

To focus the topic on specific questions, we looked at the following areas:

When I select to override a rule or monitor, I can select to target all objects of a class, or all objects in a group. If I have a choice of either (because the objects I am interested in are included in both one or more classes and one or more groups), which should I select?

You would select class. By default, discoveries are targeted at a class; therefore as new objects are added, they will inherit the override. This can be accomplished with groups but discovery will take longer as group membership needs to be calculated also.

When I am authoring a management pack, and I want to pre-define how overrides are targeted, is there a performance or feature difference in selecting either classes or groups?

Again, you will want to select class. Targeting groups will prevent you from using DAs (distributed applications) properly. Say you have a monitor targeted at a class, you can add this class to a DA and have its health state roll up.

So when should I use groups over classes?

A situation where targeting groups is easier to administer is when you want to leverage the ability to quickly add and exclude objects from a group using the Authoring space of the Operations console. It's not so easy to change the membership of a class.

Microsoft provides a video to clarify how targeting a monitor and a group works. The video is available at http://www.microsoft.com/winme/0712/31678/ClarifyTargetingAtGroups_300kbps.asx and is just over a minute long. They have also developed a "poster" of best practices for Rule and Monitor targeting which you can view at http://download.microsoft.com/download/f/a/7/fa73e146-ab8a-4002-9311-bfe69a570d28/BestPractices_Rule_Monitor_REV_110607.pdf. The poster is about 5MB in size.

Key points of the poster:

Always target classes unless the objects of interest are only defined by a group
Always target the most specific class possible - for example, the Windows 2003 Operating System if all targets are Windows Server 2003, rather than targeting Windows Computer or Windows Server Operating System
When you target groups, create a disabled monitor and then enable the monitor for the group.

UPDATE

Here are some other interesting links and additional tidbits (courtesy of Jason Sandys who is helping with the System Center Configuration Manager 2007 Unleashed book):

Computer groups cannot per used to target monitors and rules (http://blogs.technet.com/momteam/archive/2007/11/14/targeting-series-part-2-why-targeting-a-computer-group-fails.aspx ), but they can be used to target overrides (http://systemcenterforum.org/wp-content/uploads/OpsMgr_overrides.pdf ).
Normal groups can be used for either targeting scenario depending on the actual objects that are members of the group. This leads to the conclusion that targeting rules and monitors is completely different from targeting overrides - and it would have been nice if different terms were used for these two types of targeting, maybe filtering for overrides instead of targeting.
Targeting rules and monitors applies them to the actual object and when using the computer group, it actually targets the group object instead of the members of the group but not when using a regular group. Targeting (filtering) an override always filters based on the members of the group if one is used.

Do you have burning questions about OpsMgr 2007 you'd like us to answer as part of this series? Please submit those as comments to this article!

Moving the Root Management Server role - the ManagementServerConfigTool Utility

Fri, 11 Jul 2008 18:45:13 GMT

Chapter 12 of System Center Operations Manager 2007 Unleashed discusses ManagementServerConfigTool.exe as a tool to move the RMS component. Because of the unique role the RMS has in an OpsMgr 2007 management group, you always want to have a disaster recovery plan in place, in the event the server hosting the RMS becomes inoperable.

As part of that plan, be sure to backup the RMS encryption key (use SecureStorageBackup.exe, which runs automatically during OpsMgr installation in Service Pack 1), and have a current backup of your Operations database. If you need to transfer the RMS role, the tool that accomplishes this is ManagementServerConfigTool.exe.

In Chapter 12, we discuss the steps using the version of the tool available when the book was being written, which was prior to the current version. Let's talk a bit about how the tool works and some caveats.

The syntax on page 573, step 8, specifies

ManagementServerConfigTool.exe PromoteRMS /DeleteExistingRMS:true

If you have a clustered RMS, which many large installations have implemented, the /DeleteExistingRMS:true switch deletes the existence of the clustered virtual server from the Operations database. With SP1, it is not possible to create a clustered RMS after your initial management group installation, and this would prevent you from getting back to a clustered RMS later!

As an alternative, run the command without the /DeleteExistingRMS:true switch, so the syntax would be

ManagementServerConfigTool.exe PromoteRMS

This “demotes” the previous RMS to the role of a secondary MS. (If the switch is not specified, the tool by default uses /DeleteExistingRMS:false.)

With a clustered RMS, the RMS cannot be used in a secondary MS role - this is by design. In this scenario, running the Promote option puts the node in a temporary non-operational role, allowing\ it to remain in the database and be available for re-promotion when you are ready to put the clustered RMS back in its original role. In essence, you are demoting rather than deleting!

The tool generates the following warning:

Running this tool can cause irreversible damage to your Operations Manager DB. Please backup your DB before continuing. Continue the PromoteRMS action? (Y/N)

Hint: PLEASE be sure to have a backup!

If by accident you specified the /DeleteExistingRMS:true switch, stop the SDK service on the recently promoted RMS, restore the DB, then run the UpdateDemotedRMS action on the recently promoted RMS to set it back to a secondary MS role. This makes the clustered RMS the only machine in the RMS role in the Management Group.

Additional documentation is available at http://technet.microsoft.com/en-us/library/cc540401(TechNet.10).aspx.

The corrected syntax for the command is being published in the errata for System Center Operations Manager 2007 Unleashed, at http://www.informit.com/store/product.aspx?isbn=0672329557. Many thanks to Starr Parker of Microsoft for his help and insight!

Latest and Greatest MPViewer (Version 1.7)

Wed, 25 Jun 2008 12:50:20 GMT

Last week, Boris Yanushpolsky released MPViewer 1.6, which added exporting to Excel functionality. However, a programming bug caused the MPViewer to not be able to view the Exchange 2007 (also known as Exchange 12) MP in HTML (http://blogs.technet.com/stefan_stranger/archive/2008/06/25/goaaaal-mpviewer-with-export-to-excel.aspx), a feature Boris added last October.

Boris has corrected the issue and added some additional new features while he was at it - including frequency for performance viewers and breaking out monitors by type. You can get version 1.7 at http://blogs.msdn.com/boris_yanushpolsky/archive/2008/06/25/mpviewer-1-7-now-works-with-latest-e12-mp.aspx.

The MPViewer, a free utility (and not officially supported by Microsoft) displays what’s in a management pack before importing it. Boris posted the earliest versions of the MPViewer in October 1007 (http://blogs.msdn.com/boris_yanushpolsky/archive/2007/10/10/what-s-in-my-management-pack.aspx), and has been making numerous enhancements to it.

You can download Version 1.7 from http://blogs.msdn.com/boris_yanushpolsky/archive/2008/06/25/mpviewer-1-7-now-works-with-latest-e12-mp.aspx.

Hyper-V, OpsMgr and Unix? – Part 2

Wed, 18 Jun 2008 12:54:50 GMT

In Part 1 of this series, we discussed installing a Unix system in Hyper-V (see http://cameronfuller.spaces.live.com/blog/cns!A231E4EB0417CB76!1273.entry). In this article, we will take our Unix system and integrate it into Operations Manager using Cross-Plat (X-Plat) functionality. Our ultimate goal is to provide an environment with Microsoft virtualization technologies on 64-bit UNIX platforms, which we can then monitor using Operations Manager 2007.

Historically, OpsMgr 2007 has relied upon third party vendors to provide monitoring for non-Microsoft Operating Systems. With the addition of X-Plat, Microsoft can now provide out-of-the-box monitoring for a number of Unix-based Operating Systems. For information about the X-Plat announcement, see Kerrie's write-up at http://www.networkworld.com/community/node/27354. To summarize that article, the Microsoft-provided agent running on the Unix system is open source, and integrates seamlessly with the Operations Manager 2007 environment. The X-Plat extensions are currently available at Microsoft’s Connect beta site (http://connect.microsoft.com).

It is extremely important to note that all the software discussed here currently is NOT production-released code. These are RC and Beta versions of software only. Please do NOT install this configuration in a production environment, as it will not be supported software. This article is specifically an example of evaluating some of the potential upcoming functionality.

As background, we currently have a host system running Windows Server 2008 with Hyper-V. This environment includes a domain controller and OpsMgr server (RMS) along with a Unix (SLES 10.2, 64-bit) server.

Step 1: X-Plat download and Install

After downloading the X-Plat extensions from the Connect site and installing the X-Plat software (SetupSCX.msi), next step is to add the management pack(s) for X-Plat as shown below. As this was a test environment, we added all the Unix-related management packs, as shown in the following two screenshots:

Step 2: RunAs Accounts and RunAs Profiles

For details on how to configure the RunAs accounts and profiles, see the "Configuration of Run As Accounts and Run As Profiles" section in the SCX-PlatSetupGuide.doc. This document is part of the X-Plat (OpsMgr2007-CrossPlatform-Beta.zip) download on the Connect site.

Step 3: X-Plat Agent Deployment Debugging

With the management packs successfully installed, the next step is to install the agent on the Unix system. You can push agents with the Operations console in the Monitoring space. Navigate to the Monitoring -> Cross Platform Servers -> Overview section, as displayed below:

Starting the Wizard brings up a welcome screen that explains the function of the wizard.

The wizard begins with discovering the remote system. We can discover the system in several ways:

IP address
DNS name (as used in this example)
address range

Information required by the wizard includes

Providing credentials for the user name to deploy the agent
Specifying if the account is a superuser account
Providing the port number the Unix system has for SSH (port 22 by default)

In the screenshot below, we deployed the agent by its fully qualified name, specifying a full privilege account created on the Unix system, and using the default port of 22 to connect for SSH (which is used to deploy the agent to the Unix system).

The next screen shows the computers we will discover and deploy an agent to, and the configuration for those systems (this consists of the scope of the discovery, the SSH port, and the credentials to use). In this case we have specified a scope of 192.168.1.84, port 22, and credentials of Administrator.

The screen below indicates a successful discovery where the system was discovered, and then the attempt to deploy the agent. This is when our first issue was encountered: the agent failed to deploy to the Unix system.

Because the agent did not deploy, it was time to troubleshoot.

To troubleshoot, we tested connectivity from the OpsMgr server to the Unix server. The connectivity test used a telnet from the OpsMgr server to the IP address of the Unix system. The telnet failed; we then determined it was necessary to hard-code the name of the Unix system in DNS and/or the host file, and also shut down the firewall on the Unix system to enable port 22 to allow the SSH connection. We used the the YaST Control Center's Firewall Configuration panel to make these changes. The firewall was turned off, as shown below. Our changes enabled connectivity from the OpsMgr server to the Unix server on port 22 using the Unix server name.

After resolving the communication issues to the name/port of the Unix system, it was now time to deploy the agent. This required rerunning the wizard to complete discovery and start the deployment.

We thought we were in good shape, but this actually led to our next hiccup. In Part 1 of this series, we used a SLES 10.2 x64 system. This is NOT currently a supported platform. That “little” Oops hit at this point. OOPS!

After getting this far, the system could not actually be managed with OpsMgr, until Barry Shilmover of Microsoft gave us a good hint: A manual installation might work well in this situation.

Step 4: X-Plat Manual Agent Deployment

Our next step was to try manually installing the agent on the Unix system. Transferring data between these virtual machines was not simple! (See http://cameronfuller.spaces.live.com/blog/cns!A231E4EB0417CB76!1264.entry for reference.) The easiest approach was installing FTP on the OpsMgr server and placing the X-Plat installation file in the FTP site. For this system, the SLES 10.1 x86 version of the software was transferred to install, as shown in the next three screenshots (the agent installation was part of the UnixAgents.zip file).

After completing installation on the Unix system, we re-ran discovery on the OpsMgr server - which now could successfully start monitoring the Unix system, even though it was on an unsupported platform!

Step 5: X-Plat Integration with the Health Explorer

After our initial discovery of the system, the pieces of Health Explorer actually populated were rather limited. These included the Availability/Unix Heartbeat Monitor, and the Configuration pieces.

After a little while, additional sections started appearing (these are highlighted below in Red). The Operating System Availability Rollup and each of the core services were added, and the Performance counters started gathering data as well.

A while later, additional Health Explorer items started appearing. These included the Hardware Availability Rollup and the Hardware Performance Rollup sections, outlined in Red below.

One of the coolest parts of the X-Plat story is how seamlessly it integrates with OpsMgr 2007. The look and feel of the functionality is designed to look very similar to Windows Operating System monitoring. Some good examples of this include:

Performance / Logical Disk:

Performance / Memory Utilization:

Operating System Performance:

SUSE Diagram View:

If someone said earlier that this year we would be able to run a Unix x64 system within a Microsoft Virtualization environment and to use all Microsoft code to monitor it in Operations Manager 2007, it would have been laughable. However, it is working, and very close on the radar to being a publicly available solution!

Lessons Learned:

A few good lessons learned while doing this process:

Use the full documentation available as part of the Cross-Plat documentation, including the SCX-PlatSetupGuide.doc, and the Integration_Components_for_Linux_Read_Me.docx file.
Prior to trying to discover or deploy OpsMgr agents to the Unix systems, do a test telnet to the fully qualified name of the system using port 22. If the name does not resolve, either add a DNS entry and/or a host file entry for the fully qualified name of the system. Also, turn off the firewall on the Unix system as it is enabled by default.
Download a supported version of the Unix Operating System by verifying them with the documentation on both X-Plat and Hyper-V. At this point in time, the OS/version compatible with both products is SLES 10.1 x86.
Manual agent installation may work for platforms that are not officially supported. After installing those agents, they can be viewed within OpsMgr.

UPDATE: Ian Blyth wrote up a great article on CrossPlat, which is available at http://ianblythmanagement.wordpress.com/2008/06/24/xplat-part-2-the-install/.

The ProcessMonitor management pack in System Center Operations Manager 2007 Unleashed

Mon, 16 Jun 2008 17:45:12 GMT

The following question arose in the OpsMgr management packs newsgroup:

I have the SCOM Unleashed book (great book!) and imported their MP which among another things monitors Windows processes. However, it came with no instructions on how to actually use it except to configure it via overrides.

Has anyone figured out how to use this MP? Also, is it possible to monitor memory or total CPU time for a particular Windows process? I'd like to setup a rule that says something like if process application.exe has been running longer than x minutes, or memory usage is great than y, alert me.

Ok, here's how it works:

The ProcessMonitor is a "mini" management pack that runs a WMI query. The query performs a:

select * from Win32_Process Where Name = (the parameter passed by the script for the name of the process to monitor).

Any fields available within the Win32_Process WMI query should be easy to integrate with the script. The script itself can be found within the Operations console in the Authoring space. Navigate to Authoring -> Management Pack Objects -> Monitors. Then look within System Center Managed Computer (Any OS) -> Entity Health -> Availability -> ProcessMonitor. On the properties for the monitor, the script is available to be edited from the Script tab.

The fields that appear as available within Win32_Process are:

Caption
CommandLine
CreationClassName
CreationDate
CSCreationClassName
CSName
Description
ExecutablePath
ExecutionState
Handle
HandleCount
InstallDate
KernelModeTime
MaximumWorkingSetSize
MinimumWorkingSetWize
Name
OSCreationClassName
OSName
OtherOperationCount
OtherTransferCount
PageFaults
PageFileUsage
ParentProcessId
PeakPageFileUsage
PeakVirtualSize
PeakWorkingSetSize
Priority
PrivatePageCount
ProcessID
QuotaNonPagedPoolUsage
QuotaPagePoolUsage
QuotaPeakNonPagedPoolUsage
QuotaPeakPagedPoolUsage
ReadOperationCount
ReadTransferCount
SessionId
Status
TerminationDate
ThreadCount
UserModeTime
VirtualSize
WindowsVersion
WorkingSetSize
WriteOperationCount
WriteTransferCount

So there you have it!

Database Clustering, SQL Server Editions, and Operations Manager 2007

Sat, 24 May 2008 00:48:56 GMT

We've been asked in the newsgroups:
How does database clustering require enterprise edition? I still don't understand ... You can cluster with standard, if so that's clustering, correct? Other than having more nodes than two, are there any benefits, as they relate to the OpsMgr database itself that you gain by going to Enterprise Edition over Standard? Does it do re-indexing and stuff that may take it offline while jobs run, etc that warrant paying more for Enterprise?

Okay, here's how it works:

SQL Server Standard Edition supports up to two clustered nodes - and for the OpsMgr databases, those can be configured as active/passive
SQL Server Enterprise Edition supports up to 8 clustered nodes

The operating system in either case MUST be Windows Server Enterprise (or Datacenter) Edition.

One advantage of clustering - other than the obvious one for high ability when one node of the cluster goes down, is that it can be used to maintain the functionality of the database in situations such as patch management (this is in addition to maintaining availability when there are temporary outages).

Let's look at a creative way where you can use more than two clustered nodes. This scenario involves a 4-way Active/Active/Active/Passive configuration using SQL Server Enterprise Edition, where:

The first node would host the Operations database in the default cluster instance
The second node would host the Data Warehouse database in a second instance
The third node would host the ACS database in a third instance
The fourth node would be available to provide high availability in case of the failure of a node in the cluster

Assuming the boxes have a lot of memory, this enables you - using a single clustered implementation of SQL Server Enterprise Edition - to host all the databases used by OpsMgr (and ACS).

Now let's look at some specific advantages of using SQL Enterprise Edition in an ACS installation.

ACS supports the use of SQL Server 2005 Standard Edition and SQL Server 2005 Enterprise Edition. The version used impacts how the system behaves during the daily 2:00 AM database maintenance window while the ACS database is reindexed. During the maintenance window, any database partitions with timestamps outside the data-retention schedule (14 days in the default configuration) are dropped from the database. Keep the following points in mind:

If SQL Server 2005 Standard Edition is used, security event insertion halts and events queue up on the collector until maintenance is completed.
This is because SQL 2005 Standard Edition cannot perform online index operations, whereas the Enterprise Edition can.
If SQL Server 2005 Enterprise Edition is used, insertion of processed security events continues during the daily database maintenance, but at only 30%-40% of the regular rate.

SQL 2005 Enterprise Edition is probably mandatory in high-volume ACS environments because it reduces the chance of lost security events from filling the collector queue during the maintenance window.

The Operations database also has various maintenance tasks. This includes Discovery Data Grooming (2 AM), Partitioning and Grooming (12 midnight), Detecting and Fixing object space (every 30 minutes), and Auto Resolving Alerts (4 AM). These are in addition to a daily backup job you should schedule for all databases used by Operations Manager as well as significant system databases such as master and msdb (for more information on backups, see Chapter 12 of System Center Operations Manager 2007 Unleashed).

The Data Warehouse database also does optimizations, reindexing, and grooming.

SQL Server Enterprise Edition does not appear to be recommended for the Operations and Data Warehouse databases as strongly as Microsoft recommends it for ACS, due to the databases being maintained differently. However, based on your particular environment, you may discover benefits to using Enterprise Edition. Enterprise Edition is better able to handle querying large amounts of data (> 500 GB), which can make it valuable for the data warehouse component. Another example is that while SQL Standard can run on a maximum of 4 CPUs, Enterprise can handle 64 (based on the version of the OS that is running). Enterprise Edition also supports parallel index operations, parallel DBCC operations, table and index partitioning should you want to implement that, online index operations, and online page and file restores.

Microsoft has a scalability and performance comparison between the two versions available at http://www.microsoft.com/sql/editions/enterprise/comparison.mspx.

In the News ...

Thu, 22 May 2008 14:31:48 GMT

Lead author Kerrie Meyler has a recent podcast discussing the Operations Manager 2007 Unleashed book at http://www.cstechcast.com/home.aspx?Episode=25.

Kerrie also spoke with John Fontana of Network World discussing Microsoft's announcements for Operations Manager at MMS 2008, that article is available at http://www.networkworld.com/news/2008/051208-microsoft-management-plans.html.

Co-author John Joyner is on youtube discussing System Center 2007 with Intel vPro technology (see the second half of the 3-minute video) at http://youtube.com/watch?v=K3uUgWRjtdc.

Happy reading/viewing!

Data Warehouse SQL Server Authentication Account - response to email question

Thu, 22 May 2008 05:10:51 GMT

We received the following question via email from "Scott," but his settings did not allow us to respond to him via email.

First and foremost, great site! I've gotten more help here than from almost any other source. Which brings me to my question...

Where would be the best place to look for information on the Data Warehouse SQL Server Authentication Account? It looks like ours was changed from the default, and now we're in a down state. Any info you can point us to would be wonderful.

Thanks a million, and keep up the good work!!

Scott, if you have the OpsMgr 2007 Unleashed book, check pages 502-503 which discuss Data Warehouse database security. Check the Run As Profile for the Data Warehouse SQL Server Authentication account Run As Account and make appropriate changes to the Run As Account, which should get you back in business!

Hope this helps.

About the Essentials Management Pack for monitoring network devices in OpsMgr 2007

Fri, 16 May 2008 02:56:49 GMT

The following question was posted at Cameron's blog, cameronfuller.spaces.live.com:

I bought your book "SCOM Unleashed" , and I find it very useful. Thanks for that.

I tried to followed your advice by importing the SCE MP for the network devices for monitoring Cisco switches and routers. The import is successful, but I am unable to populate it. It seems that there is an error related to the discovery of the SNMP interfaces. Here is the error I see in OpsMgr event log:

Loading managed module type in assembly "Microsoft.EnterpriseManagement.SCE.Modules" with type name "Microsoft.EnterpriseManagement.SCE.Modules.SnmpInterfaceDiscovery" failed with error code "80FF0001" in rule "Microsoft.SystemCenter.NetworkDevice.Interface.Discovery" running for instance "10.160.100.34" with id:"{3A9BC6C5-AA0B-353B-2670-438AD4FC97F1}" in management group "DimensionDataEurope". This may be because the type or assembly could not be found or the type does not have the MonitoringModuleAttribute.

I tried it on a SCOM 2007 without SP1 on a 32 bit OS and on a SCOM 2007 with SP1 on a 64bit machine with the same issues.

I seen in the forums that I am not the only one having this issue, see: http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?&query=snmp&lang=en&cr=US&guid=&sloc=en-us&dg=microsoft.public.opsmgr.general&p=1&tid=bfaf68ee-ea6a-4161-a578-dc734842d0fb

So my question is : Did you do something "secret" to have this MP working on SCOM 2007 ??

Thanks in advance.

Our answer:

We had no 'secret' to get it to work, we were fortunate that it even worked at all for the demos in that particular chapter. We don't recommend wasting any time on it. Rather please consider our coverage of the Essentials network device MP as illustrative of what management pack features are useful when authoring custom SNMP network device management packs with OM 07.
The book does not give advice to import it, rather, we used the features of the MP in the book as an example of what you can do with OM SMTP device monitoring, and we cautioned on page 871 that the Essentials MP is not supported or designed to work on OpsMgr. It did work partially at the time we wrote the chapter, but if since then other dependent MPs have been updated and it no longer works, that would not be surprising. We are not testing it anymore and we don't have it installed in any of our management groups.
The technology for monitoring network devices is planned to undergo changes in the next release of OpsMgr as part of a new Network Aware Service Monitoring solution that is highly scalable. Operations Manager users should not invest in or rely on the Essentials network device management pack. In the near term, we recommend use only the native OM 07 SNMP network device management pack features, or utilize a third party tool or add-on built for OM 07 as needed to support your network devices.

Hope this information helps!

Report issues after moving the RMS

Mon, 10 Mar 2008 16:11:44 GMT

If you've had the "opportunity" to move your Root Management Server (which Cameron describes at http://cameronfuller.spaces.live.com/blog/cns!A231E4EB0417CB76!908.entry), there are other components you will need to update as well. This includes the Reporting Server and Web Console Server, which will need to know the new location of your RMS.

Change the rsreportserver.config file on the Reporting Server. There are two entries there for <ServerName>; change them to point to the new RMS name.
On the Web Console Server, modify the web.config file where it says <add key = "MOMServer" value='FQDN name of RMS"> to reference the FQDN name of your new RMS.
On the registry of the reporting server, change the value of HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft Operations Manager\3.0\Reporting for the DefaultSDKServiceMachine to the new RMS.

The steps to update the files as well as the entire process to move the RMS are discussed in our book. System Center Operations Manager 2007 Unleashed, which is being released this week, discusses additional issues in the RTM version when moving the RMS. You can also check out http://www.eggheadcafe.com/software/aspnet/31051585/loading-report-hierarchy.aspx.