NOTE: This resource and the associated series are a re-post of information provided at http://juice.altiris.com/node/4821 and related articles linked therein. Although the title and material make reference to Altiris, the core concepts apply to most Intel SCS based solutions.
The previous article in this series is Part 1: Deployment Scenarios for Intel Setup and Configuration Service (SCS)
Introduction: Five Architectural Models to Support Enterprise Provisioning
As noted at the introduction of this series, there is an expectation that the reader is already familiar with the provisioning process of Intel® vProTM within an Altiris environment. Materials on Altiris Juice, User guides, online or instructor led training, or other sources provide a necessary foundation in understanding the core provisioning process.
This article introduces five models or approaches to deploying, configuring, and using the Intel® vProTM technology with Altiris Out-of-Band Management. The five base scenarios provide a foundation for custom and advanced deployments that are currently in use, have been tested in the lab, or are being discussed as this article is being drafted.
This article is by no means an authoritative guide on appropriate deployment models, yet is provided as a starting point for discussions, lab testing, and advanced deployment scenarios. In the brief description provided with each model, I will note whether that model is currently being deployed in production environments, being discussed, and so forth.
Key Security and Configuration Considerations to Keep In Mind
Previous articles have hinted at and hopefully future materials will further reinforce some key items to keep in mind. This is a short list with further explanations and experiences needed to fully appreciate and understand:
Once provisioned, the Intel® vPro^TM ^management engine is a service awaiting an authenticated request. The provisioning of an Intel® vProTM client defines the future authentication and authorization of requests against the management firmware. Authentication is handled either via MD5 Digest or Kerberos (see http://juice.altiris.com/node/4492). In addition, the provision profile and Altiris Real-Time Console Infrastructure configuration define TLS and Mutual TLS certificates that could be applied to the client configuration. Therefore, both the authentication of the request and the encryption via issued certificates requires awareness and association to a defined domain, certificate authority, and so forth.
Communications to the provisioning service (e.g. AMTSCS virtual web directory) and requests to the Intel® vPro^TM ^clients are handled via SOAP over HTTP. In regards to service configuration settings, use of SSL on the AMTSCS virtual web directory is recommended.
Access to the core Intel® vPro^TM ^configuration database requires a SQL account login defined during the installation process. In addition, user access control to the configuration service settings is defined by Windows Domain or Local User accounts.
Other authentication and authorization related concepts for Intel® vProTM in an Altiris environment are provided via articles such as http://juice.altiris.com/node/1585. Again - the above is only a short list of security and configuration related considerations before introducing the deployment models. The key takeaway is ONLY properly authenticated, authorized, and secured connectivity sessions are allowed.
In the following sections, the Altiris environment is noted by "NS" or "OOBM" yet includes the following core and supporting modules:
Notification Server 6.0.6074 with SP3 applied
Real-Time Console Infrastructure 6.3.1066
Real-Time Systems Manager 6.3.1066
Out of Band Management 6.2.1035.
Out of Band Setup and Configuration Solution 6.2.1040
Altiris Task Management 6.0.1356
A previous article on "Optimal Client Environment for Intel vPro provisioning" (http://juice.altiris.com/node/4082) along with other materials on OOB Discovery still applies.
Model 1: Traditional Single Altiris Out-of-Band Management with Single Intel SCS Installation
This is the default or most common model in deploying Altiris Out-of-Band management for the provisioning and usage of Intel® vProTM technology. A single server hosts the Altiris Notification Server and Out-of-Band Management solutions. Either locally or in close association to the Altiris Notification Server is a Microsoft SQL Server hosting both the Altiris CMDB and IntelAMT databases. An environment has been created to provide an optimal situation for configuration (http://juice.altiris.com/node/4082) and using the technology (previous series provides some examples - http://juice.altiris.com/node/2201)
This core environment is the most commonly used deployment approach today. It provides the foundation to build upon as we briefly review other models and approaches to an Altiris environment.
Model 2: Multiple Altiris Out-of-Band Management Installations Running Intel SCS with Single IntelAMT Database
Having a single Altiris Notification Server that is client facing may be suitable for small or medium deployment situations. However, an increasing number of requests and situations have arisen when multiple Altiris Notification Servers are required. The reason for multiple client facing NSservers could be due to client load, separate divisions due to acquisitions or divestitures, development testing versus production environments, and so forth. A key reminder is that each client facing Altiris Notification Server with Out-of-Band Management installed likely has a separate instance of Intel SCS running.
An earlier post by Joel Smith highlighted how to setup a multiple Altiris NSserver environment with Intel® SCS - see http://juice.altiris.com/node/3771
A few key items to keep in mind:
All participating servers MUST be running the same version of Intel® SCS. This is due to APIs, database schema, and related items. The easiest method of determining what version is running is to check the AMTconfig service.
The oobprov.exe provisioning script used by Altiris and customized DLL (Interop.AeXClient.dll) must be in the same directory path on each participating Altiris NS Server
Resource synchronization should be enabled to assign the configuration parameters (e.g. Profile Assignment settings) by default, yet NOT replicate the IntelAMT entries to each Altiris NS Server.
If the ProvisionServer DNS record is used, it can direct provisioning events to the preferred Altiris NS server. One caveat seen at a few customer sites is that more than one client facing Altiris NS server was in the same DNS content (e.g. NS1.mycompany.com and NS2.mycompany.com). In that situation, take a look at the Intel® vProTM Activator Utility referenced in article http://juice.altiris.com/node/4713.
The following diagram provides a simplified view how the setup might be accomplished. Notice that a single IntelAMT database instance exists, yet the connections are in place for both Altiris NS servers to access the database for OOB Configuration purposes. On caveat to consider is server "NS1" might attempt to provision a client in the lower right. The queue of provisioning requests is presented to all associated Intel SCS instances - first come, first server (both for entry and processing of the requests in the IntelAMT database)
This model has been used in lab environments, along with a few production environments. It is recommended that lab testing and familiarization with the approach be completed before implementing in production. In addition, the next article will provide some additional insights on the Intel® SCS provisioning service.
Model 3: Provisioned via Altiris OOBM, Managed by Other Consoles
It is quite common that a single enterprise environment will have more than one client management solution. The Altiris Client Management Suite may be the primary tool, yet other consoles or customized in-house utilities may be in place to further enable a particular environment or management preference.
This model takes the approach that the Altiris NSserver with Out-of-Band Management maintains the Intel® vProTM configuration, thus acting as the ProvisionServer. From a previous article on core provisioning requirements (see http://juice.altiris.com/node/4480), the first three criteria have been completed. The goal is completing the 4th requirement - updating the management consoles to be aware of and able to access the provisioned Intel® vProTM clients. In addition, a post deployment provisioning situation may occur, which was referenced in the series http://juice.altiris.com/node/4636.
If you have ever used the Intel® WebUI or Intel® System Defense Utility (http://www.intel.com/design/motherbd/software/isdu/), then you have effectively used this very model. Either the Altiris environment was not correctly configured to access the provisioning Intel® vProTM client, or there was a particular usage model or approach that you preferred with one of the free utilities.
A key reminder: once an Intel® vProTM client is provisioned, any properly authenticated and authorized request can be made to utilize the technology. The first section of this article references a few of the security considerations.
If using TLS or Kerberos, the "non-Altiris" management consoles MUST be part of the same DNS domain, Microsoft Active Directory Forest, and have the root certificate in their local computer certificate store.
A minor variation on the image shown above is to use a "non-Altiris" management console such as LANDesk, SupportSoft, SMS with Intel® AMT add-on, HP OOBM, and so forth. The core requirements still apply, and the method to update the consoles with lists of provisioned Intel® vProTM systems is via their respective network discovery or related processes to find provisioned Intel® vProTM or Intel® AMT capable clients. The Altiris NS server maintains the configuration of the Intel® vProTM clients, yet other consoles are able to utilize the configured technology for remote out-of-band management purposes.
If unsure or doubtful that this can be accomplished - take a look atand try it out in your own environment. In my own lab, I setup a primary Altiris NSserver to configuration and manage Intel® vProTM clients. Next, I setup a second Altiris NSserver, added the root certificate to the local computer certificate store, directed the Altiris NS Agent on a few clients to the second server and enabled OOB Discovery. Within a short period of time, I was able to issue commands from either Real-Time console to the provisioned Intel® vProTM clients using Kerberos authentication and TLS encryption.
Model 4: Multiple Intel® SCS based solution
A slight variation to the previous models is to have a non-Altiris management console hosting the Intel® SCS provisioning service. The core requirements and recommendations still apply in regards to Intel® SCS versions, authentication credentials, and so forth.
This model has been proven within a lab environment (see http://communities.intel.com/openport/blogs/proexpert/2008/03/10/two-isvs-managing-the-same-client-sure ) and is also referenced in a production environment (see )
The prequisities and guidelines in model 2 above apply for the Altiris configuration. In addition, the provisioning script is likely pointed to the DB within the Intel SCS console. In effect, the Altiris server is simply looking to replicate data from IntelAMT in the Altiris CMDB. Meanwhile, the non-Altiris client management environment continues to utilize the same IntelAMT database.
The next article in this series will explore a little more detail on the underlying Intel® SCS provisioning service. That information will help to further understand the requirements, considerations, and communications necessary to make this model work.
Provisioned by Other Consoles, Interfaced by Altiris for Usage
The fifth and final model may be assumed by some, yet I chose to call it out. If the Intel® vProTM clients are already provisioned, than a discovery of the systems and appropriate credentials provided for authentication are all the Altiris environment needs to know. In essence, this is a variation of the third approach referenced above.
There are two common approaches to discovering provisioning Intel® vProTM clients into an Altiris environment. The key is to ensure Inv_OOB_Capability, Inv_AeX_AC_Location, and Inv_AeX_AC_Identification tables in the Altiris CMDB are updated:
Use of the Altiris NS Agent and OOB Discovery as reference in http://juice.altiris.com/node/4638
Use of the Altiris Network Discovery with AMT scan option enabled. The image below provides an example. Two key reminders:
If TLS or Kerberos are NOT used, than ONLY the Small Business option is needed. Otherwise, use the Enterprise mode options to properly authenticate and locate the systems.
Network Discovery with AMT Scan works ONLY if the Intel® vProTM client is provisioned, thus enabling the network interface for management communication
The model below is a simplified version of previous models. The key difference to note is that OOB Configuration requests (i.e. items requiring a ProvisionServer) are not present. The main concern customers and partners have highlighted is maintaining the configuration should the FQDN change or minor updates needed within the configuration settings of the Intel® AMT client. Take another look at the article http://juice.altiris.com/node/4640. Specifically - methods and approaches to remotely update the FQDN (i.e. Intel® AMT Reflector) and to remotely unprovision the system.
An interesting idea raised by a customer and performed in the lab is deploy systems in SMB mode. Using the Intel vPro Reflector Utility, the administrator would be able to keep the FQDN in-sync between the Intel AMT firmware and the host operating system. Supported client management consoles would be able to discovery the "provisioned" client, gaining access to perform the desired use models. HOWEVER - configuration options such as Kerberos, TLS, MTLS, and other items requiring enterprise mode configuration would not be available. IF a customer wanted to take advantage of those - the target client provisioned in SMB mode could be remotely unprovisioned using Intel vPro Reflector Utility or unprovision.exe (see Tools and Utilities for Intel® vPro™ Technology). THEN - using remote configuration with an acquired certificate and supporting infrastructure, the administrator could initiate and direct (especially with Intel vPro Activator Utility) an enterprise mode provisioning event.
If you've tried this and see it working - PLEASE let us know.
If the long term intent is for the target Altiris environment to act as ProvisionServer and maintain the configuration, utilize the approaches and ideas referenced to remotely reset the configuration. The core reminder is to ensure a method of initializing the provisioning is in place:
Target Intel® vProTM clients and the Altiris environment support Remote Configuration
The PID\PPS (aka security keys, pre-shared keys, etc) can be distributed out to the client systems
Method or utility to initiate and direct the hello packets for provisioning (e.g. Intel® vProTM Activator Utility or similar)
Once the core provisioning process methods, utilities, and approaches are understood - the different deployment models and approaches can be pursued to fit a majority of environments. Determining what environment will provision and maintain the configuration of the Intel® vProTM firmware is still relevant yet provides some flexibility per environmental considerations. Once the Intel® vProTM client is provisioned, it is only a matter of properly authenticated and authorized requests. This provides new flexibility and consideration, especially in finding the right tools and consoles to take full advantage of all the out-of-band capabilities within the Intel® vProTM technology.
The next article in this series explores the Setup and Configuration Application - http://communities.intel.com/docs/DOC-1933