If you want to multi-home a X plat machine (configure  it to report to multiple management groups) there are a couple of steps you need to take. You can not simple discover it from different management groups as we do with Windows agents.

1. Discover your Linux machine from management group 1
2. Export the certificate from the management server which discovered the Linux box in management group 1. The SCX-agent certificates are signed by a key on the management server that has discovered them, and that machine needs to be a trusted root CA on the management server in management group 2
3. Copy the root CA certificate from the management server in management group 1 to the management server in management group 2
4. Import the certificate as a trusted root CA on the management server in management group 2
5. Run discovery wizard in management group 2 and discover the Linux machine

In this scenario it is very important that both management servers communicate with the Linux machine with the same FQDN.

Here are some notes from what I did when I connected a SUSE box through a gateway server to Operations Manager 2007 R2. During the discovery I found received two error messages. The first one was solved by selecting correct management server. By mistake I selected my root management server that are on the other side of a ISA server, so it could not copy the files to my SUSE box. When I selected my gateway server instead, that are on the same subnet as SUSE, there was no problem copy the files.

< ![CDATA[Executing command: rm -rf /tmp/scx-root; mkdir -m 755 /tmp/scx-root
Transferring file: E:\Program Files\System Center Operations Manager 2007\AgentManagement\UnixAgents\GetOSVersion.sh to location: /tmp/scx-root/
Verifying that file: GetOSVersion.sh was transferred properly
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
]]>

The second error message was about Windows Remote Management (WinRM). You need to configure WinRM on the gateway server, unfortunately the error message doesn’t tell you that it should be run on the gateway server, but as it is the selected management server for the discovery, that is where you need to configure WinRM.

After that there was no problem discover the SUSE machine from a gateway server.

When I shutdown my gateway server I could see that the SUSE box was changed to a unknown state

I then changed primary management server for my SUSE box, under the Administrator workspace in the console. After a couple of minutes the SUSE box turned red (from unknown) and start alerting about certification problems.

The SCX-agent certificates are signed by a key on the management server that has discovered them, and that machine, in this case my gateway server DMZ01, is not a trusted root CA on my root management server, corp-R2. To verify that the SCX Agent on the remote system is running properly, try enumerating the SCX_Agent provider using the following command from the primary management server

winrm e http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -r:https://.:1270 -u: -p:
-auth:basic -encoding:utf-8

gave

To solve this, you need to copy the SCX-Certificate from the gateway server, or the management server discovered the SUSE box, to your new primary management server. Import the certificate as a trusted root certification authorities. Once the certificate is in place you can run the WINrm e command again and you will get another result

Summary. The SUSE box can be discovered by your gateway server. The SUSE box can also do a manually failover between a gateway server and a management server, as long as the certificate is in place. Communication between management server and the Linux box use TCP port 1270 and always originates from the management server or gateway server. In some cases, such as when the WSMAN layer is not present on the Linux box or it has failed, the communication can occur over SSH TCP 22. SSH can be used for installing the WSMAN layer or performing diagnostics tasks. There will be no “heartbeat failure” for the SUSE box, at least I did not received that first five minutes. I did received alerts for the gateway server and some “logfile module error” but not a clear “heartbeat missing” alert for my SUSE box.

Here are some notes from what I did when I installed a new agent in a workgroup/untrusted environment with Operations Manager 2007 R2. In this example my CA server is named DC01 and my agent is named DMZ-a01. These steps presuppose that the other side, a gateway server or a management server, is already configure correct. In this scenario I had a gateway server between the management server and the agent.

Remember to configure your management group to allow manually installed agent (Administration/Settings/Security).

1. From the agent, browse to http://dc01/certsrv
2. Add http://dc01 to your trusted sites in IE
3. If you get a error saying that the CA must be configured to use HTTPS authentication or ActiveX can’t be loaded, change the security settings for trusted sites zone, enable Initialize and script ActiveX controls not marked as safe for scripting. Then reload the page
3. Download a CA certificate, certificate chain, or CRL
4. Download CA Certificate chain
5. Once the cert is downloaded, open a MMC with the Certificates (Local Computer) snap-in and import the certificate under Trusted Root Certification Authorities

The next step is to request and install the proper certificate from the root CA server.

1. From the agent browse to http://dc01/certsrv
2. Request a certificate
3. Advanced certificate request
4. Create and submit a request to this CA
5. If you get a error saying that the CA must be configured to use HTTPS authentication, change the security settings for trusted sites zone, enable Initialize and script ActiveX controls not marked as safe for scripting. Then reload the page
6. On the Advanced Certificate Request page input
Name, needs to be FQDN of the machine, for example dmz-a01
Type of certificate needed: Other
OID: 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2
CSP: Microsoft Enhanced Cryptographic Provider v1.0
Check Mark keys as exportable
Name: needs to be FQDN of the machine, for example dmz-a01
7. Submit the request
8. On your root CA (DC01), open the Certification Authority console, issue the certificate under pending requests
9. On the machine that request a certificate (DMZ-a01), browse to http://dc01/certsrv
10. View the status of a pending certificate request
11. Install the certificate by clicking on it
12. Open a MMC with the Certificates snap-in, for “my user account”. Under Personal certificates, export the certificate including the private key.
13. Open a MMC with the Certificates snap-in, for “local computer”. Import the certificate under personal certificates.

Next step is to install the agent software. You need to copy the MOMCertImport.exe and the suitable agent folder (for example AMD64) from the installation source to your agent machine. Run the agent setup, input the FQDN of the management server and the name of the management group. Select a action account, if you unsure, select local system and click next. When the installation of the agent is complete, run MOMCertImport.exe and import the certificate. Then restart the System Center Management service (HealthService).

Your agent should now show up under pending management in the Operations Manager console. Approve it and you are done!

There is a tool, certificate generation wizard, that you can download here, it can make untrusted agent scenarios easier.

I installed a gateway server on Windows server 2008 X64 this week. Here are some steps from what I did. I started with installing a new standalone root certificate authority on a Windows Server 2008 X64 domain controller (DC01) with the following steps.

1. Add role
2. Active Directory Certificate Services
3. Certification Authority and Certification Authority Web Enrollment
4. Standalone, this CA does not use Directory Service data to issue or manage certificates
5. Root CA
6. Create a new private key
7. Default values on cryptography, CA Name, validity period (5 years), certificate database, web server (IIS), Role services
8. Confirm and install, the close the wizard

After that installed the root CA certificate and a certificate on both my management server (corp-R2) and on the gateway server (DMZ01).

1. From both the gateway server and the management server, browse to http://dc01/certsrv

2. Add http://dc01 to your trusted sites in IE
3. Download a CA certificate, certificate chain, or CRL
4. Download CA Certificate chain
5. Once the cert is downloaded, open a MMC with the Certificates (Local Computer) snap-in and import the certificate under Trusted Root Certification Authorities

There is a tool, certificate generation wizard, that you can download here, it can make gateway scenarios easier.

CertGenWizard.exe is a wizard tool which will take your CA information as input (it isn’t required if you are running the wizard on the box with the CA), take in the computer names (has to be FQDNs), and send out a request for the certificates you need. Now, you no longer have to fill out the Certificate Request form or enter parameters or connect to the web enrollment service. Once the certificates are approved, there is a Retrieve button in the CertGenWizard which will allow you to retrieve the certificates that you have requested. On top of the personal certificates, the wizard will retrieve the root CA certificate.

The next step is to request and install the proper certificate from the root CA server, this needs to be done on both the gateway and the management server.

1. From both the gateway server and the management server, browse to http://dc01/certsrv
2. Request a certificate
3. Advanced certificate request
4. Create and submit a request to this CA

5. If you get a error saying that the CA must be configured to use HTTPS authentication, change the security settings for trusted sites zone, enable Initialize and script ActiveX controls not marked as safe for scripting. Then reload the page
6. Input
Name, needs to be FQDN of the machine, for example dc01.corp.contoso.local
Type of certificate needed: Other
OID: 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2
CSP: Microsoft Enhanced Cryptographic Provider v1.0
Check Mark keys as exportable
Name: needs to be FQDN of the machine, for example dc01.corp.contoso.local
7. Submit the request
8. On your root CA, open the Certification Authority console, issue the certificate under pending requests
9. On the machine that request a certificate, browse to http://dc01/certsrv
10. View the status of a pending certificate request
11. Install the certificate by clicking on it
12. Open a MMC with the Certificates snap-in, for “my user account”. Under Personal certificates, export the certificate including the private key.
13. Open a MMC with the Certificates snap-in, for “local computer”. Import the certificate under personal certificates.

When both your gateway machine and your management server has each two certificates, the next step will be to run the MOMCertImport.exe tool on your management server. This tool will import the certificate into Operations Manager, writes the serial number of the certificate to use to the registry so Operations Manager components can determine which certificate to use for authentication. Run the tool and select the certificate to use. Then restart the System Center Management service on the management server.

Now it is time to approve the new gateway server. This is done with the Microsoft.EnterpriseManagement.GatewayApprovalTool.exe. This tool depends on a dll file in the Operations Manager installation folder, copy the approval tool to that folder. Run the tool and approve your gateway, for example

Microsoft.EnterpriseManagement.GatewayApprovalTool.exe /ManagementServerName=corp-r2.corp.contoso.local /GatewayName=DMZ01 /SiteName=DMZ /Action=Create

Next step is to install the gateway server. You need to copy the MOMCertImport.exe and the suitable gateway folder (for example AMD64) from the installation source to your gateway server. You need the whole gateway folder, including MOMGateway.msi and tree cabinet files named OMGW, SCXAGTS and OMAGTMGT). The run the MOMGateway.msi as administrator. It will fail if you not run it as administrator. Input the FQDN of the management server and the name of the management group. Select a action account, if you unsure, select local system and click next. When the installation of the gateway server is complete, run MOMCertImport.exe and import the certificate. Then restart the System Center Management service (HealthService).

Open the Operations Manager console and verify that your new gateway server is green and healthy. You can now move on and start install agents.

Late yesterday the RTM of Operations Manager 2007 R2 was approved, which immediately initiated the next stage of the process … getting this latest version of Microsoft’s end-to-end monitoring product for IT environments and datacenters out to YOU! Read more in our overview whitepaper, What’s New datasheet, or download the trial, and see customer stories and more information on our pages on Microsoft.com and TechNet.

The trial version of Operations Manager 2007 R2 RTM (build 7221) is now available via the Microsoft Download Center. General Availability of the product will be 1st July 2009, at which point new and existing customers will be able to obtain the bits from their respective customer download centers, such as MVLS.

In addition to the updated product documentation, our overview whitepaper, and what’s new datasheet, newly released collateral includes a number of new datasheets that include:

Reducing the cost of data center management with Operations Manager 2007 R2
Monitoring UNIX/Linux with Operations Manager 2007 R2
Tracking Service Levels with Operations Manager 2007 R2
Interoperability Connectors for Operations Manager 2007 R2
Some of you have also have the opportunity to try our new hands on labs at our MMS and TechEd events this year, which cover topics such as installation, introduction, management pack authoring, and more. We’re busily upgrading these with the RTM bits, and they will be available for you to use via the TechNet Online virtual labs next month (June).

In addition to downloading the trial (or if you’re waiting for the upgrade or full product bits to arrive in your customer portal):

Check out our TechNet Webcast Series on Operations Manager 2007 R2:
Introducing Operations Manager 2007 R2 (Level 300)
Monitoring .NET and Web Applications with System Center Operations Manager 2007 R2
Operations Manager 2007 R2 Deployment and Upgrade Best Practices
Operations Manager 2007 R2 Agentless Client Monitoring
Successfully Monitor UNIX and Linux Alongside Your Windows Infrastructure with Operations Manager 2007 R2 (Level 300)
Developing Custom Reports and Operational Dashboards with Operations Manager 2007 R2 (Level 400)
Monitoring .NET and Web Applications with System Center Operations Manager 2007 R2
System Center Operations Manager 2007 R2 Interoperability Connectors

Watch our TechNet EDGE Video Blogs (more on their way!):
Introduction to Operations Manager R2
Visio Integration with Operations Manager 2007 R2
Microsoft Management Summit 2009 Day 1 Keynote Recap with Brad Anderson

Learn about v2.0 of the Service Level Dashboard from our Solution Accelerators team, which lets you measure and report application or system performance & availability in near real time across your organization through Microsoft SharePoint. Download the Service Level Dashboard from the System Center Catalog (available shortly).

Check out our new community portal, System Center Central for downloads, discussions with our MVPs, and much, much more!

Source: the system center team blog

By default Exchange 2007 only log logons to the server, not to which mailbox. With the following cmdlet we can enable mailbox access auditing on our mailbox servers.

Set-EventLogLevel “MSExchangeIS\9000 Private\Logons” –level low

Note that there might be times, special with older Outlook clients) when other users will access other mailboxes to see details about for example calendar appointments. So a login event can be a simple check in the calendar. When I booked a meeting between two users, with Outlook 2007, I did not notice a extra security extra.
When we have enable audit of mailbox access we can use a collection rule in Operations Manager to collect them and store them in the data warehouse. I will use event IT 1009 in this example, event ID 1009 is an indication that the specified user account logged into the specified mailbox.

Event ID 1016

Start by creating a new rule, authoring/rules/create a rule/collection rule/NT event log. The collection rule will only collect, not generate any alerts. In my example I used Windows Server 2008 Computer as target. I created the rule disable as default. Then override and enable it for a group including a couple of Exchange mailbox server computer objects.

Event ID 1016 is also interesting. When a user access a mailbox another mailbox, then its primary mailbox, you will see a event with ID 1016.
The next step is to create a report. You can use the generic Custom Event report to create a linked report showing all the events. Run the Custom Event report and select your windows server 2008 computers as objects, filter the report for example in my example Event ID equals 1009. Note that you have to check its checkbox for every report field you want to include. If you check any checkboxes you will get a empty report.

If you don’t like the default event report you can author a new in Visual Studio. You can read my guide about that here and use the following query when building the data set in Visual Studio. In this query I have two parameters, keyword01 and keyword02. That is two parameters that the report operator can input as words to search for in the event description, for example a username and a mailbox name.

SELECT Event.vEvent.DateTime, vEventPublisher.EventPublisherName AS 'EventSource', vEventLoggingComputer.ComputerName AS 'Computer',
Event.vEvent.EventDisplayNumber AS 'EventID', vEventChannel.EventChannelTitle, Event.vEventDetail.RenderedDescription AS 'EventDescription'
FROM Event.vEvent LEFT OUTER JOIN
vEventCategory ON Event.vEvent.EventCategoryRowId = vEventCategory.EventCategoryRowId LEFT OUTER JOIN
vEventPublisher ON Event.vEvent.EventPublisherRowId = vEventPublisher.EventPublisherRowId LEFT OUTER JOIN
vEventLoggingComputer ON Event.vEvent.LoggingComputerRowId = vEventLoggingComputer.EventLoggingComputerRowId LEFT OUTER JOIN
vEventLevel ON Event.vEvent.EventLevelId = vEventLevel.EventLevelId LEFT OUTER JOIN
vEventChannel ON Event.vEvent.EventChannelRowId = vEventChannel.EventChannelRowId LEFT OUTER JOIN
Event.vEventDetail ON Event.vEvent.EventOriginId = Event.vEventDetail.EventOriginId
WHERE (Event.vEvent.EventDisplayNumber = '1009' OR
Event.vEvent.EventDisplayNumber = '1016') AND (Event.vEventDetail.RenderedDescription LIKE '%' + @keyword01 + '%') AND
(Event.vEventDetail.RenderedDescription LIKE '%' + @keyword02 + '%')
ORDER BY Event.vEvent.DateTime DESC