1. Monitoring untrusted domains with SCOM 2012 SP1
Predrag Oparnica
Senior Premier Field Engineer

2. Topics Gateway Server Untrusted domain: Common Failover Scenario
Demo 1: Scenario with Enterprise CA and Gateway server (as part of DMZ zone)
Demo 2: Scenario with Stand Alone CA and Stand Alone server (workgroup server)
Managing Untrusted domain
11/11/2018

3. Gateway Server Gateway Server
The gateway server allows Operations Manager to discover target computers across untrusted domains and provides communication between the target computer and the management server. You use certificates to encrypt the data between the management server and the gateway server.
Although a gateway server is not necessary to communicate with computers in untrusted domains, if you do not use this server, you must open paths in the firewall between each agent and the management server. In addition, each agent will then require a certificate that needs to be managed to enable communication with the management server.
The gateway server cuts down on the administrative overhead required by allowing a single path through the firewall (TCP Port 5723) and management of certificates only for the gateway server and its management server.
In a workgroup environment, you need to install certificates for communication between the agents and the gateway server. This is because there is no Kerberos authentication between the workgroup agents and the gateway server.
In a domain environment, the gateway server is installed on a computer in the same domain where the target computers are located. Therefore, the gateway becomes the computer where discovery of target computers is performed. This is possible because there is Kerberos authentication between the domain-joined agents and the domain-joined gateway server.
If the management server to which the gateway server was connected becomes unavailable, you can configure the gateway server to fail over to another management server within the management group. Currently, there is a limit of one gateway per server supporting only one management group.
If the gateway server becomes unavailable, you can configure the agent to fail over to another gateway server.
The configuration of the failover scenarios mentioned above is only possible through Operations Manager command shell.
The Microsoft Operations Manager product team has stated that a gateway server is a good candidate for virtualization. If server consolidation is required, then consider moving the gateway server role to a virtual server.
11/11/2018

4. Untrusted domain: Common Failover Scenario
Mutual Auth is
Kerberos
Domain A
11/11/2018

5. Untrusted domain: Common Failover Scenario
Mutual Auth is
Kerberos
Domain A
Domain B
No Trust
Install and Manage Certificate MS1
Install and Manage Certificate GTW1
Using Port: 5723
Mutual Authentication is
Certificate Based
Primary
11/11/2018

6. Untrusted domain: Common Failover Scenario
Mutual Auth is
Kerberos
Domain A
Domain B
No Trust
Install and Manage Certificate MS1
Install and Manage Certificate GTW1
Using Port: 5723
Mutual Authentication is
Certificate Based
Install and Manage Certificate MS2
Install and Manage Certificate GTW2
Primary
11/11/2018

7. Untrusted domain: Common Failover Scenario
Mutual Auth is
Kerberos
Domain A
Domain B
No Trust
Install and Manage Certificate MS1
Install and Manage Certificate GTW1
Using Port: 5723
Mutual Authentication is
Certificate Based
Install and Manage Certificate MS2
Install and Manage Certificate GTW2
Primary
Secondary / Failover
11/11/2018

8. Configuring Gateway Servers for Failover.
#Set specific Gateway Server (GTW) to use MS1 as Primary and MS2 as Failover
$primaryMS = Get-SCOMManagementServer | where {$_.Name –eq ‘MS1.DOMAIN.COM'} $failoverMS = Get-SCOMManagementServer | where {$_.Name –eq ‘MS2.DOMAIN.COM'} $gatewayMS = Get-SCOMManagementServer | where {$_.Name –eq 'GTW.DOMAIN.COM'} Set-SCOMParentManagementServer -GatewayServer: $gatewayMS -PrimaryServer: $primaryMS Set-SCOMParentManagementServer -GatewayServer: $gatewayMS -FailoverServer: $failoverMS
Configuring Gateway Servers for Failover
Although gateway servers can communicate with any management server in the management group, failover between management servers must be configured. In this scenario, the secondary management servers are identified as targets for gateway server failover.
Use the Set-ManagementServer-gatewayManagementServer command in Operations Manager Shell, as shown in the following example, to configure a gateway server to failover to multiple management servers. The commands can be run from any Command Shell in the management group.
Configure Gateway Server Failover
Log on to the Management Server with an account that is a member of the Administrators role for the management group.
On the Windows desktop, click Start, point to Programs, point to System Center Operations Manager, and then click Command Shell.
In Command Shell, follow the example that is described in the next section.
11/11/2018

9. Configuring Agent Gateways for Failover.
#Set Agents reporting to GTW1 - Failover to GTW2
$primaryMS = Get-SCOMManagementServer | where {$_.Name –eq 'GTW1.DOMAIN.COM'}
$failoverMS = Get-SCOMManagementServer | where {$_.Name –eq 'GTW2.DOMAIN.COM'}
$agent = Get-SCOMAgent | where {$_.PrimaryManagementServerName -eq 'GTW1.DOMAIN.COM'}
Set-SCOMParentManagementServer -Agent: $agent -PrimaryServer: $primaryMS
Set-SCOMParentManagementServer -Agent: $agent -FailoverServer: $failoverMS
Configuring Gateway Servers for Failover
Although gateway servers can communicate with any management server in the management group, failover between management servers must be configured. In this scenario, the secondary management servers are identified as targets for gateway server failover.
Use the Set-ManagementServer-gatewayManagementServer command in Operations Manager Shell, as shown in the following example, to configure a gateway server to failover to multiple management servers. The commands can be run from any Command Shell in the management group.
Configure Gateway Server Failover
Log on to the Management Server with an account that is a member of the Administrators role for the management group.
On the Windows desktop, click Start, point to Programs, point to System Center Operations Manager, and then click Command Shell.
In Command Shell, follow the example that is described in the next section.
11/11/2018

10. Mutual Authentication is
Scenario with Enterprise CA and Gateway server (as part of DMZ zone)
Demo 1
No Trust
Using Port: 5723
Mutual Authentication is
Certificate Based
CONTOSO-OM2012
CONTOSO-RS
PRO-SCOM-A
GTW
CA-ENT
11/11/2018

11. Mutual Authentication is
Scenario with Stand Alone CA and Stand Alone server (workgroup server)
Demo 2
No Trust
Using Port: 5723
Mutual Authentication is
Certificate Based
CONTOSO-OM2012
PRO-SCOM-2A
CA-SA
STANDALONE
11/11/2018

12. Managing Untrusted domain
No push for Workgroup servers – only manual install
Gateway server(s) as management point – push point
Agent prerequisites
Agent push requirements
11/11/2018

13. Push agent in untrusted domain
Agent Prerequisites:
Supported Operating System Version
Windows Installer 3.1
MSXML 6 Parser
5723
Agent push requirements (including firewall ports):
The account being used to push the agent must have local admin rights on the targeted agent machine.
The following ports must be open:
RPC endpoint mapper Port number: 135 Protocol: TCP/UDP
RPC/DCOM High ports (2000/2003 OS) Ports Protocol: TCP/UDP
RPC/DCOM High ports (2008 OS) Ports Protocol: TCP/UDP
NetBIOS name service Port number: 137 Protocol: TCP/UDP
NetBIOS session service Port number: 139 Protocol: TCP/UDP
SMB over IP Port number: 445 Protocol: TCP
MOM Channel Port number: Protocol: TCP/UDP
The following services must be set:
Display Name:  Netlogon Started Auto Running
Display Name:  Windows Installer Started Manual Running
Display Name:  Automatic Updates Started Auto Running
Agent Prerequisites:
Supported Operating System Version (see below)
Windows Installer 3.1
MSXML 6 Parser
Agent push requirements (including firewall ports):
The account being used to push the agent must have local admin rights on the targeted agent machine.
The following ports must be open:
RPC endpoint mapper                              Port number: 135             Protocol: TCP/UDP
*RPC/DCOM High ports (2000/2003 OS)    Ports               Protocol: TCP/UDP
*RPC/DCOM High ports (2008 OS)            Ports            Protocol: TCP/UDP
NetBIOS name service                             Port number: 137             Protocol: TCP/UDP
NetBIOS session service                           Port number: 139             Protocol: TCP/UDP
SMB over IP                                            Port number: 445             Protocol: TCP
MOM Channel                                          Port number: 5723           Protocol: TCP/UDP
The following services must be set:
Display Name:  Netlogon                           Started                 Auto      Running
**Display Name:  Remote Registry            Started                 Auto      Running
Display Name:  Windows Installer              Started                 Manual   Running
Display Name:  Automatic Updates             Started                 Auto      Running
*The RPC/DCOM High ports are required for RPC communications.  This is generally why we don't recommend/support agent push in a heavily firewalled environment, because opening these port ranges creates a potential security issue that negates the firewall boundary.  For more information:
11/11/2018

14. Questions ?
11/11/2018

15. Senior Premier Field Engineer proparni@microsoft.com
Contact
Predrag Oparnica
Senior Premier Field Engineer
© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION