Yes, it's here! Microsoft began pushing out Service Pack 1 (SP1) to the web this past weekend. The version number is 6.0.6278.0. To download the upgrade, go to http://www.microsoft.com/downloads/details.aspx?FamilyId=EDE38D83-32D1-46FB-8B6D-78FA1DCB3E85&displaylang=en. Service Pack 1 includes new functionality as well as bug fixes; http://blogs.technet.com/systemcenter/archive/2008/02/23/system-center-operations-manager-2007-service-pack-1-sp1-now-available.aspx highlights some of the new features and enhancements.

Tips for upgrading

• Backup your databases (even in your test environment!)
• Read the OpsMgr2007_UpgradeGuide.htm document included in the extracted download. It lists supported upgrade paths, and the sequence in which to upgrade your components. You will want to increased the size of your databases, and the guide also gives tips on how to verify the upgrade has completed successfully.
• Be sure to upgrade your agents when you are finished. See http://support.microsoft.com/kb/941811 - memory leaks will occur if you do not upgrade your agents.
• Don't forget to import SP1 versions of MPs in as necessary.

I did a write-up of improvements in SP1 several weeks ago at http://www.networkworld.com/community/node/24734, which includes some useful Microsoft references which I have updated for the RTM.

Microsoft is providing a dedicated page for SP1 at their TechNet site, http://technet.microsoft.com/en-us/opsmgr/cc280350.aspx. The contents of this page will probably change as more information is available.

Other useful tips and information are available at:

• http://blogs.technet.com/kevinholman/archive/2008/02/24/after-you-install-sp1-for-operations-manager-2007-what-s-next.aspx
• http://blopon.blogspot.com/2008/02/it-is-time-to-find-what-was-fixed-and.html
• http://blogs.technet.com/cliveeastwood/archive/2008/02/22/operations-manager-2007-service-pack-1-rtm-upgrade-guide.aspx

If you have issues, check the newsgroups, in particular microsoft.public.opsmgr.sp1. Some bugs have been identified and resolutions will be posted there as they become available.

Regarding coverage of SP1 in our book, System Center Operations Manager 2007 Unleashed: Although the book was completed before SP1 was released, we discuss the service pack based on the functionality available in the release candidate. This includes bug fixes and major changes in functionality.

Microsoft developed several sets of Visio stencils for OpsMgr that we use throughout System Center Operations Manager 2007 Unleashed. These have been posted on System Center Forum, at http://www.it-jedi.net/downloads/scomstencils.zip (new link attached on 2/9/09 as the previous link was no longer functional).

There is also an additional set of stencils that we developed for the book, available with the companion CD distributed with the book.

We received the following email from "Jay", but his communication preference settings do not allow a reply to his email. Jay said:

I'm attempting to build a system that can host 10-20 concurrent Operation Consoles.  I already plan to get dedicated fast drives (10K SAS), and have separate drives (or "spindles") for each of: OS/apps/swap; DB data; DB logs; DB backup.

My deliberation is whether to have the RMS, Reporting/SRS (not the data warehouse DB), and operational DB/DBS all on one server with 4 dual-core Opterons and 64 GB RAM (OS, DBS, and SCOM, all 64-bit)  OR

Put the operational DB/DBS on it's own server  -- still with 4 dual-core Opterons and 64 GB RAM, and have the RMS and reporting on it own server with 4 dual-core Opterons and 16 GB RAM  OR

go with 3 servers and put the reporting/SRS on it's own server.

Microsoft says to "scale up" or "scale out", but my instinct says "scale up" may be better for reducing latency for an interactive app like the console, as long as you have "enough" CPUs and RAM.

With around 1000 managed servers, or operational DB is about 50 GB, so the large amount of memory is intended for caching the DB.  With the DB "heavily" cached, and the DB/DBS on its own server, even with GB network, I would think the network latency, including the OS network stack latency would be significant.

With the one server solution, the "thread execution delay" may be significant, as even 8 processors may not be enough to keep all of the functions: RMS, reporting, SRS, DBS, running without "latency".

What I don't know, is what is more significant --  the network latency or the "thread execution delay" latency.

I could also build the single server with 4 quad-cores to cut down the "thread execution delay" latency, but the quad-cores are still a bit pricey.

Salient points:

• The question is where to position the database servers. There are three scenarios (if we read this correctly):
  • Have the RMS and SRS on one server with the operational database and data warehouse on a second server
  • Use three servers - RMS and SRS on one server, Operations database on a second server, data warehouse on the third server, Operations database on the third server
  • Use three servers - RMS on on server, Operations database on second server, data warehouse and SRS on  on a third server
• He has 1000 managed servers, and a 50GB Operational database.
• The plan is to have 10-20 concurrent Operations Consoles open.

Thoughts:

We vote for option number 3. With 1000 managed servers, it is definitely best to have the RMS all by itself. This also separates the Operational database and the data warehouse, which are updated simultaneously by the management server(s).

Jay did not mention the number of planned management servers. With 1000 agents, you would want to install multiple management servers. A rule of thumb is once you have at least 100 managed nodes, you will want to install a second management server. (A second management server is always a good idea in case the RMS goes down and you need to promote another server to that role.) While Microsoft supports up to 2000 agents per management server, you may want to add additional management servers, depending on the type of data being collected. For example, a single management server is unlikely to be capable of supporting 2000 Exchange servers due to the particularly heavy load these agents place on it. After the first two management servers, you may want to add an additional management server for every increase of 250-500 nodes.

As the number of active consoles grows, the database load also grows. This is because consoles, either operator or web-based, increase the number of database queries on both the operations and data warehouse databases. Having that many consoles is another reason to separate the two databases to different servers. Console performance improves quite a bit with Service Pack 1, which will be released shortly.

In addition, 50GB is fairly big for the Operations database. You may want to tune the grooming settings to get the database down to 40GB or even perhaps 30GB. While the database size officially has no limits, a number of OpsMgr sites (including Microsoft), have suggested a database of 40GB or below.

A good article on network bandwidth is one by Satya Vel at http://blogs.technet.com/momteam/archive/2007/10/22/network-bandwidth-utilization-for-the-various-opsmgr-2007-roles.aspx

In addition, you may want to look at Chapter 4 of System Center Operations Manager 2007 Unleashed, which discusses planning your OpsMgr deployment.

Anyone else have comments or suggestions for Jay?

1. In the Operations console, navigate to the Authoring space. Open Authoring -> Management Pack Objects -> Objects Discoveries.
2. Narrow your scope, then search for the "Discover Windows CPUs" discovery rule.
3. In the Properties window of the rule, go to Overrides. Set overrides on all Windows Server 2003 Operations System role type objects. Check "override" on the "Enable" parameter.
4. Save the override setting to an unsealed management pack, preferably not the Default management pack.

Once the Processor class is functional, the CPU percentage utilization monitors will also start working.