Google Reader Pete's Management Blog
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Add to My AOL
Add 'Pete's Management Blog' to Newsburst from CNET

Powered by Blogger

My MVP Profile

Sunday, July 01, 2007

Consolidating my efforts

Blogging can be a lot of work. Tracking multiple blogs can be a pain to.

That being said, I have decided to consolidate my efforts, and will do all future blogging through my MS System Center-focused site with which you are likely already familiar, We've lots of great content headed to the site, and a couple of great new features rolling out in the next month, so be sure to visit the new site to see what happens!

All content lives under a namespace I own, so it will remain available through the useful life of MOM 2005 and Ops Mgr 2007 and beyond.

My new feed:
Catch my future work on my new site rss feed:

(if you subscribe to my systemcenterforum feed, you have this already)


Wednesday, June 27, 2007

Outsmarting "Smart Defaults" in the Essentials Network Device Monitoring MP

Because SCE 2007 is designed with the overworked "IT Generalist" in mind, you have to keep an eye out for what is NOT enabled out of the box. In the Network Device MP, I think these smart defaults missed the mark for me. I was dismayed to find some fairly important performance metrics are disabled out of the box. For example, the monitors for Inbound and Outbound Utilization % are disabled by default, as are the threshold alerts that go with them.

I can appreciate the thought behind this, because alerting per network interface can be noisy and performance data cause substantial database growth, this is probably a safe bet for minimizing support calls..... But for visibility from a performance perspective, you may find you need to enable many performance threshold monitors and rules to collect and measure and relevant performance data, as well as to alert on interface threshold breaches - at least for your critical network devices, like core switches and Internet routers.

This can be a bit of work, but I'm going to show you how to make this task a bit less tedious, by filtering down to only the Network Device MP rules and monitors, as well as determining which rules are not enabled by default.

1. Start by navigating to the Authoring space in the Operations Console.

2. In the Navigation pane, browse to and select Management Pack Objects.

3. At the top of the Results pane, click Change Scope.

4. In the pop-up provided, select only the Network Device Group and any target beginning with SNMP. This will filter the rules and monitors down to only those relevant to our configuration objectives.


Figure 1 - Filtered View of Network-relevant Monitors and Rules


5. In the Navigation pane, select the Monitors node. You should only the lists of SNMP-enabled device monitors as depicted in figure 4.

6. To determine which rules are NOT enabled by default (and will thus need to be enabled via overrides), expand each of the rule groups, and view the monitor names and descriptions, which are for the most part self-explanatory.

You can make this easier by dragging and dropping the ‘Enabled by Default’ column to the left, as depicted in figure 1 below.  It's way off to the right by default, about 5 columns over.


Figure 2 - Viewing 'Enabled by Default' Status of Monitors and Rules


1. For monitors not enabled by default, right click the monitor and select Overrides --> Override the Monitor for --> <object or group of objects you wish to monitor / measure>.

2. Repeat this process for each group of monitors, and repeat for each group of rules as well. The end

Wednesday, June 20, 2007

Certificate-based Authorization across the Internet in Ops Mgr 2007


Certificate-based authorization scenarios in Operations Manager 2007 are something we've tested and documented, but there is one question that's been raised a few times we have yet to address:

What if I assign a certificate to a server in a network across the Internet that has an FQDN that cannot be resolved by the management server?

Let's take the following example:

We have a management server and potential agent-managed computer on distant, untrusted networks connected only by the Internet.

  • management server:
  • agent-managed machine: SVR03.contoso.local

You'll notice the agent-managed machine has an FQDN with the non-routable extension of .local. It could be anything really - the point is, servers in protected networks generally have an FQDN that is not resolvable across the Internet on remote networks. Operations Manager is capable of bridging this gap, but there can be some additional difficulty involved in mutual authentication in this case.

Why would this be a problem? 

Quite simply, when you assign a certificate to this machine, and the management server attempts to contact this machine by its FQDN, the connection will FAIL if the name cannot be resolved by the management server (and if resolution fails in other direction for that matter). You could try to work around by assigning a DNS alias in a publicly accessible domain (like, for example) and using that in the certificate request and using that FQDN in the certificate request for the agent.

The result? Mutual authentication will fail. OM 2007 requires that the FQDN reported by the machine match that which is present in the certificate, else, mutual authentication will fail.

Why does Ops Mgr require this?

According to Ian Jirka from the product team, "The fundamental reason for us forcing the FQDN of the local machine is it greatly reduces the chance of having a name collision when using certificate based authentication, and provides a consistent tie back to the actual machine. If you have a name collision you end up with two devices with the same identity. Issues can arise from that ranging from strangely-broken functionality to security problems."

What should you do?

According to Ian, "You should give it (the FQDN you supply in the certificate request) the FQDN of the local machine-- we won't load it otherwise. In general things will work except for that which relies on the name for remotely accessing the machine. If you do need to reach out to that box from within an OpsMgr workflow, and want OpsMgr to give the name to you, it will give that local FQDN."

So you have the issue in this case that the name (svr03.contoso.local in our example) cannot be resolved. To work around this issue, you could simply add a host file entry on our management server (%windir%\system32\drivers\etc\hosts) that contains the PUBLIC IP ( in this example) of the agent-managed machine and the internal, or non-routable name (SVR03.contoso.local). And if the agent-managed computer cannot resolve the management server FQDN, it's feasible you'll need to add a reciprocal entry in the host file on the agent-managed computer.

And let's face it, this doesn't scale well from a process perspective. A gateway server fills the gap nicely when you have to manage multiple machines on a network across the Internet. At worst, you'd need host entries on only the gateway and management servers. From a security perspective, remember that agent communication is encrypted by default, so coupled with the mutual authentication sequence between agent and mgmt server, you have secure communication even across unprotected networks.

Thursday, June 14, 2007

Audit Collection (ACS) and the Gateway Role in Ops Mgr 2007

The Audit Collection Collector role can be installed on a gateway server....usually.

The gateway role was designed to facilitate a couple of purposes as I understand it:

  1. Minimize points of communication between disconnected environments
  2. Allow utilization of Kerberos authentication in disconnected / untrusted domains, which reduces TCO by eliminating the need to configure a bunch of certifcates on client machines in the untrusted environment.

So if you wanted to employ Audit Collection in such an environnment, you can install ACS Collector on a Gateway server. HOWEVER, Audit Collection has a dependency on Active Directory, so you cannot install Audit Collection on a Gateway in a workgroup environment (as of RTM, the Gateway role has no AD dependency).

Joseph from the product team offered up an interesting workaround if you have a Gateway Server in a workgroup environment and wish to deploy Audit Collection on the Gateway Server:

Since the ACS Collector has dependency on AD, you could promote your Gateway server to a Domain Controller - which can be a completely isolated and seperate domain.If agents are in a workgroup, certificate auth between them and the Gateway+Collector box will be required.

Sunday, June 10, 2007

Is Powershell coming to Windows 2008 core?

With the announcement that IIS 7.0 is now officially part of Windows 2008 core, it's easy to predict high demend for the .NET framework, which then provides the foundation for Powershell...but is it going to happen?

So, in the same session where Maarten spotted SP1 for Windows Server 2008 Beta 3, I posed the question to the presenter - Will Powershell make it into the Windows 2008 core, and if so, when?

His answer was roughly as follows:

There are too many dependencies to get the .NET framework in it's present state into the core, but work on a modular version is underway, but much work remains to be done. While he ruled out any possibility that this would happen in the RTM timeframe, he didn't completely rule out the possibility in the SP1 or R2 timeframes.

So, I guess we'll wait and see. Until then, get reacquainted with the net and netsh CLI commands, accessing control panel elements (launched by calling .cpl files), and installing core components with an included vbscript.

Thursday, June 07, 2007

HIgh-level Evaluation Criteria for Non-Windows, VMware and network monitoring solutions

With the announcement of the purchase of Engyro, Maarten from confirmed that the Engyro MPs were in fact pulled from the market. This put a crimp in the non-WIndows story for more than one person I am sure.

On the VMware front, we have spent quite a bit of time with nWorks VMVware monitoring. nWorks has a slight advantages from a data collection perspective over their competitors it appears, which I'll speak more about in later posts. Jalasoft will almost certainly provide the broadest range of coverage with the best integration, but to their credit, eXc has a very low price point, along with responsible and knowledgeable support in our experience. SecureVantage has owned the security market where MOM is concerned, but Enterprise Certified arrived on the scene in recent months, offering some choice.

But how do I choose the appropriate solution for my environment?

Solution criteria will obviously vary by the target service or device and your environmental specifics. However, I think we can make some high-level generalizations here. When comparing non-WIndows monitoring solutions, some high-level key evaluation criteria should like include some of the following:

  1. Intelligent defaults in threshold rule settings and alert severities. Nobody likes to install a product only to find it's completely worthless without days or weeks of tuning. Alerts should be easily interpreted by humans.
  2. Product knowledge integrated in the solution display through alerts. Good event, alert, perf, state and diagram views are a plus as well
  3. An architecture - one that is
    1. Extensible - Allows customization and development where possible (APIs are good)
    2. Un-coupled from the management server if feasible. Use of a proxy agent is preferable. Engyro had that concept in well in hand (sigh...)
    3. Scalable - very few providers provide documented scalability numbers that I have seen.
    4. Intelligent in its data collection choices - efficient and rich data collection is a must. A solution is only as good as the data is collects - the richest dataset from the most economicle source or sources for a given target is important.
  4. Virtualization friendly - Components should run within a VM without issue - and with a low footprint.
  5. Integration - A minimum of configuration outside the Operations Console is a nice to have....but not always possible I know.
  6. Automation - Deployment and configuration of multiple nodes should require a minimal amount duplication. (I would point to Jalasoft's forthcoming IO release as evidence of a vendor listening to customers on this count).
  7. Reporting - This has less weight than it once did, given the generic reporting libraries in Ops Mgr 2007. The exception here would be specialty solutions, like security and regulatory compliance reporting (SecureVantage clearly understands this).
  8. Good Documentation - Poor documentation hints at poor preparation. 
  9. Support - Staff who are both knowledgeable and responsive. Many vendors in the Ops Mgr ISV space score well here.
  10. Fair Licensing Model - Licensing should be easy to navigate, and shouldn't make me feel like I am paying for Ops Mgr all over again. This is especially true today, as we're all simply bridging a 2-3 year gap until the arrival of MOMv4.

What do you consider when selecting 3rd party solutions to augment OpsMgr functionality? Community, MS, ISV - Let me hear your insights into the topic. Comments can be left on this post directly, or I can be reached via the contact form on my blog @

Monday, June 04, 2007


I landed in Orlando today.....I am too cranked up to sleep tonight. It's 11:30pm and I am ready to get started!

TechEd 2007 is shaping up to be a pretty incredible event. I skipped last year due to the product development cycles last year, as many products (like Ops Mgr '07) were in early beta. My focus this year is going to be on all aspects of Longhorn, enterprise messaging with Exchange 2007 with some DPM, SCCP and SCCM and Service Desk thrown in.

The volume of management sessions here are little less than I thought, but you can bet I will be seeking the Ops Mgr product team for answers......oh, you know I will.

Expect plenty of activity here and on this week as I bring what enlightenment I can from the conference.