Small and medium-size organizations (those with about 500 employees or less) have historically been less able to take advantage of scaling economies because they are small “islands” of technology. The smaller organization usually has a higher average Total Cost of Ownership (TCO) for its IT assets; this is from the increased manual work involved in maintaining the network and the friction and mistakes that happen from reinventing the wheel, over and over.

The challenge in extending large organization-style IT efficiencies to the smaller network is rooted in the difficulty SMBs face in adopting enterprise IT management techniques. For example, using the Information Technology Infrastructure Library (ITIL), the internationally accepted framework of best practice approaches to IT service delivery, is not something that a SMB network administrator is typically familiar with. The smaller organization rarely has long-range strategic technology plans, including those of IT asset life cycle management. Without a mature management approach such as ITIL and lacking multiyear IT planning, the SMB is unable to make dramatic advances in increasing IT efficiency and lowering the TCO of its IT assets.

A common characteristic of IT departments of both traditional organizations and IT businesses is that the larger the IT department, the more likely that the individual members are specialists, rather than IT generalists. Microsoft has identified this demographic as a key ingredient in the planning behind its ROM offering. It is the nature of the larger organization, including teams of specialized experts, that allows the large network to adopt strategies such as ITIL that have a dramatic impact on TCO. Because the SMB IT staff usually consists of IT generalists, operations management approaches and strategies do not play well in that space. This phenomenon produces a natural divide between the enterprise approach and the SMB approach to managing IT, and it pervades every aspect of the IT industry.

Enterprise IT management approaches outsourcing IT services using the vehicle of the Service Level Agreement (SLA). A SLA is a contract between a customer and a service provider specifying the terms for delivering an IT service. SLAs generally focus on the application needed by the customer. For example, a SLA for Exchange services might specify that employees can log into their mailboxes and use Exchange 99.99% of the time, equating to allowing less than 4 minutes of mailbox unavailability per month. If the service provider fails to deliver that level of service uptime, a SLA violation occurs. Depending on the wording of the SLA, SLA violations can result in the service provider paying the customer a penalty, and can even lead to automatic cancellation of the contract.

A primary benefit of the SLA mechanism is that it aligns the business goals of the customer and the service provider. Both parties have incentive to achieve the uptime metrics specified in the SLA. When things break, the burden is on the service provider to fix the problem, rather than the customer. This self-enforcing, shared-goals arrangement permits the customer to focus its IT department on strategic goals specific to that industry and business, and frees the customer from worrying about supporting the hardware and software platforms used to deliver the service. If one service provider cannot deliver the service properly, the customer finds another service provider. Just as importantly, the customer enjoys fixed costs to use the delivered service for the period of the SLA, regardless of how often the service provider has to perform preventative or corrective maintenance on the involved hardware and software platforms.

SLAs, with their many attendant business benefits, have been a staple in the enterprise space for over a decade. Large organizations (such as airlines and credit card companies) outsource some portions of their infrastructure to other large organizations such as IBM or EDS. Because the customers and the service providers both are large organizations, employing enterprise methodologies for service delivery is natural and straightforward.

Characteristics of the enterprise space include centralized datacenters, uniformity in supported technologies and devices, and secure private connectivity between Network Operations Centers (NOCs) and managed computers and devices. Those characteristics of the enterprise space contrast sharply with the SMB networked landscape. SMB networks (in aggregate) are extremely decentralized, do not feature uniform technology sets, and are not equipped for secure remote access by service providers. From the disjointed, patchwork nature of the IT business in the SMB space, a paradigm sometimes called “break-fix” has emerged as a primary business model for many SMB service providers. Quite simply, the service provider waits for things to break, is called by the customer, dispatches the technical staff to fix the problem, and bills the customer for the repair costs. This upside-down model actually incents the service provider when the customer has problems! The model is diametrically different from the planned and preventive approach espoused by ITIL.

Of course, many SMB service providers also have a consulting component and assist customers with designing and deploying new hardware and software. This work is often contracted for via a Statement of Work or similar document, defining that a project is completed within a certain timeframe. Customers may retain a legitimate suspicion that there may be a conflict of interest where the service provider (not necessarily consciously) will deploy solutions that will break and require periodic fixing (by that service provider of course).

The combination of project-based and break-fix revenue is how the service provider stays in business. There are numerous downsides to this model:

In particular, the inability to forecast accurate future revenue hampers the SMB service provider’s ability to attract investment and grow to the point where it could start specializing staff members and introducing enterprise management techniques!

The challenge is for IT service companies to transition their businesses from those that depend on project-based and break-fix revenue, to subscription-based business models based on SLAs. In recent years, a new sector of the IT industry known as “managed services” has emerged as a transformative vehicle for the IT service provider. A September 12, 2007 New York Times article titled “Outsourcing I.T. To Unlikely Places, Like America” identifies four trends as contributing to the success of the rising managed services industry:

For individual IT service providers that transition to becoming MSPs and joining the managed services industry, the opportunity for growth and stabilization is enormous. The economics are also overpowering for the SMB customers, because they pay less in managed services fees than they did with traditional IT service delivery models such as break-fix, while enjoying dramatically increased availability of the IT services they use to conduct their primary business.

Microsoft has published a number of statistics that validate the large and growing market for managed services in the SMB space, including the following:

Remote Operations Manager is Microsoft’s solution to help its partners that are SMB service partners transform their business models. This transformation is a win-win-win circumstance:

Although Essentials has its roots in OpsMgr and uses the same Agent Component, understand that the primary deployment scenario for Essentials does not involve OpsMgr or ROM. Essentials is marketed primarily to the SMB network administrator as a standalone, comprehensive management solution for his or her environment. Essentials will be bundled with the new multiserver Microsoft offering for the mid-market (code name “Centro”). Intel, which has built its System Management Software 2.0 solution around Essentials 2007, is distributing Essentials as well.

These offerings mean there is going to be a lot of Essentials installations out there! Many administrators of smaller Microsoft networks will use Essentials to manage their networks; for a good percentage of them, Essentials may be their first experience with network management tools. Let’s look at the Essentials console. At first glance, this console is very similar to the OpsMgr Operations console, but look more closely! Figure 21.1 displays the Essentials console, focusing on the Computers navigation space.

Figure 21.1. The Computers pane includes WSUS status; this is unique to Essentials.

OpsMgr administrators may be jealous of their Essentials counterparts when they see the attractive presentation of computer details in the Essentials console—the Computers space shown in Figure 21.1 is unique to Essentials, and it allows the administrator to browse the status of his or her managed computers. The Essentials Computers view combines inventory data provided by WSUS and health status from the Agent Component. Notice in Figure 21.1 we highlighted the Updates and Software console spaces (these are also unique to Essentials):

Although the Updates and Software components are wonderful features for the Essentials administrator, the ROM solution actually does not offer a collective access mechanism into these two Essentials functions.

In the first release of ROM, the service provider running ROM only has a central view of the Essentials console functions that already exist in the OpsMgr Operations console. Data from managed customer computers appear in the ROM Monitoring, Administration, Authoring, and Reporting spaces—the same navigation spaces shared between the OpsMgr and Essentials consoles. The ROM service provider cannot centrally view or interact with the Computers, Updates, or Software spaces of its customers.

In one sense, Essentials features are a subset of those in OpsMgr, because OpsMgr features such as the Audit Control System (ACS) and My Workspace pane are not present in Essentials. Yet, in another sense, Essentials features are also a superset that includes most OpsMgr features and adds functionality not present in OpsMgr. Chapter 2, “What’s New,” includes two tables that display the differences between Essentials and other Microsoft System Center products:

Some of these differences deal with market positioning and licensing schemes and may not immediately make sense. Technically, the composition of the Essentials server is more cut and dried. An Essentials 2007 server in the Remote Operations Manager solution consists of three entities:

The ROM solution performs a bit of a magic trick. Here we are pulling the covers off the essence of Remote Operations Manager: the sleeping OpsMgr Gateway Server Component hidden in every Essentials server. Microsoft created the Gateway Server Component, new with OpsMgr 2007, for customers that need to monitor computers in untrusted domains, possibly at remote sites without a direct network or VPN connection. Both MOM 2000 and 2005 required a one-way domain trust and routed network connection between management servers and managed computers to accomplish a similar feat. This configuration had significant overhead and imposed scaling limitations on those service providers that used a multitenant MOM solution to deliver managed services.

We cover using the Gateway Server Component in management group architecture in Chapter 5, “Planning Complex Configurations,” and Chapter 10, “Complex Configurations.” The ROM solution transplants that identical gateway functionality—the Gateway Server Component of OpsMgr links the customer’s Essentials server to the ROM instance at the service provider.

The Gateway Server Component is not a separate piece of software; it is an additional functionality of the Health service available on every Essentials Server Component in any management group. Here’s the magic: The ROM solution leverages the flexibility of a management server in one management group (the Essentials management group) to also be a gateway server for another management group (the ROM management group), in a sense dual-homing the management server!

When a customer’s Essentials server is converted to Service Provider mode, the gateway server functionality is activated and the Essentials server is permitted to proxy OpsMgr Agent Component connections between other computers on the customer network and ROM. The Essentials server becomes a gateway server in the Remote Operations Manager management group while remaining a fully functional Essentials server.

However, as far as the ROM service provider is concerned, the customer’s (Essentials) server is technically an OpsMgr gateway server. For this reason, the ROM solution differentiates little between an Essentials server and a gateway server configuration at the customer network. Although some features of the Service Provider management pack only function when the customer gateway server is an Essentials server, native OpsMgr gateway servers and Essentials servers in Service Provider mode are generally interchangeable.

The native behavior for the OpsMgr Agent and Management Server Components in authenticating with one another is through Kerberos, the default Windows Active Directory authentication process. Managing computers in other domains seamlessly with OpsMgr, including features such as automatic and push installation of agents, requires a trust relationship and the routing of many Windows domain protocols, such as private DNS and Lightweight Directory Access Protocol (LDAP), as well as NetBIOS over TCP/IP (NBT). Because those networking elements cannot traverse Internet firewalls, we use private networks or VPNs to route the native OpsMgr agent/server communications between remote computers and the OpsMgr management group core components.

Microsoft needed a way to extend its System Center–based management to remote computers in untrusted domains and even workgroups, and in a more seamless manner than the model required with native Kerberos authentication (which involves Active Directory forests, domains, and trusts). Microsoft selected a Public Key Infrastructure (PKI) approach. This takes place by issuing the gateway servers of the ROM service provider and the Gateway Server Component of the customer Essentials server digital certificates from the same trusted Certificate Authority (CA). Fundamentally, the organizations are federated by virtue of their mutual trust of the same CA, a mutual authentication system that extends beyond any one organization’s Active Directory (AD).

In addition to furnishing a means of authentication, the digital certificates are dual-purposed for encrypting communications between the gateway servers. The Secure Sockets Layer (SSL) connection on TCP port 5723 is encrypted with the digital certificate issued for authentication purposes. This means that in order for a validated SSL connection to be established, the host name on the certificate (issued by the mutually trusted CA) must match the expected DNS host name of the remote server.

This is a PKI scenario where you do not want to use a publicly trusted root CA certificate provider. The ROM service provider must utilize a private CA, because possessing the specific private trusted root certificate is part of the ROM security mechanism. Using a public CA such as VeriSign compromises a portion of the ROM security, because it would be easy to obtain the trusted root certificate. You can utilize either a standalone or an enterprise CA infrastructure for this purpose.

The ROM solution is Internet-centric. You can begin to sketch the minimum implementation of ROM using an Internet cloud and a pair of firewalls on each end of a communication channel:

The ROM solution does not support any direct communication between a remote customer Essentials server and the OpsMgr management server. Although it is technically feasible, Microsoft believes there are security mandates for supporting communication only between a remote customer Essentials server and an OpsMgr gateway server. For example, there is the security tier isolation created by the fact that gateway servers (that might be Internet-facing) do not have direct write access to the OpsMgr Operational database, as do management servers.

For this security reason, the ROM provider must minimally provision at least one gateway server in addition to the minimal all-in-one deployment scenario of an OpsMgr management group. In other words, the minimal installation would include all OpsMgr components on a single server and one Gateway Server Component on an additional server. Your gateway server can be a virtual server, provided there is appropriate network-level security—for example by associating the network adapter of the gateway server virtual machines (VMs) with a DMZ, perimeter network, or other network-isolation scheme such as virtual LANs (VLANs).

For security reasons, the gateway server should be in a separate secure domain from that of the OpsMgr management group, or in a hardened workgroup configuration. An inbound firewall publishing rule is created on the firewall of the ROM provider, mapping an Internet IP to the private IP of the gateway server. Figure 21.2 illustrates the minimum architecture for deploying the ROM solution.

Figure 21.2. The minimum configuration of ROM, highlighting the mutually trusted CA.

Figure 21.2 highlights the central importance of the Certificate Authority in the ROM solution. Notice the management server, the gateway server, and the Essentials server are each issued digital certificates by the same mutually trusted CA. The certificates are issued using the Fully Qualified Domain Names (FQDNs) that match the DNS records or the hosts file name records each server uses to locate the other server with. Each server is issued one certificate that is used for all encrypted gateway server traffic on that server, and each server is configured to use only one certificate at a time.

The minimum configuration of Remote Operations Manager shown in Figure 21.2 is suitable for the Lab, Pilot, and Proof of Concept phases. The capacity of such a configuration on adequate hardware could support perhaps 10 customers (with Essentials) and 100 managed computers (average 10 per customer). However, this minimal configuration has a big single point of failure: the all-in-one management server at the ROM provider. Risk analysis shows that the economic value of a ROM instance increases rapidly as customers are added. It just doesn’t make business sense to deploy ROM in this minimal configuration when SLAs and contracts are involved.

Of course, it is not mandatory to employ the ROM solution as part of a SLA-based offering. Service providers can use ROM technology to achieve a central view of their customers’ network health, perhaps only for the service provider’s convenience, or to leverage the Web console or Mobile console features of ROM (which are not available with Essentials). However, because the service provider is paying a per-computer, per-month license fee (SPLA) for each customer computer in the ROM instance, ROM is by no means free. Most likely, you will see ROM employed as a value-add to a managed services offering that delivers applications of a stated availability and capacity. ROM itself is the centerpiece of the solution, providing sensors to detect problems, built-in Microsoft best-practice response to events, and reports to verify compliance with SLAs.

The ROM instance becomes a business-critical service for every managed services customer network, requiring accommodations for fault tolerance and redundancy in architecture of the ROM management group. At the least, a pair of gateway servers, a pair of management servers, a clustered Root Management Server (RMS), and a clustered Operational database will remove the single points of failure in maintaining continuity of monitoring operations.

In addition to the minimum configuration of the OpsMgr ROM instance (such as the Certificate Authority and gateway server), there is a big piece of the Remote Operations Manager solution optionally installed on the customer network. Remote Web Workplace (RWW) is a web-based Remote Desktop Protocol (RDP) proxy application. When the service provider does not have a VPN or other access to the customer’s private network, RWW provides a secure means for support engineers to remotely control managed customer computers over the Internet.

Service provider staff periodically require RDP access to managed customer computers. RDP allows them to assist with customer service requests and perform routine and unscheduled maintenance. By installing RWW on the customer’s Essentials server and making two changes on the customer’s firewall, you create a secure portal between the ROM service provider network and the customer network. The key feature of RWW is to actively proxy Internet-facing proprietary TCP port 4125 to the inside-facing standard port used by Terminal Services on client computers, TCP port 3389. RWW securely routes the RDP application across those ports and is a single-purpose application gateway.

Communicating with managed customer computers in the RWW scenario takes place differently than the normal OpsMgr gateway server-to-gateway server traffic on TCP port 5723. By using the RWW web portal, the connection is between the service provider’s browser and the customer’s Essentials server website over the Internet. You first establish an inbound browser-based connection to the RWW web portal on SSL port 443 with conventional HTTPS. After authenticating with the server and selecting the computer to connect to, the workstation sends a second inbound connection on port 4125. The RWW translates this to port 3389, creating an application-layer (RDP) bridge to the computer you selected. Look at Figure 21.3, where the top-center section highlights that the customer firewall must permit inbound TCP ports 443 and 4125 for RWW to function.

Figure 21.3. The web browser on a workstation uses the reason for RWW: RDP proxy.

Publishing and using RWW is more secure than direct Remote Desktop Protocol via a VPN, because removing the VPN removes any opportunity for undesired traffic to come over a VPN connection into the protected customer network. You can safely use RWW from public, kiosk-type computers, which is not an option when VPN is in the picture. In addition, there is nothing left on the remote computer (such as a VPN connection definition) to be exploited to gain access to the customer network. More than one simultaneous user of RWW is supported, so multiple IT employees can work independently with the same customer network. You can work on multiple customer computer desktops at the same time by opening new Remote Web Workplace sessions from your workstation.

Of course, there is always the option to publish the customer Essentials server RDP port 3389 and establish the terminal server connection directly to the desktop of the server. That is a less secure solution compared to the multilayer security added by using the RDP proxy features of RWW. There are several security benefits to employing RWW compared to directly publishing the RDP port 3389 of the Essentials server:

The Remote Operations Manager product is licensed only to Microsoft partners that are service providers, by definition those partners who license ROM components under the Service Provider License Agreement (SPLA). Yet, many Microsoft partners with customers in the SMB space can leverage ROM to participate in the delivery of managed services without becoming traditional service providers. The Master Hoster concept recognizes a new partner-to-partner opportunity created by ROM.

In this solution, Microsoft partners have the option of attaching their SMB customer networks to a backend Network Operations Center (NOC) running ROM, the Master Hoster. The partner retains the customer relationship and optionally uses Essentials independently for workstation management. The servers and network devices are under SLA with the ROM service provider; essentially the partner is outsourcing the continuous eyes-on of the NOC (and the enterprise OpsMgr infrastructure) of the Master Hoster. Deploying the OpsMgr Web console with role-based security is key to sharing managed computer health information between customer contacts, partner contacts, and NOC staff.

Figure 21.4 illustrates the relationship between the Microsoft System Center products in the ROM Master Hoster scenario, with the Master Hoster, the partners, and the customer. Notice the Master Hoster handles the per-computer, per-month Service Provider Access License (SAL) payment to Microsoft under the terms of a Service Provider License Agreement (SPLA). The Master Hoster will deliver the remote NOC services for the partner.

Figure 21.4. The Managed Services Provider (MSP) partner leverages the ROM NOC.

To deliver software as a service to customers, which is what ROM facilitates, you have to invest in infrastructure. The operator of the ROM instance(s) at the Master Hoster is a larger Microsoft partner. This partner can staff the NOC with Level 1 engineers 24×7×365 and have additional specialized staff and support partners available to immediately escalate unresolved events to Level 2 and 3 engineers and necessary Subject Matter Experts (SMEs), thus supporting SLAs on applications and services.

The Master Hoster runs scalable and highly redundant instance(s) of ROM, installing OpsMgr in similar configurations to those used by large enterprise OpsMgr customers. The Master Hoster NOC hardware and staff may exist in different locations, with the hardware located in an Internet datacenter and the staff in a secure NOC with emergency generator power that has redundant remote access paths to the datacenter. Figure 21.5 shows the core components of the OpsMgr management group, optimized for supporting the ROM scenario.

Figure 21.5. ROM management group core components, includes clustered servers.

Customers-per-Gateway Capacity

The five management servers shown in Figure 21.5 can comfortably support 2000–4000 or more direct-attached agent computers with n+1 redundancy, meaning that even if one management server is not operating, there is still enough capacity to support the production load. However, in the ROM solution, the only computers agent-managed by the ROM management servers are the server components and possibly the workstations of the NOC. All customer computers and devices are managed via a gateway-to-gateway server connection. Figure 21.6 shows the DMZ side of the ROM Master Hoster infrastructure and illustrates the five management servers in the NOC core from Figure 21.5 communicating with 10 gateway servers in a DMZ network.

Figure 21.6. Gateway servers and the Web Console server are published from the DMZ.

The 10 gateway servers in the DMZ shown in Figure 21.6 offer a secure communications interface for at least 100 (and as many as 200 or more) customer networks. Microsoft recommends a baseline of 10 remote customer networks (Essentials or gateway servers) assigned per ROM service provider gateway server. This recommendation is more due to a desire to create a firebreak, or security bulkhead, between certain quantities of customer networks than it is for capacity reasons.

Connecting up to 20 customer networks to each of the 10 gateway servers puts the capacity of the ROM instance pictured at about 2000 to 4000 managed computers. The NOC physical plant for the Master Hoster should be carefully designed to scale, including the actual room(s) where the monitoring staff will work. As an example, the NOC of Master Hoster ClearPointe (shown in Figure 21.7) is designed to support over 4000 managed servers on a 24×7 engineer shift rotation. A “Mission Control” design with tiered platforms and big-screen projectors can create a purposeful atmosphere.

Figure 21.7. The NOC at ClearPointe, a large-scale ROM Master Hoster.

Remote Operations Manager integrates tightly with the Active Directory of the service provider, because the service provider needs to provision AD user accounts and distribution groups for customers and partners participating in ROM. Because there is no trust relationship between customer and partner domains and the ROM domain, the AD in the ROM domain becomes the directory service and security provider for user-level activities involving customer and partner staff.

In particular, one will specify user accounts from the ROM service provider’s AD when creating user roles for customer and partner staff, and those credentials are used to access the OpsMgr Web console. The ROM service provider will customize group scopes, console tasks, and views to apply to user roles, thus limiting customer access to only their managed objects. Likewise, partner staff has access only to the managed objects of its customers.

You will also want to leverage user accounts in the ROM AD for creating email distribution groups targeted at each customer and partner. You can mail-enable the AD user accounts of customers and partner staff, specifying their external SMTP email addresses. As an example, if a customer has three points of contact, and each customer contact has a mail-enabled user account defined in the ROM AD, you can create a distribution list with those three user accounts as members. Emailing to the distribution list automatically emails each of the customer contacts. This saves time when contacting customers and facilitates customer communication.

The ROM service provider should prepare its AD for creating these user account and distribution list objects. We recommend an Organizational Unit (OU) structure that segregates these external objects from the rest of the ROM AD. For example, a top-level OU named ROM contains a child OU named Partner, which contains OUs for each ROM partner. You would create user accounts and distribution groups for partner staff here. Within each ROM partner OU, there are child OUs for each customer associated with that partner, where you would create user accounts and distribution groups for customer staff. Back at the higher level Partner OU, there are distribution groups such as All Customers and All Partners that include appropriate customer and partner distribution lists as members. You should also consider using Access Control Lists (ACLs) to restrict who can send email to these distribution lists, to guard against embarrassing unintended broadcast emails. Figure 21.8 shows the service provider’s AD hosting two partners, each with one customer.

Figure 21.8. OUs in the ROM service provider’s AD host partner and customer objects.

You can also use the ROM service provider’s DNS for name resolution of customer Essentials servers. In order to use Remote Web Workplace from the ROM network, the service provider workstation initiating the RWW session needs to resolve the FQDN of the customer server to the Internet IP address of the customer firewall that is publishing RWW.

Although name resolution of the FQDN can occur using a local hosts file on each ROM workstation, we recommend using the private DNS of the ROM AD. Each customer will have a standard primary DNS zone established in the private DNS of the ROM AD, with an address (A) record created in the zone with the host name of the customer Essentials server. To utilize RWW effectively, the customer firewall publishing RWW must have a static IP address on the Internet (preferred); alternatively, the customer can participate with the ROM service provider in a reliable Dynamic DNS (DDNS) service.

The Certificate Authority service is a critical and required component in a ROM solution. The ROM service provider can utilize an existing CA on its network (an enterprise or standalone CA) or establish a CA just for the ROM solution. A 26-page document, “Obtaining Certificates for Service Providers Scenario,” is included with the ROM distribution media. This document includes detailed procedures, with a screenshot at each step, for deploying a standalone CA for ROM. If the ROM service provider does not yet have a CA, following the procedures in the document is the simplest method of deployment.

We recommend you publish your CA with a publicly resolvable DNS name, to avoid having to create host file entries with private DNS names on customer servers for the one-time purpose of certificate issue.

The ROM service provider requires a robust firewall solution on the Internet edge. Optionally (and recommended), ROM gateway servers are also isolated to their own DMZ. The ideal architecture includes a separate highly available firewall solution to segregate the gateway servers from the management servers and the ROM core components. If you are not using a separate firewall, consider employing VLANs or IPSec to isolate traffic from the Internet-facing gateway servers. The gateway servers only need to communicate with their assigned management servers on TCP port 5723. TCP port 3389 (Remote Desktop Protocol) is also useful for remote management of the gateway servers from the NOC core network.

If there is only one gateway server, a best practice is to install the gateway component on a server in hardened workgroup mode (that is, on a computer that is not a domain member and that passes the Microsoft Baseline Security Analyzer test). If there are to be two or more gateway servers in a DMZ (required for gateway redundancy), consider installing DCs in the DMZ for a dedicated domain. Utilizing a dedicated DMZ domain lets you use domain-based Group Policy to enforce uniform security policies on gateway servers. Gateway servers remain fully and seamlessly monitored by the ROM management group in a DMZ.

Firewall Publishing Rules

Figure 21.9 shows the firewall publishing rules created for publishing ROM to the Internet using ISA Server 2006. (This screenshot is from the ISA Server Management console.)

Figure 21.9. Firewall array policies used to publish Remote Operations Manager with Microsoft ISA Server 2006.

The firewall policies in Figure 21.9 are explained as follows:

• The first two firewall rules shown in Figure 21.9 (rules 7 and 8) support the Internet publishing requirement to map TCP port 5723 from Internet-facing TCP/IP addresses to the private TCP/IP addresses of the gateway servers in the DMZ.

  Two gateway servers are published in this example, so there is one server publishing rule for each gateway server. Each gateway server has an associated Internet-facing TCP/IP address, which is the address the customer Essentials server or gateway server will resolve from the FQDN of the gateway server.

• Rule 9 in Figure 21.9 shows publishing the Web console on port 443 from the Internet to the Web Console server.

• An additional web publishing rule (number 10) directs port 443 requests to the web certificate issue page on the CA used by the ROM service provider. The rule that publishes the CA to the Internet should be disabled during normal operations and only enabled when a new customer Essentials or gateway server is actually performing a certificate request.

Installing the centerpiece of the ROM solution, the Service Provider management pack, is probably the easiest part of an OpsMgr-to-ROM transformation. The Remote Operations Manager software distribution media contains the Microsoft System Center Service Provider Management Pack 2007.msi file. This package installs the management pack on a computer, but does not import the management pack into the management group. After running the installer, if you accept the default installation location, the management pack is placed in the C:Management PacksMicrosoft System Center Service Provider Management Pack 2007 folder. Import the Microsoft.SystemCenter.ServiceProvider.2007.mp management pack file in the conventional manner, using the Operations console or PowerShell.

Here are the changes made to the management group when the Service Provider management pack is imported:

Hotfixes (sometimes called QFEs) might need to be applied to the OpsMgr management servers and/or gateway servers of the ROM service provider before Service Provider Mode is enabled on any customer Essentials server. The QFE folder on the ROM software distribution media will contain any such hotfixes. Install those QFEs following the instructions included with each hotfix.

No additional configuration is needed after importing the Service Provider management pack and applying any QFEs; the ROM functionality is ready to use. The next task for the ROM service provider, bringing a customer into management, occurs after installing Essentials on the customer network.

It is important to understand that an Essentials server is an all-in-one OpsMgr management server group, capable of importing management packs and monitoring computers and devices just like a native OpsMgr management group. Without ROM, Essentials is the primary and only monitoring engine involved on the customer network. In the ROM scenario, the primary monitoring engine is the remote instance of OpsMgr the ROM service provider runs, so some features of the local Essentials instance become redundant. That does not mean Essentials is no longer useful, but for performance reasons you want to prevent the Essentials and the ROM instances of OpsMgr from running the same application management packs against the same computers. Here are the possible modes of operation for a managed services partner considering Essentials:

The reference procedures to install Essentials are available online at http://go.microsoft.com/fwlink/?LinkId=94444, which is an online document discussing System Center Essentials deployment planning and installation. All else being equal, an Essentials server–based connection is more useful to the service provider than an OpsMgr gateway server–based connection to an SMB customer network. (When customers have Essentials servers, you can use all the features of the Service Provider management pack.) However, the hardware requirements and software footprint for Essentials are larger than for a gateway server. In particular, a 64-bit Essentials server requires a full instance of 64-bit SQL Server 2005 for a local database, whereas the 64-bit OpsMgr Gateway Server Component has no database overhead.

If the customer has an existing Essentials 2007 server, the ROM service provider can evaluate the capacity of that server to handle the load of the added Gateway Server Component. Remember that the Remote Web Workplace goes on the customer Essentials server as well. If Essentials does not exist in the customer environment, the service provider either selects an existing server to install Essentials on or installs a new server hosting Essentials. We do not recommend deploying Essentials in production environments on a virtual machine. Because Essentials (and its SQL Server database) can be memory-intensive, we recommend allocating 2GB RAM for 32-bit Essentials server and 3GB RAM for 64-bit Essentials server processes.

Essentials as ROM Grooming Tool

Regardless of how you plan to utilize the local Essentials instance after converting the Essentials server to Service Provider Mode, the Master Hoster service provider can consider using Essentials as a grooming tool/staging area for ROM. Here is a possible protocol to employ for customer network discovery:

• Prior to admitting new managed customer computers to the larger population of existing computers in the ROM NOC, let Essentials first discover customer networks.

• ROM and MSP partner staffs employ the local Essentials instance to groom customer computers and achieve a healthy state in the Essentials console, prior to discovering those computers from the ROM instance.

• After the healthy computers are under the management of ROM, uninstall their Essentials agents (removing dual-homing) and/or uninstall redundant management packs from the Essentials management group.

The service provider will want to leverage some features of the Essentials Feature Configuration Wizard, which is the post-setup configuration tool launched from the Essentials Administration space. For example, you will need the same Windows firewall exceptions that enable remote administration from the Essentials server for employing the Gateway Server Component in the ROM scenario. The wizard will add the firewall exception to the System Center Essentials All Computers Policy Group Policy Object (GPO). In other words, what would normally be a manual procedure if you were only employing a gateway server (creating the GPO) becomes automated with the Feature Configuration Wizard on an Essentials server.

Figure 21.10 shows the Introduction page of the Feature Configuration Wizard. We indicated which portions are always useful in the ROM scenario and which are optional, depending on the proposed use of the Essentials instance after placing the server in Service Provider Mode.

Figure 21.10. The ROM service provider can leverage many Essentials features.

<Essentials Path>SetupSetupSCE.EXE /Path: <Essentials Path> /SQLExpressPath
<Path> /User: <UserName> /Password: <Password> /Domain: <Domain> /UpdateLocation:
<location to store local WSUS files> /ImportSystemMPsOnly /Silent
Msiexec /i <Essentials Path>helperobjectsSCECertPolicyConfig.msi /qn

You need to enable name resolution of the ROM gateway server FQDN(s) from the Essentials server. The simplest way to accomplish this is by adding the FQDN(s) of the ROM gateway server(s) to the local hosts file of the Essentials server—the Essentials server is the only customer server that requires name resolution of the ROM gateway server(s).

Additionally, if the customer firewall is locked down to allow only certain ports or protocols to the Internet, you must permit outbound communication on port 5723 from the Essentials server to the ROM gateway server(s). If the customer firewall permits all outbound ports to the Internet, which is common, no outbound rule firewall changes are necessary.

The customer Essentials server needs to be issued a digital certificate by the mutually trusted CA in the same manner as the ROM management servers and gateway servers. Follow steps 1 through 14 from the “Importing the Certificate on ROM Servers” section earlier in this chapter and then add these two steps:

So really, creating the exported CER file is the only difference between obtaining certificates for customer Essentials servers and ROM management and gateway servers.

After issuing the certificates and staging the certificate files, launch the Configure Service Provider Mode tool from the Windows Start menu -> All Programs -> System Center Essentials 2007 program group. There are just five information fields to populate, as you can see in Figure 21.11.

Figure 21.11. Enabling Essentials Service Provider Mode on the customer server.

Notice in Figure 21.11 that the FQDN entered in the Operations Manager management server name field is ambassador.continent.com, which is the FQDN of the primary gateway server for this customer in the DMZ of the ROM service provider. The DMZ domain for this ROM service provider is continent.com, whereas the core domain for the ROM service provider is odyssey.com. The customer Essentials server needs DNS name resolution only for the gateway server(s) in the ROM service provider’s DMZ domain.

After entering the correct information in the five fields and clicking the OK button, the message “Successfully enabled service provider mode” appears. Communication with the ROM management group begins immediately, assuming you previously created the customer site in the ROM service provider’s OpsMgr management group.

In most cases, because using RWW offers a more secure remote access solution than RDP alone, we recommend that the ROM service provider install Remote Web Workplace on the customer Essentials server. The RWW feature in the ROM solution is derived from the same-named RWW that is a component of Microsoft Small Business Server 2003 (SBS). If the customer network already is running an instance of RWW on its SBS server, that instance suffices for the ROM solution and you do not need to install the RWW that is distributed with Remote Operations Manager.

Key characteristics of the RWW solution include

Because the Essentials server already requires IIS, and because web server certificates are easily available from the same ROM CA furnishing the computer certificates for the gateway components, deploying RWW on the Essentials server is usually a simple matter. Here are the steps to follow to install RWW in the ROM solution on the customer server:

To use RWW, you must possess a username and password that is a member of the Administrators local security group on the Essentials server. Service providers must stage administrative user credentials on the customer server or in the customer domain for using RWW.

There is a two-step procedure required to enable management of customer networks by the ROM service provider. We will step through each of these procedures:

Microsoft.EnterpriseManagement.GatewayApprovalTool.exe /ManagementServerName=
ambassador.continent.com /GatewayName=mission.pegasus.com /SiteName="Customer
Pegasus Corp."

Customer Site Approval

After a customer Essentials server is successfully converted into Service Provider Mode, the customer Essentials server will appear healthy in the System Center Essentials Servers view in the Operations console Monitoring space. Simultaneously, key Event ID 1210 appears in the Operations Manager event log of the customer Essentials server, as shown in Figure 21.13. The gateway-to-gateway connection to the service provider is operational when that event appears with the name of the ROM service provider management group (GROUP1 in this example).

Figure 21.13. Event ID 1210 in the customer Essentials Operations Manager log signals success.

You will want to wait about 10 minutes after observing Event ID 1210 on the customer Essentials server and confirming the healthy status of the customer Essentials server in the System Center Essentials Servers view in the Monitoring space. This is necessary for the Service Provider management pack discovery rule to discover the customer Essentials server, and this discovery occurs every 5 minutes.

When the customer site is ready for approval, it appears healthy (green) as the Customer Pegasus Corp. customer site does, seen in Figure 21.14. Notice the Health Service Task area on the right (the cursor is highlighting the Create/Edit Customer Site). Select the new customer site you want to approve and then click that shortcut to launch the Create/Edit Customer Site Health Service Task.

Figure 21.14. Essentials servers represent gateways to customer sites.

Running the Create/Edit Customer Site task against a healthy customer Essentials server (gateway) accomplishes two things:

• The gateway is validated to be an Essentials server. This one-time invisible action makes a change to the Operations database that indicates this is an Essentials server. After this task is run one time, the other Service Provider views, such as the Customer Health state view, will populate with data from that customer site.

• A remote task is run on the Essentials server, optionally populating Registry keys on the Essentials server with information useful for performing customer service. Customer information entered here includes the customer time zone, point of contact, and three customizable fields to track other management information.

Figure 21.15 shows the Create/Edit Customer Site task dialog box after we have populated the overrides in the task parameters. In the ROM Master Hoster scenario, you can use one of the custom fields to track the managed services partner associated with the customer. In this example, see a partner named Acme in CustomerCustomField3.

Figure 21.15. The Create/Edit Customer Site task enables features of the Service Provider management pack.

Within five minutes of running the Create/Edit Customer Site task (Figure 21.15), a rule from the Service Provider management pack reads the information from the customer server’s Registry and writes it to the Operational database. The override data entered in the Create/Edit Customer Site task then becomes visible in the details pane of the Customer Health view. Figure 21.16 shows the Customer Health view of the Pegasus Corp. site after successful customer site approval.

Figure 21.16. Customer service details are exposed in the Customer Health view.

Until this point, only the customer’s Essentials server is involved in the ROM scenario. This Essentials server is fully monitored and manageable by the ROM management group due to its gateway server role. If the Essentials server is the only computer that the ROM service provider will manage, no additional discovery is necessary. However, usually and hopefully, there are other customer computers and/or network devices, such as routers and switches, that will be also be managed by the ROM service provider.

To begin managing other computers or devices, the ROM service provider must run one or more discovery tasks against the customer network, using the standard Discovery Wizard in the Administration space. When running an advanced discovery task, select the management server in the drop-down list that is the customer Essentials server. Figure 21.17 shows the mission.pegasus.com management server selected to perform the discovery.

Figure 21.17. Using the Discovery Wizard to discover computers on the customer network.

The remote computer and network device discovery function in the ROM solution works exactly like the same-named function in the OpsMgr gateway server solution. Using the Discovery Wizard, scan for and select customer objects to manage in the same manner as if Essentials servers were just OpsMgr gateway servers. Microsoft designed both Essentials servers in Service Provider Mode and OpsMgr gateway servers to operate in a remote, untrusted domain, without direct network connectivity to the ROM management group.

After the ROM management group discovers the customer objects, data begins to appear in the Customer Alerts, Computers, and Customers (diagram) views in the Service Provider view folder. If the Essentials management group was already managing a customer computer, the Agent Component will be dual-homed. Monitoring of customer SNMP network devices is proxied by the Essentials server or another designated customer watcher node. Figure 21.18 demonstrates using the Find Now filter in the Customer Alerts view folder to look for Exchange server alerts from customer computers.

Figure 21.18. Filter on customer name or application of interest in the Customer Alerts view.

There likely will be some post-configuration tasks you will want to perform in the ROM management group after discovering customer computers and devices. These will be customizations to the management group that provide value to the customer. The next sections cover setting up each of these features:

User Roles for Customers and Partners

A big value-add to the ROM solution is the Web console, which in the System Center family is only available with the Operations Manager product. The Essentials product lacks a Web console equivalent, much less one that can aggregate the views of many Essentials servers. The role-based security in OpsMgr 2007 is a perfect framework to create profiles that easily and securely offer up a customer or partner view of its share of the ROM solution. Figure 21.19 shows the ROM Web console as viewed by a partner with two customer networks in management (in our case Draco and Pegasus).

Figure 21.19. The ROM Web console presents an aggregate view of a partner’s customers.

Figure 21.20 shows a user role being created for the Customer Pegasus Corp. Essentials customer site. The Read-Only Operator Role or the Operator Role might be appropriate for both customers and partners. On the Group Scope tab of the User Role Properties, select the customer group that is a subgroup of the All Customers group. Click the View group members link (circled in upper right) to confirm the identity of the objects the user role will have access to.

Figure 21.20. Creating a user role for a customer or partner to use with the Web console.

Real World—No Customer Names in Management Packs

The ROM service provider must take care in naming management packs created in the ROM instance of OpsMgr. When managed customer computers join the ROM management group, the names of all management packs in the management group may appear in the Operations Manager event log of the customer computer. To avoid one customer seeing the name of another customer in the name of a management pack, use a customer-neutral naming scheme for ROM management packs.

Notifications for SMEs and Customer and Partner Contacts

To expedite staff workflow, the ROM service provider may want to enable custom notification actions to designated Subject Matter Experts (SMEs) on particular advanced aspects of managed customer environments. As an example, if you know a predicted condition will be beyond the capability of engineers staffing the NOC to resolve, you can speed issue resolution by prenotifying SMEs before the NOC staff contacts them.

Each customer’s Essentials server has its own notification actions that can originate from alerts occurring in the Essentials management group. The ROM scenario does not utilize the local notification features of Essentials, and any notifications arising from managing a customer (such as an email, instant message, Short Message Service (SMS) text message, or a command-line process) are launched from the ROM service provider instance of OpsMgr. An exception is if the customer or managed services partner actively uses Essentials for workstation management. In that case, alerts from the Client OS and Information Worker management packs, which may not be under management by ROM, can be enabled to send notifications directly from the Essentials server.

Customers or partners may want the opportunity to leverage the notification features of OpsMgr. In the ROM Master Hoster scenario, generally neither the customer nor the partner will desire an automatic notification feature, because freedom from such alerts is a reason for engaging the Master Hoster! However, there may be situations where a notification action is appropriate for one or more customer site groups. OpsMgr Notification Subscriptions make this is easy to implement.

Figure 21.21 shows two steps in the Notification Subscription Properties Wizard. Configure the wizard’s User Role Filter to limit the groups and classes available for approval to those already granted to the user role for the customer. Doing so makes only the customer site group available for selection on the Groups page of the wizard. This linkage efficiently associates the Notification Subscription to the scope of the user role already created for access to the Web console.

Figure 21.21. The User Role Filter property of a Notification Subscription.

$primaryMS = Get-ManagementServer | where {$_.Name -eq 'ambassador.continent.com' }
$failoverMS = Get-ManagementServer | where {$_.Name -eq 'armada.continent.com' }
$agent = Get-Agent | where {$_.Name -eq 'mission.pegasus.com' }
Set-ManagementServer -AgentManagedComputer: $agent -ManagementServer: $primaryMS
-FailoverServer: $failoverMS