By shahar nusbaum

Well there might be a few guides like this around the web and I have used most of them,

But for the past 3 mounts I have been battling with this scenario where the agent would stay in "not monitor" state after been approved in the pending management pane and the agent had 21007 and 21016 events on the operations manger event log on the workgroup / dmz server  I wanted to monitor.

If you have a working gateway and after your approve the agents in pending mode and used to momcertimport with successful results and you still receive event id's like21007 and 21016 on the workgroup / DMZ agent this guide is for you.

Well my solution is available for you here

Well first of all and very basic (but not for me) I have 2003 enterprise ca server so I used this guide to create my certificate template

To create a certificate template - http://technet.microsoft.com/en-us/library/bb735413.aspx

I flowed that guide to the letter and still those event id's and no communication to my gateway.

 Something was missing,

The first change I noticed was that I now I had no option to save a certificate to local computer certificate store this of course is because of the server 2008 enrolment  pages that would need administrator right witch the internet explorer does not use  

So in order to export the certificate to a file I had to use internet explorer

There under tools -> internet options -> content 

There is a certificates section.

Click the certificate button and you can export your certificate from there

Remember to export the private key after clicking the next batten leave this mark

Don’t mark include all certificates it the certification path if possible

The momcertimport tool will not be able to import the certificate

We will deal with the root ca needed in the workgroup / DMZ server in a minute

Then you can save your certificate to a pfx file and copy it to the server you want to monitor

Keep it in a shared folder for the duration of the install process because you will need it for the gateway server as well as the workgroup / DMZ server.

One more certificate is needed before we can continue and again I used this guide

http://technet.microsoft.com/en-us/library/bb735413.aspx  I used the section called "To download the Trusted Root (CA) certificate"

Notice that you might not be able to get to the web site of your ca server form the workgroup computer so you can do that from your root management server and just save it in the folder were you saved your ca for the workgroup / DMZ server you wanted to monitor

And on one last note before we begin: while most guide say the certificate subject a.k.a the name filed is fqdn don’t just push your domain name in the computer name.
cheek before logon to the workgroup / DMZ server  and Go to start -> computer -> properties – check the full computer name and copy the exact name to your gateway host file if no dns resolution is available

NOW FOR THE STEP BY STEP GUIDE

1.    PREPERING TO INSTALL  THE AGENT ON THE WORKGROUP MECHINE 

 I recommend  you copy this folders  form your scom CD  to one folder you can move around in your environment, let's call that our "scomdmz" inside you will need this folders
* SupportTools
* agent
I recommend  you copy this files to that same folder
* server_cert.pfx (certificate you created using a template for your workgroup / DMZ server)

* CA_certificate_chain.p7b (for the trusted Root (CA) certificate)
move this file to your workgroup machine  (keep a copy of your server_cert.pfx to copy to your gateway server later  )

2.     INSTALLING THE AGENT ON THE WORKGROUP MECHINE

run the msi installation on your server  if there is no dns resolution for your gateway server ping –a the ip address to see if you get the name of your gateway server,  if not you will need to add your gateway server fqdn name to your host file – it's in c:\windows\system32\drivers\etc


(we use the example in our org…)

I KNOW THIS IS A VERY BASIC STUFF RIGHT HERE – I want this guide to be able to apply even to those who don’t deal with this in a daily manner

 now this to prevent any human typing Mistake write the fqdn gateway server in the host file copy & paste it to the management computer name I recommend also copy & paste to command line and telnet the computer name to your gateway on 5723 to check connectivity.
Click next your almost home free…

3.     IMPORTING THE CERTIFICATES TO YOUR GATEWAY AND SERVER

THIS WILL BE SPLIT IN TO TWO PARTS

A.  IMPORTING THE CERTIFICATES ON YOUR DMZ SERVER YOU WANT TO MONITOR -  

 using the momcertimport tool   
-on the workgroup / DMZ server go to start -> if 2008 type cmd if 2003 go to run type cmd
one thing very imported cheek -  if you're on server 2008 check to see if your command prompt run with administrator rights (if not right click the icon before you press enter and  run it as administrator)



the tool is in the SupportTools folder (the one we copied earlier if you flowed step one)
so! The way to run this tool is simple get to it in the command prompt and the give the server certificate file like so
c:\dmzfolder\SupportTools\i386\momcertimport  server_cert.pfx type the password for the key and you will need to receive successfully  state message

YOU GOT THIS FAR – you stop and started the health service like asked in the momcertimport tool after imported the certificate  and still receive those 21007 and 21016 events  you will need to fallow this few steps

 What you need now is another certificate to be imported.
    1.     Go to start mmc -> file -> add/remove snap-in…
    2.     Add certificates add computer account, click next choose local                                            computer click ok and exit – it's all you need for the console

    3.     Go to the Trusted Root Certification Authorities folder on the folder Certificates right click all tasks -> import…
and import your  CA_certificate_chain.p7b we prepared in step 1 this guide
and import it to the Trusted Root Certification Authorities folder
the folder contains certificates that in most time already be in there
but don’t skip this stage.



B. IMPORTING THE CERTIFICATES ON TO YOU GATEWAY SERVER – again this is for all of you battling with  error id  21037 on your gateway (and of course any kind of lack of communication between the agent and your gateway server )

    1.     Go to start mmc -> file -> add/remove snap-in…
    2.     Add certificates add computer account, click next choose local                                            computer click ok and exit – it's all you need for the console
    3. Go to the Trusted Root Certification Authorities and import your
server_cert.pfx we talked about in step one to that folder
    3. Go to Personal folder and import it to that folder ass well



note: we are importing the certificates of the server that we want to monitor into our gateway  Trusted Root Certification Authorities and to the personal folder

4.     CHEKING THE COUMNICATION -

after all the certificates have been imported to  the gateway server and to our soon to be monitored server, in order for this changes to take affect well have to do the fallowing steps

restart health service known as system center management on your gateway
restart health service known as system center management on your  root management server
restart health service known as system center management on your dmz server

Check your DMZ server event viewer to see if the error id repeats

Some changes take time you might want to wait 5-10 minutes after 10

Minutes you need restart the health service again on your DMZ server and cheek your event viewer for the id's if still receive restart the health service again on your root management server and your gateway server


this is my solution and I would like to thank Yossi tali and Gal Hutman

For their help in finding this solution

Free Evaluation Copies: https://portal.nice.de

• Phase 1: User Profile Loading
• Phase 2: Applying Group Policy Objects (GPOs)
• Phase 3: User Environment Initialization and Active Setup
• Phase 4: Logon Script Execution.

Get more information in the article Logon Process Monitoring for Citrix XenApp published on hermes.softlab.com.

Click the Download button and you'll be redirected to the source.

Gateway Server Role Scenario

The Gateway Server role allows the Discovery Wizard in Operations Manager to discover target computers in workgroups, across one-way trusted and untrusted domains, and provides communication between the target computer and the Management Server. The security requirements of Operations Manager 2007 also bring PKI into a prominent role in many environments where it is has previously been underutilised or non-existent.

There are two primary goals for the gateway server:

1. Minimize the number of points of traffic between two secured environments, (for example, a Customer and Service Provider network)

2. Maximize the use of Kerberos based authentication when it is available, because the TCO associated with Kerberos is lower than with certificates.

Operations Manager introduces a more secure communication model than in its previous versions in that mutual authentication is now required by default between an agent and a management server, as well as between Gateway Servers and Management Servers.

Mutual authentication can be achieved via Kerberos in trusted scenarios where all machines are in the same Active Directory domain or in a domain with a two-way trust relationship. However, in cases where machines outside the trusted environment must be monitored, Kerberos authentication is not possible. In these cases, Operations Manager 2007 can utilize x.509 certificates for mutual authentication in a variety of scenarios. Certificates can be deployed to any Windows operating system that supports an Operations Manager 2007 agent.

The Gateway facilitates communication between the target agent-managed computers and a Management Server, easing management in un-trusted and distributed environments. It may be easiest to think of a Gateway as a management server that simply relays information received from agents to another management server. In real terms a gateway is effectively a management server without direct database access. When you approve a gateway, it appears as a management server in the Operations Console.

To ensure high availability, the Gateway Server on the customer site can be implemented with a secondary gateway to allow agents to failover in the event of the primary gateway becoming un-available also a gateway can be configured for failover to both a primary and secondary management server on the service provider side, allowing Gateway communication to continue in the event of a Management Server failure. The Gateway Server also does not require membership in an Active Directory domain, so it is perfect for the typical service provider scenario where quite often a customer site is separated from the Service Provider by some kind of security boundary. Alternatively, agent-managed computers can be configured to communicate directly to a management server while authenticating via certificates, this is suitable where you have a very small number of agents or where implementation of a Gateway Server is not possible.

Common Deployment Scenario for Multi Tenant Environments.

Gateway with Agent-managed Member Servers

In this scenario, monitoring of a remote, un-trusted AD domain is desired. All servers desired for management in the remote domain are members of the same AD domain as the Gateway Server. There is no trust relationship between the two domains. In this scenario, certificate authentication will be required only between the management server and gateway server, as no trust relationship exists. Agent-managed computers in the remote AD domain will be authenticated via Kerberos for communication with the Gateway Server. Thus, certificates must be secured for both the Management Server and Gateway Server in the remote domain.

Gateway with Agent-managed Workgroup Servers

In this scenario, monitoring of a remote, un-trusted AD domain is desired. Some servers desired for management by the Gateway Server are members of a workgroup. In this scenario, certificate authentication will be required not only between the management server and gateway server, but also between the Gateway Server and agent-managed computers. 

Agent-managed Workgroup Servers - Gateway in Workgroup

In this scenario, monitoring of a remote, DMZ or workgroup environment is desired. An additional requirement to minimize the number of points of communication between the isolated environment and the Management Server exists, making deployment of a Gateway Server an appropriate choice. In this scenario, certificate authentication will be required not only between the management server and gateway server, but also between the Gateway Server and agent-managed computers. 

While there is no programmed limit for the number of agents that can be managed within a single Management Group, information from live environments has established certain limits. Performance has been shown to degrade beyond 6,000 agents, so you should always plan for one Management Group for every 6,000 agents.

The official supported limit for the number of agents that can communicate to a gateway server is 1,500. 

Connected Management Groups Scenario

This deployment scenario is comprised of multiple management groups, each of which can be of the single or multiple server configurations type. This deployment scenario is exceptionally flexible and is mostly used to provide monitoring, alerting, and reporting services in complex environments.

This is extremely useful in the service provider scenario as it allows the connection to multiple instances of a Management Group that may exist on customer sites providing a "single pane of glass" for viewing critical alert data.

Connecting management groups offers these additional services:

• Consolidated monitoring and alerting for greater than 6,000 agents
• Consolidated monitoring across trust boundaries

Operations Manager 2007 Server Roles

This configuration supports all Operations Manager server roles and makes use of the Operations Manager Connector Framework to enable bidirectional communication between the connected groups and local groups.

Common Uses

This deployment scenario can be used when the service provider requirement is to link to a complete Operations Manager Management Group on a customer site to allow a consolidated view of all monitored activity and consolidated management of that data.

There is no official limit on the number of Management Groups that you can connect to in this scenario.

High Level Architecture for Mixed Multi-Tenant Environment

In the case of many large service providers quite often the environment would be a mix of both connected and non-connected management groups, therefore a tiered architecture would be suitable.

This may consist of a master Management Group (or Local Management Group) which would host a roll up of alerts from all connected management groups and second management group which would be the collection point for all data from non-connected Management Groups.

Data Warehouse collection at the Master Management Group level would consist of purely Alert and Discovery Data and this would be the primary connection point for other Management Tools or any Ticketing System, this would also provide a high-level, global data collection point for customer facing scorecarding and reporting.

Any customer owned Management Groups would connect directly to this tier via the Microsoft Connector Framework (MCF), with performance and inventory data being collected locally on their sites.

A Second Management Group would be implemented as a connection point for any non-Management Group sites which would have local Gateway Servers for relaying data from local agents, this Management Group would also be connected to the Master Management Group via the MCF. This second tier would have Data Warehouse Collection Capabilities for Performance Metrics and Inventory Data and would provide a second data collection point for customer facing scorecarding and reporting.

 The following diagram shows an example of how this architecture may look:

Connecting to other Management or Helpdesk Ticketing Systems

The Operations Manager 2007 R2 release saw the introductions of a number of free Interoperability connectors, these include HP Openview, Tivoli TEC, Remedy Helpdesk and a universal connector.

With the recent acquisition of Opalis Integration Center by Microsoft a number of other connection options have been added to the product such as Omnibus Netcool and HP Service Center.

Microsoft also has a close collaboration with EMC around the SMARTS network management toolset, which includes the purchase of some of the EMC SMARTS IP for addition to the next version of the product.  This collaboration has led to a recent release of a a bidirectional adapter package from Microsoft called the EMC Smarts Connector for Microsoft System Center Operations Manager 2007. The adapter will let Operations Manager users view Smarts topology and root-cause reports using their own interfaces. Smarts will also be able to suck in data from Operations Manager.

Operations Manager also comes with an extensive SNMP Trap collection feature allowing you to receive traps from any SNMP enabled system as well as being able to probe other systems ( via SNMP) for information.

Management Escalation

Operations Manager 2007 has a very extensive and flexible subscription based notification system which supports output to SMTP enabled mail systems, Microsoft Office or Live Communication Server (for delivery of messages to Office Communicator clients), GSM for SMS Text Messaging integration via a suitable GSM enabled device, as well as any command line supported medium.

This subscription mechanism supports a very granular and targeted alert stream, allowing you to alert down to a single object or alert over a variety of parameters (such as time raised, severity, business priority etc.).

Operations Manager also supports Alert Ageing which allows you to put a time expiry on un-answered alerts meaning that you can escalate them to higher tiers of Management or too other Operators.

Hardware Support for All Platforms

Microsoft has full support for Operations manager 2007 from most of the large Hardware Vendors such as HP, Dell, Fujitsu Siemens and IBM. Each of these vendors provide a full Operations Manager 2007 management Pack which typically integrates with the local hardware agent and contains Vendor specific knowledge in alerts generated.

Role based administration

Operations Manager 2007 can monitor many different types of applications in the enterprise and these applications can be administered by multiple teams. As the Operations Manager administrator, you can limit access to each team so they access only their monitoring data. Role-based security allows you to grant access to monitoring data, tools, and actions on a team-by-team basis.

Except for the Administrator role, you can add Active Directory security groups or individual accounts to any of these predefined roles. You can add Active Directory security groups only to the Administrator role.

Adding users or groups to a role mean that those individuals will be able to exercise the given role privileges across the scoped objects (including any inherited objects).

Operations Manager also allows you to create custom roles based on the Operator, Read-Only Operator, Author, and Advanced Operator profiles. When you create the role, you can further narrow the scope of groups, tasks, and views that the role can access. For example, you can create a role entitled "Exchange Operator" and narrow the scope to only Exchange-related groups, views, and tasks. User accounts assigned to this role will only be able to run Operator-level actions on Exchange-related objects.

Measuring and Displaying Customer Service Levels

One of the most challenging aspects of providing a managed service to a customer is being able to visualise the value of the service you are providing back to the customer in a format that can be consumed and understood by  any level of the business.

Operations Manager 2007 delivers the ability to define an IT service (or distributed application) by selecting the components that together deliver that IT service, along with their inter-relationships. For example, a web service may comprise of the web server, application pools, a database, and the servers that each are hosted on.  By monitoring a defined number of characteristics of each of those components, Operations Manager is able to determine both the health and performance of each component through 3 states:

• Healthy, indicating that the component being monitored is operating within expected parameters.
• Warning, indicating a performance or health threshold has been exceeded, and that while the component is operating, attention is required to prevent service disruption or restore performance.
• Critical, indicating that the component being monitored has entered an unhealthy state that requires immediate attention, and that the availability and performance of that component are compromised.

This feature is one of the most powerful features of Operations Manager as it gives the ability to be able to group together all of the components that make up a service and in the event of an outage very quick root cause analysis of the source of an outage of performance problem can be identified by simply clicking on a problem path button.

This is also extremely useful to the service provider as it gives him the ability provide metrics back to the customer on the core services that he is being paid to manage through Operations Manager 2007 R2's in built Service Level Reporting capability.

The Service Level Reporting capability in Operations Manager 2007 R2 (also called "service level objectives" or SLOs) leverages this same functionality maintained in the Distributed Application concept to determine both availability and performance metrics for monitored IT services. It does this by calculating the overall time that the components that comprise that IT service remain in a particular state to arrive at the following metrics:

• Availability, calculated as the time the components that comprise the service are in a healthy or warming state. Only a critical state counts against the availability metric, since even if it is in a warning state the IT service is seen as being accessible by end users, (e.g., a web service may take a long time to respond, but it does eventually deliver a web page).
• Performance, calculated as the time the components that comprise the IT services are in a healthy state. Both warning and critical states count against the performance metric, (e.g., if a database transaction is expected to complete in less than 300ms, and the actual transaction takes 2 seconds, then this will be seen as a performance impact).

Once you have defined your Distributed Applications and Service Level Objectives you can use the in-built Service Level Report to display the results or can display the data in a much more effective format using the Service Level Dashboard.

The Service Level Dashboard for Operations Manager R2 is a free download from the Microsoft Solution Accelerator team which is an application built on Windows SharePoint Services 3.0. It is designed to work with an existing Operations Manager 2007 R2 infrastructure configured to monitor business-critical applications. The dashboard evaluates an application or group over a time period that the administrator selects during setup, determines whether it met the defined service level commitment, and displays summarized data about the service levels.

In Operations Manager 2007 R2, you define your service goals. The Service Level Dashboard evaluates each SLO over the defined dashboard time period and determines if it met the goal during that period. The dashboard displays each SLO and identifies its states, based on defined service level targets.

The following diagram illustrates, at a high-level, the process flow that occurs within the Service Level Dashboard environment:

The Service Level Dashboard integrates with the Operations Manager Data Warehouse database and displays service level metrics on the Windows SharePoint Services interface. All the customized and personalized data associated with the Web Parts of the Service Level Dashboard is stored in the Windows SharePoint Services Content database.

The dashboard can summarize the current status and health of all defined SLOs against an application or group of objects. Key measures used to evaluate various aspects of the health of defined SLOs include such information as service level metrics, mean time to repair (MTTR), mean time between failures (MTBF), and service level trends.

As this Dashboard can be used in SharePoint or WSS, it can easily be imported into a public facing portal for on-line consumption by the customer.

Custom SLA Scorecarding

As the needs of the Service Provider often varies from some of the functionality that is provided from Operations Managers "out-of-the-box" availability and SLA Reporting, there is often a need to publish key data collected from Operations Manager in executive level dashboards and scorecards to give customers a "10,000" feet view of their environment so they understand the value the service provider is bringing in managing their infrastructure also key performance metrics can be presented allowing IT stakeholders within those businesses to make key decisions without the complication of having to run their own reporting infrastructure.

This extra level of reporting can easily be provided through extending Operations Managers reporting capability to utilise some of the new, native SQL 2008 reporting capabilities.

By using some of the new reporting controls now in SQL 2008, very effective, customer ready scorecards can be created which can easily be tied to an individual customer by using a combination of

Gordon McKenna - System Center Operations Manager MVP

Technical References:

Gateway Server and Certifcate-based Authorization Scenarios in Operations Manager 2007: http://www.systemcentercentral.com/Downloads/DownloadsDetails/tabid/144/IndexID/7885/Default.aspx

Tracking Service Levels with Operations Manager 2007 R2: http://download.microsoft.com/download/9/B/4/9B4829DC-55A5-46E7-9C9A-91B49EBB6320/SC_OpsMgr2007_R2-ServiceLevelMonitoring.pdf

Service Level Dashboard for System Center Operations Manager 2007: http://technet.microsoft.com/en-us/library/dd630553.aspx

Agentless Exception Monitoring (AEM) of System Center Operations Manager and System Center Desktop Error Monitoring (DEM) are identical features with the only difference being that AEM is shipped with Operations Manager 2007 and DEM is shipped with Microsoft Desktop Optimization Pack (MDOP) SKU’s.  These features leverage the Microsoft Error Reporting (formerly known as Dr. Watson) or Windows Error Reporting client applications for reporting the crash or hang.

Because this is a hybrid user group meeting there are two ways to register.
1. If you would like to use Live Meeting to attend the meeting remotely, register here http://www.clicktoattend.com/?id=146192
2. If you would like to go to the Alpharetta, GA Microsoft Campus to attend the meeting please register here, this will help us with planning for lunch requirements. https://www.usergroupsupportservices.com/UGEventView.ugss?EventID=8775
 

DATE & TIME
March 5, 2010
10:00 AM – 4:00 PM Eastern Time Zone
 

Lunch provided by Prowess http://www.prowesscorp.com
 

“At Prowess Consulting, we focus on providing technology marketing, technical writing, IT infrastructure, and managed services to Fortune 500 companies. We make businesses stronger by delivering the right information at the right time. We are trusted by the largest organizations to deliver results through innovative and customized solutions.”
 

THE AGENDA
 

9:45 AM 10:00 AM Opening and Introductions
10:05 AM 11:00 AM Prowess Presentation
11:05 AM 11:50 AM Introduction to Microsoft App-V and the Enterprise
11:55 AM 12:40 PM SCCM R3 Features and Benefits
12:45 PM 1:00 PM Break
1:05 PM 1:50 PM Ed Wilson Powershell Best Practices
1:55 PM 2:40 PM MP Authoring Resource Kit
2:45 PM 3:40 PM What is SCUP and How Do I Use It?
3:35 PM 4:00 PM Closing
 

PRESENTER BIOGRAPHIES
 

Steve Bucci
Steve is a Senior Support Engineer with Microsoft System Center Support in Charlotte, NC. He supports Application Virtualization (App-V), Microsoft Enterprise Desktop Virtualization (MED-V), and Virtual Machine Manager (SCVMM). He has worked for Microsoft for the past 8 years.
 

Brian Shaw
Brian has been with Microsoft the past 2.5 years and is currently holding the position of Senior Support Escalation Engineer supporting SMS, Configuration Manager (SCCM), and WSUS. Brian has been supporting SMS for well over 10 years, starting with SMS 1.2. Brian is currently the CSS Beta Engineer supporting the development and release of SCCM R3.
 

Ed Wilson
Ed is a senior consultant at Microsoft and a well-known scripting expert. He is a Microsoft Certified Trainer who delivers popular scripting, networking, and administration workshops to Microsoft employees and customers worldwide. He’s written several books on Windows scripting, including Microsoft Windows Powershell Scripting Guide, Microsoft Windows Scripting Self-Paced Learning Guide, and Microsoft VBScript Step by Step. Ed holds more than 20 industry certifications, including MCSE and CISSP.
 

Cory Delamarter
[Unavailable at this time.]
 

Jason Lewis
Jason is a Program Manager on the System Center Configuration Management SE Team at Microsoft. He’s been with the team for over 5 years working on products such as Systems Management Server 2003 SP2 and R2, including the Custom Updates Publishing Tool (CUPT), Inventory Tool for Custom Updates (ITCU), System Center Updates Publisher (SCUP), and Configuration Manager 2007 R2. Jason also authors a blog at http://blogs.technet.com/jasonlewis where he covers products that he’s working on including “FYI” and “How To” topics.

Thank you for your continued support!

Scott Moss
Microsoft MVP (Operations Manager)
Vice President Atlanta SMUG http://www.atlsmug.org
President System Center Virtual user Group  http://systemcenterusergroup.org

• In part 1 - basics of building a CentOS Management Pack,.
• In part 2,  how to build the actual MPs.
• In part 3, MP installation and validation.

To view the entire series at the source, click the Download button.

Click Download to read the entire article...

Kevin writes: This is something a LOT of people make mistakes on – so I wanted to write a post on the correct way to do this properly, using a very common target as an example.

When we write a monitor for something like “Processor\% Processor Time\_Total” and target “Windows Server Operating System”…. everything is very simple. “Windows Server Operating System” is a single instance target…. meaning there is only ONE “Operating System” instance per agent. “Processor\% Processor Time\_Total” is also a single instance counter…. using ONLY the “_Total” instance for our measurement. Therefore – your performance unit monitors for this example work just like you’d think.

However – Logical Disk is very different. On a given agent – there will often be MULTIPLE instances of “Logical Disk” per agent, such as C:, D:, E:, F:, etc… We must write our monitors to take this into account. (continue at source) 

In this article I will give a step-by-step instruction how to configure Service Level Tracking on a Live Maps view and show the results using the Service Level Tracking report in OpsMgr and the Service Level Dashboard in SharePoint.

(continue at source)