In part one we covered how to install Out of Band Management and Intel SCS into a multiple Notification Server infrastructure. This section covers the recommended order of operation when using the environment, including covering the caveats the environment imposes. The goal is to enable large Altiris customers to deploy Intel vPro systems into their environment when they have multiple Notification Servers.

Introduction

As with Part 1, this Part is offered 'As is', and provides no guarantees. Limited testing has been done on this, but the procedures have not gone through the Symantec QA process. Most of the details provided here are gleaned from experience working with the associated solutions in conjunction with limited testing done against a multiple Intel SCS and Out of Band Management environment. Any feedback provided against this article is appreciated as it is possible there are factors not figured in to the processes documented here.

Infrastructure

The following sections cover how the architecture is setup after the installations are complete, and the ramifications to the existing environment. The following segments cover:

• Microsoft SQL Server -- SQL is the key to the integration
• Resource Synchronization -- A must know for this environment
• Provisioning and Maintenance Queues -- SCS to client communication caveats

Microsoft SQL Server

The key to the integration of the different Out of Band Management and Intel SCS installs stems from the use of a single IntelAMT SQL Database. Essentially the Intel SCS installs can see the entire environment as within each Altiris Console when accessing the OOB pages they all connect to the same database. This means:

• Changes made in one Altiris Console are universal and will show in any other Altiris Console when accessing the Provisioning nodes
• All Intel AMT systems will show in all Consoles, regardless of origin
• Log entries will include logs from all Intel SCS instances
• Connections to the database will be made from all registered Provision Servers

One of the largest risks in a bigger environment is delays caused by lack of SQL Resources. Since all OOB functions (including all SCS functions) originate from the database, it is important to have enough memory, threads, and processes available through SQL to handle the load.

Resource Synchronization

Resource Synchronization is the process of synching the Intel SCS data with the Altiris database. Because of the nature of this synch, it is important to understand how each OOB install interacts with the IntelAMT database. As previously covered, every Altiris install will have access to the same list of provisioned or inprovisioning systems. Because of this, a Resource Synch will migrate ALL systems into the local Altiris database. For those systems that have the Altiris Agent installed and pointed to the target NS, the Intel SCS data will be merged with the existing record. For those systems that do not have Altiris Agent data locally, an 'unmanaged' record will be created for the system. There are several potential approaches to this:

1. Disable Resource Synchronization -- While Resource Synchronization cannot be disabled without stopping provisioning, a schedule can be set to far in the future so that it never runs. The drawback for this is the loss of OOB collection population.
2. Synch only Primary NS -- This option requires Resource Synch to be disabled on all but the primary NS. If the primary NS is a top-tier Notification Server, usually it will have records for all managed systems in the environment.
3. Leave Synch Enabled -- This will place many 'unmanaged' record into the vPro collections. This may have an impact on these particular collections, and these systems will also show up in Asset-type functionality for computer records.

Other approaches may be taken, but the above details show the drawbacks for using or not using Resource Synchronization.

Queues

The queues for both provisioning and maintenance requests are universal for all Intel SCS installs. Anything processed from the queues may get pulled by any Intel SCS server, regardless of where the item originated from. If the processing SCS cannot reach the client, the item will fail. This is the biggest drawback for this environment. This affects the following functions:

• Provisioning tasks -- Though the SCS that logs a request ideally will pick it up, this might not be the case. The larger numbers of SCS servers, the greater chance it won't be the processing server. Please see the section 'Single-Point Provisioning' for details.
• Standard Maintenance executions (configured under View > Solutions > Out of Band Management > Configuration > Provisioning > Configuration Service Settings > Maintenance) -- When these come due, the maintenance items will be queued to be executed by Intel SCS
• Unprovision or reprovisioning Tasks -- Unprovision or reprovision requests from within Intel AMT Systems will queue the items
• Delayed Provisioning requests -- If provisioning cannot occur immediately due to one of the following reasons, the provisioning request will be queued:
  • Issuing AMT system not responding
  • FQDN map unable to complete
  • Unavailable resources on the local Intel SCS
  • Unavailable resources on the SQL Server

At this point the only suggestion is to allow each Intel SCS have access to all subnets (not realistic) but this would allow all requests to be completed regardless of which Intel SCS picked up the item. Otherwise it will be a hit and miss process. Forward looking we will be handling the environment better to allow queued items to be properly routed to the local Intel SCS server.

Provisioning

The process of provisioning does not 'hook' into Notification Server. Since the database is central, any system requesting provisioning with the correct authentication will get provisioned. Here's the basic process: *The process is self-contained when the system to be provisioned is local to the primary install since the IntelAMT database is also local.

1. The vPro system sends the hello packet to 'Provision Server', or to the specified IP address supplied by the RCT tool
2. Authentication occurs to ensure the system transmitting the hello packet is authorized on this Provision Server (Note: Since all Provision Servers in the environment are using the same Database, the authentication is shared between them)
3. The local SCS logs the provision request into the IntelAMT database, adding the UUID and IP address
   Note: It's possible another SCS picks up the request. This will cause this specific request to fail. Please see RCT Tool section for how to deal with this scenario.
4. Out of Band Management maps the FQDN using several methods depending on how the environment is configured
5. The profile is read from the IntelAMT database by the local SCS
6. The local SCS assigns the profile to the local system and Provisioning is complete

How the hello-packets reach the server is covered in the following sections:

• ProvisionServer -- the default destination
• RCT Utility -- The 'simulated' way to direct the hello packets

ProvisionServer

There are two potential methods for getting the hello packets from the vPro systems to the right Provision Server. The first is the default sending destination of 'ProvisionServer'. Definition: Provision Server = the server with Notification Server, Out of Band, and Intel SCS installed Often it's the network and domain environment that provides us with distinct identification for the CNAME 'ProvisionServer'. By default all hello-packets are sent to 'ProvisionServer'. If each server lies within a sub-domain to the root, it will each have a unique name. For example, let's take the following hypothetical environment:

• Primary Notification Server = primns.altiris.com
• 1st Secondary NS = usans.americas.altiris.com
• 2nd Secondary NS = eurons.emea.altiris.com

On each local DNS Server for the environments, a CNAME can be created to route traffic sent to 'ProvisionServer' to their proper Notification Servers. In this way the environment can be setup to properly route the hello messages. Thus those systems joined to americas.altiris.com will get the ProvisionServer back of usans.americas.altiris.com.

RCT Tool

Intel provides a utility that can initiate the Hello packet sequence on vPro systems, including the ability to pass details for what Provision Server to send the packet to. In an environment that has multiple Notification Servers in the same Domain, this can help direct clients to the right SCS server. Software Delivery can be used to distribute and execute the utility so that the hello packets are correctly configured for the local environments. Please see the following article on how to setup this situation: http://www.symantec.com/connect/article/3612/using-intels-rct-tool-restart-amt-hello-packets-enterprise-provisioning

Single-Point Provisioning

The biggest obstacle when implementing this solution is to ensure that the Provisioning Server (NS+OOB+SCS) that logs the provisioning request is the same one that processes it. The current architecture does not flag queue requests with SCS identifiers, which makes the queue selection process blind. The way to deal with this are as follows.

Repetition Until Right

If the number of SCS servers isn't too great, we can schedule the reoccurring Software Delivery Task to send the Hello Packets. The repetition will ensure that one of the queued requests get answered by the local SCS. To do this, please see the following article: http://www.symantec.com/connect/article/3612/using-intels-rct-tool-restart-amt-hello-packets-enterprise-provisioning Use the Software Delivery Task to create a persistent method of getting the right Provision Server. Note that the biggest caveat is that the larger number of SCSs in the environment, the greater chance each attempt to have the right server pull the queued item will fail. For example a one in three chance will have a much greater chance of finding the right server compared to a one in ten chance.

All Inventory Forward

The two tables required for a local SCS to properly provision a system with the right FQDN are:

• Inv_OOB_Capability
• Inv_AeX_AC_Location
• Inv_AeX_AC_Identification (this is needed to create a computer resource)

If you forward these three data classes to all servers, each local SCS will have a good chance of correctly mapping the FQDN, so any SCS can handle the request. The only other requirement is to have the right ports open between subnets or sub-domains so that each SCS can communicate to a provision request from different subnets. Ports include:

• 9971 -- NS Listening Port
• 16994 -- AMT Hello message sending port
• 16992 -- Standard TCP communication for AMT
• 16993 -- Encrypted TCP communication for AMT

Conclusion

Hopefully all necessary items are covered in this article. This will enable larger environments to properly setup and provision Intel AMT systems so that the valuable functionality is available at each local Notification Server. In the future we are looking to improve the process and allow management in a multiple-NS environment integrated into the default product.

Using Out of Band Management with Intel SCS in a Multiple Notification Server Environment – Part 1: Intel SCS Installations

Using Out of Band Management with Intel SCS in a Multiple Notification Server Environment, Part 3: Non-NS Intel SCS