Customer Scenario

Procedures

Install Server Certificates

SQL

• Logon to the first SSRS instance (TMS-RS-01) with complete admin privileges on the server and database tiers. Edit the .\scripts\Certs\Request-Cert-SSRS.ps1 script on the installation source and change the Subject ($_name variable) to match the target environment: ssrs.tms.local.
• Run the script. It will provide a certificate request in C:\Certificates folder on the server. Issue the certificate request(s) to the CA. Receive the certificate and import to local server’s certificate store. Export with private key and apply to remaining server(s): TMS-RS-02.

SharePoint

• Logon to the first SharePoint front end server instance (TMS-SPW-01) with complete admin privileges on the server, SP, and database tiers. Edit the .\scripts\Certs\Request-Cert-SP.ps1 script on the installation source and change the Subject ($_name variable) and Subject Alternative Names (-SANs) to match the target environment. Important: The certificate will be invalid if the FQDN in Subject does not match first line in the Subject Alternative Name (SAN) field.
• Run the script. It will provide a certificate request in C:\Certificates folder on the server. Issue the certificate request(s). Receive the certificate and import to local server’s certificate store. Export with private key and apply to remaining server(s) in the farm: TMS-SPW-02, TMS-SPA-01, and TMS-SPA-02.
• Install this certificate on the two WAP servers for the farm: WAP-TMS-01 and WAP-TMS-02.

CRM

• Log on the first CRM Front End Server (TMS-CMW-01) ) with complete admin privileges on the server and CRM. Edit the .\scripts\Certs\Request-Cert-CRM.ps1 script on the installation source and change the ($_name variable) and Subject Alternative Names (-SANs) to match the target environment. Important: The certificate will be invalid if the FQDN in Subject does not match first line in the Subject Alternative Name (SAN) field.
• Change the names to reflect the CRM front-end server URLs that match your environment for IFD:
  • TMS.xrm.tms.local
  • auth.xrm.tms.local
  • dev.xrm.tms.local
  • internalcrm.xrm.tms.local
• Run the script. It will provide a certificate request in C:\Certificates folder on the server. Issue the certificate request(s). Receive the certificate and import to local server’s certificate store. Export with private key and apply to remaining server(s): TMS-CMW-02, TMS-CMA-01, and TMS-CMA-02.
• Install this certificate on the two WAP servers for the farm: WAP-TMS-01 and WAP-TMS-02.

ADFS

• Logon to the primary ADFS server (TMS-ADFS-01) with complete admin privileges on the server and ADFS. Edit the .\scripts\Certs\Request-Cert-ADFS.ps1 script on the installation source and change the ($_name variable) to match the target environment: adfs.tms.local.
• Run the script. It will provide a certificate request in C:\Certificates folder on the server. Issue the certificate request(s). Receive the certificate and import to local server’s certificate store. Export with private key and apply to remaining secondary server(s): TMS-ADFS-02.
• Install this certificate on the two WAP servers for the farm: WAP-TMS-01 and WAP-TMS-02.

WAP

• Logon to the first WAP instance (WAP-TMS-01) as the local Administrator.
• Ensure that each of the trust chains for the enterprise and the enclave are both installed in the local server’s certificate store under the Certificates (Local Computer) > Trust Root Certification Authorities > Certificates node.
• Ensure that CRM, SP, and ADFS certificates (from previous sections) are also in the local server’s certificate store under the Certificates (Local Computer) > Personal > Certificates node.
• Repeat these steps on the second WAP instance (WAP-TMS-02).

Update SQL Reporting Services

• Logon to the first SSRS instance (TMS-RS-01) with the SharePoint installation account (SP-Install-SVC). Open Reporting Services Configuration Manager and connect to TMS-RS-01.
• Web Service URL: Select the previously imported SSRS certificate (ssrs.tms.local) in the SSL certificate drop-down menu and then click the Apply button.
• Web Service URL: Click the Advanced button and select TCP Port 80 and then click the Remove button. Click the OK button. You should now only see a single URL listed for Report Server Web Service URLs: https://ssrs.tms.local:443/ReportServer.
• Report Manager URL: Click the Advanced button and select TCP Port 80 and then click the Remove button. Click the OK button. You should now only see a single URL listed for Report Manager Site URLs: https://ssrs.tms.local:443/Reports.
• Restart SQL Reporting Services service.
• Verify the Report Server and Report Manager URLs in IE.
• Delete the old certificate in the server’s certificate store.
• Repeat these procecures on the second SSRS instance (TMS-RS-02).

Update CRM

Grant CRMAppPool Certificate Access and Update IIS

• While logged on the first CRM Front End Server (TMS-CMW-01) with complete admin privileges on the server and CRM, open an elevated command-prompt (WinKey + X > Command Prompt (Admin)) and execute MMC and load the Certificates snap-in for the Local computer.
• In the navigation pane, select Certificates (Local Computer) > Personal > Certificates node. In the details pane, right-click the tms.xrm.tms.local certificate and select All Tasks > Manage Private Keys in the shortcut menu.
• Click the Add button and add the CRMAppPool account (DOMAIN\CRM-AppPool-SVC) and grant Read permissions. Click the OK button.
• Open IIS Manager (WinKey + R > inetmgr) and right-click the Sites > Microsoft Dynamics CRM node in the navigation pane and select Edit Bindings in the shortcut menu.
• In the Site Bindings dialog box, select https and then click the Edit button. In the Edit Site Binding dialog box, click the Select button and pick the new certificate. Click the OK button. Click the Close button.
• Perform an iisreset.
• Repeat these steps the second CRM Front End Server (TMS-CMW-02).

Verify SSL

• Log on the first CRM Front End Server (TMS-CMW-01) with complete admin privileges on the server and CRM. Open Microsoft Dynamics CRM Deployment Manager.
• Right click on Microsoft Dynamics CRM in the navigation pane and select Properties in the shortcut menu.
• Click on the Web Address tab.
• Select the radio button in front of HTTPS and enter internalcrm.xrm.tms.local:443 in each of the fields. (Important: Do not put https:// in front of the addresses.) Click the OK button.

Configure Claims for Internal Access

• While logged on the first CRM Front End Server (TMS-CMW-01) with complete admin privileges on the server and CRM, open Microsoft Dynamics CRM Deployment Manager. Click the Configure Claims-Based Authentication link.
• On the Welcome page, click the Next button.
• On the Specify Security Token Service page, enter https://adfs.tms.local/federationmetadata/2007-06/federationmetadata.xml in the Federation metadata URL field and then click the Next button.
• On the Specify Encryption Certificate page, click the Select button and select the TMS.xrm.tms.local certificate and click the OK button. Click the Next button.
• On the System Checks page, review and correct any Errors or Warnings before proceeding. Click the Next button when ready.
• On the Review page, click the Apply button.
• Log on to the primary ADFS server (TMS-ADFS-01) and open AD FS Management snap-in.
• In the navigation pane of the AD FS Management snap-in, select the AD FS > Trust Relationships > Relying Party Trusts node. In the details pane, right-click Internal CRM and select Update from Federation Metadata in shortcut menu and then click the Update button.
• Log onto another server and view https://internalcrm.xrm.tms.local/TMS. in Internet Explorer to verify no errors.

Configure IFD

• While logged on the first CRM Front End Server (TMS-CMW-01) with complete admin privileges on the server and CRM, open Microsoft Dynamics CRM Deployment Manager. Click Configure Internet-Facing Deployment. The Configure Internet-Facing Deployment Wizard will launch.
• On the Welcome page, click the Next button.
• On the Server Roles page, enter the following values in the corresponding fields:
  • Web Application Server Domain: xrm.tms.local
  • Organization Web Service Domain: xrm.tms.local
  • Discovery Web Service Domain: dev.xrm.tms.local
• Click the Next button.
• On the External Domain page, enter the following value in the corresponding field:
  • External Domain: auth.xrm.tms.local
• Click the Next button.
• On the System Checks page, review and correct any Errors or Warnings before proceeding. Click the Next button when ready.
• On the Settings Review page, click the Apply button.
• When the configuration successfully completes, click the Finish button.

Configure Claims for External Access

• Log on to the primary ADFS server (TMS-ADFS-01) and open AD FS Management snap-in.
• In the navigation pane of the AD FS Management snap-in, select the AD FS > Trust Relationships > Relying Party Trusts node. In the details pane, right-click Internal CRM and select Update from Federation Metadata in shortcut menu and then click the Update button.
• Perform an iisreset on both CRM Front End Server (TMS-CMW-01 and TMS-CMW-02).

Republish CRM to WAP

• Log onto the WAP server (WAP-TMS-01) with the local Administrator account and open the Remote Access Management snap-in. Remove the CRM IFD published apps: CRM TMS, CRM AUTH, CRM DEV.
• Open PowerShell ISE elevated and edit and run the following script: .\scripts\WAP\Update-WAP-CRM.ps1

Post-Configuration

Update ADFS

Grant ADFS Read Access to the New Certificate

• Logon to the primary ADFS server (TMS-ADFS-01) as an ADFS administrator. Open an elevated command-prompt (WinKey + X > Command Prompt (Admin)) and execute MMC and load the Certificates snap-in for the Local computer.
• In the navigation pane, select Certificates (Local Computer) > Personal > Certificates node. In the details pane, right-click the adfs.tms.local certificate and select All Tasks > Manage Private Keys in the shortcut menu.
• Click the Add button and add the ADFS domain service account (DOMAIN\FsGmsa$) and grant Read permissions. Click the OK button.
• Restart adfssrv service.
• Repeat these steps the secondary ADFS server (TMS-ADFS-02).

Update ADFS Bindings

• While logged on the primary ADFS server (TMS-ADFS-01), open AD FS Management snap-in. In the navigation pane of the AD FS Management snap-in, select the AD FS > Service > Certificates node. In the actions pane, click the Add Token-Signing Certificate link and select the new certificate. Then, notify all Relying Parties of the change. Once configuration updates have been made (if any) on the RP ends, then promote the Token Signing certificate to be the primay by right-clicking it and selecting Set as Primary in the shortcut menu. Remove the secondary Token Signing certificate.
• In the actions pane, click the Add Token-Decrypting Certificate link and select the new certificate. Promote the Token Descrypting certificate to be the primay by right-clicking it and selecting Set as Primary in the shortcut menu. Remove the secondary Token Decrypting certificate.
• Open PowerShell ISE elevated and edit and run the following script: .\scripts\ADFS\Update-ADFS-Primary.ps1
• Logon to the secondary ADFS server (TMS-ADFS-02) as an ADFS administrator. Open PowerShell ISE elevated and edit and run the following script: .\scripts\ADFS\Update-ADFS-Secondary.ps1

Update ADFS Proxy Trust on WAP

• Log onto the WAP server (WAP-TMS-01) and open PowerShell ISE elevated and edit and run the following script: .\scripts\WAP\Update-WAP-Certs.ps1

Post-Configuration

Update SharePoint

Configure IIS

• Logon to the first SharePoint front end server instance (TMS-SPW-01) with complete admin privileges on the server and SP.
• Open IIS Manager (WinKey + R > inetmgr) and right-click the Sites > Extended Zone for HNSC Web App node in the navigation pane and select Edit Bindings in the shortcut menu. In the Site Bindings dialog box, select https and then click the Edit button. In the Edit Site Binding dialog box, click the Select button and pick the new certificate. Click the OK button. (Repeat for all applicable sites supporting the SharePoint farm.) Click the Close button.
• Perform an iisreset.
• Repeat these steps the remaining servers: TMS-SPW-02, TMS-SPA-01, and TMS-SPA-02.

Acquire Token-Signing Certificate from ADFS

• Log on to the primary ADFS server (TMS-ADFS-01) and open AD FS Management snap-in.
• In the navigation pane of the AD FS Management snap-in, select the AD FS > Service > Certificates node. In the details pane, double-click the Token Signing certificate. In the Certificate dialog, click the Details tab and then click the Copy to File button. Export the certificate in .cer format (without the private key and in DER encoded binary X.509) as it will be needed in subsequent steps to update the Trusted Root Authority in the SharePoint farm.

Configure SharePoint

• Logon to the first SharePoint back end server instance (TMS-SPA-01) with complete admin privileges on the server and SP.
• Copy the aforementioned ADFS token-signing certificate to the server.
• Open PowerShell ISE elevated and edit and run the following script: .\scripts\SP\ADFS\Update-SP-Certs.ps1
• Perform iisreset on all SP farm servers.

Republish SharePoint to WAP

• Log onto the WAP server (WAP-TMS-01) with the local Administrator account and open the Remote Access Management snap-in. Remove the SharePoint published apps: SP Team Site (team.tms.local) and TMS SP Content Site.
• Open PowerShell ISE elevated and edit and run the following script: .\scripts\WAP\Update-WAP-SP.ps1

Post-Configuration

Meanwhile, here are the direct links for the free downloads:

• Download the PDF (2.52 MB)
• Download the EPUB file  (5.32 MB)
• Download the Mobi for Kindle file (8.1 MB)

The following resources provide even more detailed information on Microsoft's Infrastructure-as-a-Service (IaaS) Product Line Architecture (PLA):

• IaaS PLA - Deployment Guide
• IaaS PLA - Fabric Architecture Guide
• IaaS PLA - Fabric Management Guide

The saying "necessity is the mother of invention" sums up why the latest updates to the ACS Autopilot management pack were made. If you ever have to spend some time troubleshooting problematic ACS forwarders, you may be aware of the capability to place a forwarder/collector in debug mode so as to dig deeper into the verbose log file in hope of remediating the situation. At a high level, the technique involves stopping the service, creating the TraceFlags registry key, starting the service, and then reviewing the AdtAgent.log file.

Important: As with most verbose debug logging, this should be used solely for diagnosis and you should not keep debugging enabled during normal operation.

Some folks have scripted this tedious process in a batch file which has been helpful. Others may have automated it further in PowerShell. For me, I decided to elevate and sort of “productize” the automation in the OM console as three tasks. This helps make it even easier for ACS admins and operators to troubleshoot forwarders.

Enhancements

The MP now includes three tasks which are described in the next section:

The MP now also includes a new view named Agents - Running Debug which depicts ACS forwarders in debug mode.

Guidance

So how does one leverage this debug capability in the MP? Here's how:

• Suppose you have a problematic ACS forwarder that will not forward events or keeps stopping for whatever reason. Select that target endpoint and then run the ACS - Enable Debugging task. The task will stop the AdtAgent service on the remote computer, configure it for debugging, start the AdtAgent service, and then provide output that resembles the following image.
• 
• After a few minutes the forwarder will appear in the Agents - Running Debug view. Select the forwarder in that view and then run the ACS - Read Debug Log task. The task will then read the AdtAgent.log file contents and will then provide output that resembles the following image.
• 
• Hopefully, the output will help you remediate the root cause. If the data is too cryptic or not helpful, and all other troubleshooting actions do not restore operations to the forwarder(s), then I highly recommend leveraging Microsoft Services Premier Support resources.
• Once you restore the ACS forwarder to normal operations, select the forwarder in the Agents - Running Debug view and then run the ACS - Disable Debugging task. The task will stop the AdtAgent service on the remote computer, disable debugging, delete the AdtAgent.log file, start the AdtAgent service, and then provide output that resembles the following image.
• 

Remember, do not leave forwarders in debug mode once they return to normal operations! Lastly, there are similar debugging techniques for the ACS collector(s) that one could implement via a script. I personally didn’t see the need or value in exposing that automation in a MP when an ACS admin can run such a script on the collector if/when the need arises to place it in debug mode.

The MP is unsealed and is available for download here.

While the Operations Guide for System Center 2012 - Operations Manager prescribes how to backup the ACS database, this post seeks to enable you to automatically backup important data stored on the ACS collectors. The most important item to backup on the ACS collectors is the %WINDIR%\System32\Security\AdtServer\AcsConfig.xml file which is updated by the collector every 5 minutes. Although it doesn't change as frequently as the AcsConfig.xml file, the second most important item to backup is the ACS filter and any other AdtServer Registry key modifications. If these lightweight items are copied off of the servers to another backup location, then you won't have to back up the servers hosting the ACS collector role.

Assumptions

In order to get value out of this approach, the following capabilities are assumed to be in effect in the target ACS environment:

• Availability and disaster recovery planning has been completed and factored into the ACS design and implementation.
• The ACS infrastructure may have two collectors that write security events to a single ACS database in an active/passive manner (described here).
• The ACS collector role is not co-located on the same server as the ACS database role.
• The ACS database backup is capable of including flat files stored in a directory that is shared on the network to which the ACS collector computer accounts can write.
• The ability to deploy the following in a fast manner: a Windows Server OS, the OM 2012 Management Server role, and the ACS collector role.

Implementation

Follow these steps to implement:

1. Configure the ACS database backup directory as a share and grant permissions to the ACS collector computer accounts so that they can write to the share. (By default, the scheduled task runs under SYSTEM credentials. However, as an alternative, you can change the task to run under a domain user account which will need write permissions to the share/dir instead of the computer accounts.)
2. Download the attached zip file and extract the two PS files (Backup-AcsConfig.ps1 and Set-AcsTask.ps1) and copy to the ACS collectors.
3. Log on to the ACS collector with admin privileges. Open elevated PS prompt and change directory to the local folder where the files are stored.
4. Execute Set-AcsTask.ps1. When prompted with the text “ACS configuration will need to be copied to a network share for backup”, enter the UNC path to the network share that was configured in step 1 above. When prompted with the text “Specify the directory where the Backup-AcsConfig.ps1 script is currently located”, enter the local path from step 2 above.
5. Open the Task Scheduler snap-in on the server. Select View > Show Hidden Tasks in the toolbar. In the details pane, double-click Backup-AcsConfig and inspect the task’s default settings. By default, the task runs as SYSTEM and runs once every 4 hours starting at 12:00 AM. Adjust the settings to match your environment’s RTOs and RPOs.
6. Manually verify that the task can run by right-clicking it and selecting Run in the shortcut menu. The task should execute quickly. Refresh the view and inspect the Last Run Result column in the details pane. If it failed, then ensure the remote backup share is configured with correct permissions; otherwise, examine the Task History for details on the failure. The task will also potentially log errors in the System event log as the Audit event source.
7. The remote backup share should have a XML and a REG file copied to it with the ACS collector’s server name as a prefix. Use these files if/when re-installing the ACS collector to support a restore operation.
8. Rinse and repeat above steps on other ACS collectors.

Backup-AcsConfig.zip

Beginning with OpsMgr 2007 SP1, one could install ACS backend with two ACS collectors that write security events to ACS database in an active/passive manner. This capability is still available for ACS in OM 2012 but still forces one to configure the security on the SQL database to be SQL Authentication which isn't as secure as Windows Authentication. Furthermore, it is a bit more involved to configure in a secure manner where SSL/certs are leveraged to secure communications to the SQL database. That said, the instructions in this video should enable one to configure the SQL database with Windows Authentication instead. The target environment scenario is described here.

Prerequisites

Before proceeding, the following prerequisites should have been addressed already:

• OM infrastructure implemented
• MS role installed on the 2 Windows Servers that will be the ACS collectors
• SQL 2012 database implemented (clustered for continuous availability if possible)
• 2 Windows Servers' computer accounts added to a domain security group (such as CONTOSO\ACS-SERVERS)

Implementation

Download the attached PS scripts and follow the steps in this video: 

Config-ACSDB-v1.1.zip

As stated in part 1 of this series, the task of enabling ACS forwarders on target endpoints is normally a manual procedure –and for good reason! If the automation in the accompanying “autopilot” management pack were to be enabled prematurely or without careful planning, it could potentially overwhelm the ACS backend infrastructure. However, much like the “autopilot” technology can be a good thing for flying planes and has a role to fulfill in the course of a flight, the automation specified in this management pack should only be implemented under certain conditions. “Kids, don’t try this at home.”

As reflected in the graphic above, the process of enabling ACS forwarders in a safe manner is manual at first. Then, once ~99% of the forwarders been enabled, turn on ACS autopilot to audit all target computers in a dynamic and elastic manner.

Assumptions

The following activities are assumed to have already been followed and successfully implemented in the target environment:

• Audit requirements fully factored into the design of ACS
• Appropriate level of audit policies implemented and applied against target computers to meet governance requirements
• ACS infrastructure, including storage configuration, adequately sized to address anticipated audit volume
• ACS filter properly tested and verified against audit requirements and successfully implemented on the ACS collector(s)
• Operations Manager agents automatically deployed to target computers by Configuration Manager software distribution package
• Target computers are limited to Windows servers

Note: This management pack is compatible with both OpsMgr 2007 R2 and OpsMgr 2012 infrastructures.

Implementation

Import the accompanying management pack (Microsoft.SystemCenter.ACS.Extended.xml) into the Operations Manager 2007/2012 management group and then follow these steps over the duration of the implementation of ACS forwarders:

1. In the Operations Console, click the Monitoring wunderbar. In the Monitoring navigation pane, expand the ACS folder and select the Agents – Not Running view. After several minutes, agents with the AdtAgent service not running will gradually populate this view.
2. Manually enable ACS forwarders with one hand on “the switch” (task) and one hand on “the dial” (perfmon):
• Select 10 ACS forwarders in the view by holding the CTRL button on the keyboard down and multi-selecting the target computers’ Health Service objects. Select Enable Audit Collection task in the Actions pane.
• In the Enable Audit Collection task dialog box, click the Override button. Enter the ACS collector(s) FQDN in the provided field; for example: ACS1.contoso.com, ACS2.contoso.com. Click the Override button to commit the change. Click the Run button to execute the task against the target computers.
• Using Performance Monitor on the collectors (or the Performance views in the Microsoft Audit Collection Services management pack in the Operations Console), monitor both the ACS Collector/Connected Clients and ACS Collector/Incoming Events/sec counters. Observe Database Queue % Full counter and throughout the surge and make note of the events per second (eps) that the system can withstand. Wait until the surge in new events levels out before continuing.
• Repeat this iterative step on another 10 ACS forwarders while monitoring the ACS Collector performance counters. If running Operations Manager 2012, increase the number to 20 forwarders and observe the performance counters.
• As the load gradually increases, insertion into the SQL database increases and the max throughput will approach the bounds of disk IO supporting the SQL database and transaction log. This will be reflected by the Database Queue % Full counter growing and the collector and database not able to reduce the queue fast enough. Record that system threshold and back off that number of ACS forwarders that are enabled at a time.
• Enable ACS forwarders in stages and groups that fall under the newly discovered system threshold until all desired ACS forwarders have been enabled in the target environment.
• A “cruising altitude” has now been reached and there should be few, if any, agents listed in the Agents – Not Running view.
3. Enable ACS autopilot:
• In the Operations Console, click the Authoring wunderbar. In the Authoring navigation pane, select the Rules node.
• In the details pane, Change Scope to Look for "Autopilot" and then select the Autopilot – Enable ACS Forwarders on Servers target. Click the OK button.
• In the details pane, scroll down and right-click the Autopilot – Enable ACS forwarders on Servers rule and select Override > Override the Rule > For all objects of class: Autopilot – Enable ACS forwarders on Servers in the shortcut menu.
• 
• In the Override Properties dialog box, select the Arguments checkbox and change the corresponding Override Value to be the ACS collector(s) FQDN; for example: //NoLogo "ACS1.contoso.com, ACS2.contoso.com". Select the Enabled checkbox and change the corresponding Override Value to True.
• 
• Click the OK button to commit the change and to enable autopilot.
4. Disable ACS autopilot: For a variety of reasons, the autopilot may need to be temporarily disabled; such as in the cases of ACS upgrades, event storms, etc.
• In the Operations Console, click the Authoring wunderbar. In the Authoring navigation pane, select the Rules node.
• Uncheck the Enabled checkbox on the previously configured override to the Autopilot – Enable ACS forwarders on Servers rule.
• Then re-enable once back at “cruising altitude”.

ACS-Autopilot-MP-v1.1.1.0.zip

Before one can enable ACS forwarders (manually or with the autopilot MP), the OM agent must first be deployed and the agents homed to the management group. Given the scenario described in part 1, CONTOSO leverages System Center 2012 – Configuration Manager for deploying software to Windows servers across its private cloud and diverse enterprise. This approach is especially effective when considering bandwidth and latency challenges across its WAN links. In contrast, the OM “console push” approach is dependent on SMB protocol which doesn’t work as well for this network topology scenario –where the objective is automation and a guiding principle is KISS. So we turn to leveraging a single, good-old-fashioned, software distribution package via CM 2012. The wrapper script also includes auto-remediation tasks to run once a day in order to help keep the OM agent baseline healthy.

Credits and Props

Before rolling with the show, I need to give credit to where credit is due… This battle-tested package wouldn’t be possible without the following two stellar Microsoft colleagues:

• Chris Harrod – Took the idea, made it real, and ran with it.
• Eric Hopson – Took over the responsibility to maintain the wrapper script and has scripted in new auto-remediation capabilities.

This OM agent package has been battle tested in a variety of large enterprise scenarios. For example, it is rumored that Xbox LIVE is running a derivative of this package to monitor their comprehensive infrastructure. Pretty cool!

Overview

This installation routine has been designed to be executed from within a CM 2012 (or CM 2007) package. The associated programs are advertised and assigned to target Windows servers and run every day since the script also includes auto-remediation routines. The installation supports a variety of enterprise scenarios:

• Base OM 2012 release plus and Update Rollup (This installation routine provides OM 2012 RTM plus Update Rollup 2 as an example.)
• Multiple management servers in a management group and load balancing the installs
• Dual-homed agents
• Migrating agents from one management group to another one

Preparation

To prepare the package, download and extract the attached zip file to create the following directory structure:

The following scripts should be staged in the root of the package directory:

• INSTALL-SCOM2012Agent.vbs – Performs the installation and auto-remediation routines. It’s written in VBScript to address “lowest common denominator” situations where PowerShell is unfortunately not an option.
• SetupOMAgent.cmd – Only required if deploying the agent package via Configuration Manager 2007 which is a 32-bit application. This additional wrapper script detects and bypasses Windows on Windows 64-bit (WOW64) file system redirection. (This script is not required for deployments via Configuration Manager 2012 since it is a 64-bit application.)

The following files should be staged in the subdirectories:

• AD Helper Objects
• Copy HELPEROBJECTS\AMD64\OOMADS.MSI from the OM 2012 installation source media into the x64 subdirectory.
• Copy HELPEROBJECTS\I386\OOMADS.MSI from the OM 2012 installation source media into the x86 subdirectory.
• OM 2012 agent
• Copy all files in the AGENT\AMD64 directory on the OM 2012 installation source media into the x64 subdirectory.
• Copy all files in the AGENT\I386 directory on the OM 2012 installation source media into the x86 subdirectory.
• Update rollup
• Download and extract Update Rollup 2* and copy KB2731874-x64-Agent.msp into the x64 subdirectory.
• Download and extract Update Rollup 2* and copy KB2731874-x86-Agent.msp into the x86 subdirectory.
• CleanMom utility
• Download and install the System Center Operations Manager 2007 R2 Admin Resource Kit. (This utility is beneficial for uninstalling OM 2007 R2 agents which is a common scenario when upgrading/migrating from OM 2007 to OM 2012.)
• Copy %ProgramFiles(x86)%\System Center\SystemCenter Operations Manager 2007 R2 Admin Reskit\Cleanmom\x64\CleanMom.exe to the x64 subdirectory.
• Copy %ProgramFiles(x86)%\System Center\SystemCenter Operations Manager 2007 R2 Admin Reskit\Cleanmom\x86\CleanMom.exe to the x86 subdirectory.

*Note: If installing a newer update rollup, be sure to edit the INSTALL-SCOM2012Agent.vbs file and replace (CTRL+H) the x64 and x86 updates.

Verify/edit the following three variables for the agent versions that are listed in the Environment Specifics section of the INSTALL-SCOM2012Agent.vbs file:

• strCurrentVersion – Indicates the desired end state for OM 2012 agent version –including Update Rollup.
• strMinimumVersion – Indicates the value of the base OM 2012 agent version (such as RTM). If a target server is found to have this version, then only the Update Rollup is applied.
• strOldVersion – Indicates highest version level of OM 2007 R2 (including cumulative update) that could be found in the target environment. If a target server is found to have this version, or an older version, then the agent is completely uninstalled (see note above).

Syntax

Understanding the configuration of the Operations Manager management group(s) in the enterprise is required to create the correct installation string with the following syntax:

INSTALL-SCOM2012Agent.vbs /MG:MG2 /MS:OMSVR-MS1,OMSVR-MS2,OMSVR-MS3,OMSVR-MS4 /LEGACY:MG1

• MG – [Mandatory parameter] Name of the management group to which the agent is to be homed.
• MS – [Mandatory parameter] Name(s) of management servers in the management group which the installation script will randomly select to home the agent.
• LEGACY – [Optional parameter] Name(s) of the management group(s) to which the agent is to not be homed.

If the SetupOMAgent.cmd script will also be used for CM 2007 scenarios, then use the derived command-line from above and fill in the appropriate information in place of the asterisks:

%CWD%%ScriptName% /MG:**************** /MS:**************** /LEGACY:**************** >> %LogFile

Repeat this step on the remaining three lines in the script that have this pattern. Close and save the script.

Deployment

Make the following deployment configurations in Configuration Manager 2007/2012:

• Package – Create a package in Configuration Manager with entire directory structure and files previously created.
• Program – Create a program for the appropriate version of Configuration Manager:
• CM 2012: INSTALL-SCOM2012Agent.vbs /MG:MG2 /MS:OMSVR-MS1,OMSVR-MS2,OMSVR-MS3,OMSVR-MS4 /LEGACY:MG1
• CM 2007: SetupOMAgent.cmd
• Advertisement – Mandatory/assigned with a schedule of once per day.
• Collection – Target servers that match the scope of the Operations Manager 2012 management group in the target environment. Be sure to only use dynamic collection membership rules.

After testing the OM agent package against use cases that represent the target environment, proceed to pilot and then fully deploy the agent. Monitor and remediate the distribution to ensure full coverage.

You are now 1 step closer to enabling ACS autopilot in Part 3…

OM2012AgentInstallPkg-v2.9.zip

In order to automatically audit security events from Windows servers that are provisioned dynamically to private clouds, branch offices and the entire enterprise; Microsoft recommends Audit Collection Services (ACS) which is included in System Center 2012 - Operations Manager. However, ACS does not natively expose the capability to audit ACS forwarders on Windows servers as they come and go in an “elastic” manner –and for good reason! If the automation in the “autopilot” management pack were to be enabled prematurely or without careful planning, it could potentially overwhelm the ACS backend infrastructure.

So how do you audit Windows servers in an automated manner when one of the key attributes of a private cloud is “rapid elasticity”?

"Rapid elasticity. Capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time." - The NIST Definition of Cloud Computing, Special Publication 800-145

This mini-series seeks to answer that need with ACS “autopilot”. Before we get to that capability, let’s “set the table” with a common auditing scenario in customer enterprises:

• CONTOSO is a large, multi-national company with a private cloud, a datacenter, and many branch offices around the world. They are having to “do more with less” in a challenging economy and have sought to cut operational costs down through economies-of-scale and by consolidating its IT staff into a single org and hierarchy. This has helped them simplify their OM 2012 management group design greatly with a single MG monitoring all Windows servers in their enterprise.
• CONTOSO has also implemented a SIEM solution that enables it address governance controls for SOX compliance. They have internal auditors who routinely run reports in their ACS and SIEM solutions to ensure compliance.
• OM 2012 and ACS and have been “scaled up and out” to handle current and anticipated load. CONTOSO engaged Microsoft Consulting Services who followed best practices in scaling the solutions correctly. :-)
• OM 2012 and ACS have been designed and implemented with role separation (auditors vs. admins) specifically in mind.

The following conceptual diagram depicts the single management group scenario which will be referenced throughout this mini-series (and possibly others in the future):

Now that the OM 2012 and ACS infrastructures have been fully implemented to address monitoring and audit requirements, we can move on to part 2 where the OM 2012 agents are automatically deployed.

Eric Fitzgerald’s blog
http://blogs.msdn.com/b/ericfitz

"Chapter 10: Security and Compliance" in the "System Center 2012 Operations Manager Unleashed" book, 2nd Edition by Kerrie Meyler, Cameron Fuller, John Joyner; Sams Publishing, February 2013
http://opsmgrunleashed.wordpress.com

"Chapter 15: Monitoring Audit Collection Services" in the "System Center Operations Manager 2007 Unleashed" book by Kerrie Meyler, Cameron Fuller, John Joyner, Andy Dominey; Sams Publishing, March 2008
http://opsmgrunleashed.wordpress.com

System Center 2012 - Operations Manager Technical Documentation (Online)
http://go.microsoft.com/fwlink/?LinkId=231676

System Center 2012 - Operations Manager Technical Documentation (Offline)
http://go.microsoft.com/fwlink/?LinkId=246682

Operations Guide for System Center 2012 - Operations Manager
http://technet.microsoft.com/en-US/library/hh212887.aspx

Collecting Security Events Using Audit Collection Services in Operations Manager
http://technet.microsoft.com/en-us/library/hh212908.aspx

"ACS Internals" blog post by Kevin Holman
http://blogs.technet.com/b/kevinholman/archive/2008/03/07/acs-internals-part-1.aspx

System Center 2012 Operations Manager Survival Guide
http://social.technet.microsoft.com/wiki/contents/articles/7809.system-center-2012-operations-manager-survival-guide.aspx

System Center - Operations Manager Forums
http://social.technet.microsoft.com/Forums/en-US/category/systemcenteroperationsmanager

"Auditing and Compliance in Windows Server 2008" by Rob Campbell and Joel Yoker; TechNet Magazine, March 2008
http://technet.microsoft.com/en-us/magazine/2008.03.auditing.aspx

Chapter 3 and Chapter 8 in the "Windows Server 2008 Security Resource Kit" book by Jesper M. Johansson; Microsoft Press, 2008
http://www.microsoft.com/learning/en/us/book.aspx?id=11841

Advanced Security Audit Policy Step-by-Step Guide
http://go.microsoft.com/fwlink/p/?LinkId=231804

NIST’s Guide to Computer Security Log Management (SP800-92)
http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf