The Task Server contains AMT function tasks that give you the ability to integrate AMT functionality into Task Server Jobs. This allows you to use AMT in conjunction with Software Delivery, Scripting, and any other Task Server supported function. Understanding how to troubleshoot the AMT side of a Task Server job will help resolve issues so that AMT can be utilized. This includes the following technologies:

• System Defense - Network Filtering

• Reliable Power Management

• IDE redirect for boot redirection

Introduction

This is the concluding article for the series: Troubleshooting the Altiris Manageability Toolkit for vPro Technology. The first four articles covered the setup and configuration of AMT systems, while parts 5 and 6 covered RTCI and RTSM respectively. This final article discusses troubleshooting the AMT integration into Task Server when issues arise.

As an introduction, the actual SOAP or API calls made to the AMT system is invoked through Real-Time Console Infrastructure, the same as when they are invoked through the Real-Time tab for RTSM. Though the calls are from the same place, how those calls are made differ. The following subjects will be covered:

• Determining Cause of Failure

• AMT Detection Issues

• Authentication Issues

Determining Cause of Failure

Often you'll known the general symptom that tells you a job or task in Task Server didn't execute as expected. For example a power management task may have shown as run but the AMT system never woke up. A failure is not shown except deep within a series of status windows.

To determine the returned error, use the following steps. Task Server's actual failure code is buried deep in a series of status windows, as shown in the screenshot after the steps.

1. Under the Task or Job that failed, double-click on the general status row for the specific execution attempt.

2. If within a job, double-click on the line that represents the task or AMT function that failed.

3. Note the numbers of successes versus failures. Click the ‘View Report' link.

4. Now you'll get a grid with the status of the Task, including the status and return code, if present.

AMT Detection Issues

When Task Server reaches a Task that involves AMT, it makes direct calls to AMT in those systems targeted in the task or job. Detecting AMT and subsequently executing the scheduled function requires success at both junctures. The following sections discuss potential issues and solutions in this process.

Power State Unknown

One common problem we see is when a power management task fails due to the failure message: Generic error, FromState detected as unknown:14. This will cause the power action to fail. The causes vary, but the following list contains the most common:

• System unreachable - The target system is not available on the network

• AMT failed to be detected - See the subsequent section ‘AMT not detected'

• Authentication failed - See the subsequent section ‘Authentication Troubleshooting'

• AMT is unavailable - If a system is not provisioned, or AMT is not functioning on that system

Use the following process to determine what the issue is:

1. If RTSM is available, try connecting to the target system using RTSM, specifying the same credential profile.

2. If that fails, try manually putting in credentials until you find one that works.

3. If Step 1 succeeds, try creating a different connection profile with only AMT functions provided.

4. If no RTSM is available, still try the profile with only AMT functions to see if it works.

5. Try other AMT functions, such as Collect Intel AMT Inventory to see if they succeed.

6. If other functions succeed, try using another method to reboot the system to reset the power state stored in the Intel ME. One way to accomplish this is using the Task Server Power Management Agent to send down a standard reboot command to the PC.

7. If no other AMT functions are successful, AMT might not be properly setup on this system. Ask the question: Has this system gone through the provisioning process?

8. If unknown, use the Out of Band Discovery Task to see if AMT is available and to identify what state it is in. See the steps provided under the ‘AMT Not Detected' section following.

9. If all else fails (generally this is on a system-by-system basis, rarely do a collection of systems encounter this level of this issue) try reprovisioning the system by fully unprovisioning and going through the provisioning process again.

AMT Not Detected

Normally a non-vPro system will receive the return code that AMT was not detected. This is accurate, but when it happens to valid managed vPro systems, the issue must be troubleshot to determine why the applying Task Server cannot detect AMT on the system. Out of Band Discovery is a great way to determine what state the system is in. Use the following steps to take stock of the systems:

1. In the Altiris Console, browse to View > Solutions > Out of Band Management > Configuration > Out of Band Discovery > and select the ‘Out of Band Discovery' policy.

2. Enable the policy if it is not yet enabled. If it is enabled, set a schedule to run the discovery again so you have updated information on your systems.

3. On the AMT system in question, go to the Altiris Agent and bring up the Agent UI by double-clicking on the system tray icon or by launching C:\Program Files\Altiris\Altiris Agent\AeXAgentActivate.exe.

4. Highlight the ‘Out of Band Discovery Package.

5. Click the ‘Out of Band Discovery' link under Application Tasks.
   !OOBDiscoveryRun.jpg!

6. Once completed, now check back at the server and double-click the system within a collection to bring up Resource Manager.

7. Click on the Inventory tab and browse to Out of Band Management, and select the data class OOB Capability. This will give you the details of AMT.

If AMT is disabled, it needs to be enabled in the BIOS. A BIOS update from the vendor may provide you a remote way to enable AMT, by using Software Delivery for example. If it is all enabled, next check the provisioning status. Provision as necessary.

Authentication Issues

As with RTSM, Task Server uses the same basic authentication method when executing against a computer. Task Server also includes another option to add additional credentials to the execution to be used when contacting the protocol, which is AMT in this case.

Authentication Methods

Since RTCI controls the authentication, much of the same method is used whether the execution of an AMT command is issues from the Real-Time console or from Task Server, however there are some differences.

Runtime Profile - The Runtime profile contains he following information:

• All known good credentials used to connect via RTSM to a system

• The Intel SCS AMT password sent to systems when provisioning occurs

• Previously successfully used credentials from past RTSM sessions

• Previously successfully used credentials from a Task that succeeded

User-defined Profiles - Profiles can be created that specifically provide credentials for the four types of technologies:

• WMI digest or Domain account

• AMT digest or Kerberos-authenticated user

• ASF digest or Domain account

• SNMP community strings

Task-specified Credentials - When a user setups up a job or task, the user can specify specific credentials to be used when executing AMT-related functions through the profile interface. This option is per job or task, and applies to all AMT functions invoked during the job or task. The Interface allows this as shown in the following screenshot:

Authentication Troubleshooting

The following method will help identify issues and offer ways to work-around and solutions. These have been compiled through experience when troubleshooting issues with failed authentication with Task Server.

1. First, how do you determine if your task or job is failing due to authentication? Use the previous section under Introduction labeled ‘Determining Cause of Failure'.

2. In the Altiris Console browse to View > Solutions > Real-Time Console Infrastructure > Configuration > select Manage Credentials Profiles, or in the Task click the ‘Run Now', and on the subsequent page click on the pencil icon next to the credential profile being used.

3. Where does the green checkmark fall? This is the default profile that will be used when connecting via a Task Server task.

4. Create a new profile by clicking the blue + on the icon bar in the right-hand pane.

5. Under the Intel® AMT tab check the box ‘Enable this technology in the profile'.

6. Supply the admin user credentials set when the managed vPro systems were provisioned.

7. Under the WMI tab also check the box as above and provide a user that has admin privileges to the target system.

8. Give the profile a name and then save it.

9. Back at the main screen check the box under the ‘Default' column until the green check-mark uses your new Profile, or if you are in a job interface select the profile to be used for the run. Note that this does not require you to make it the default profile, allowing another profile to remain the default credentials.

10. Run the task or job to see if the authentication failure has been resolved.

11. If it is not, try rerunning with the Runtime Profile. This contains all known good authentication attempts to the system from either Task Server or RTSM.

12. In one case we supplied only AMT credentials in the Profile which allowed it to authenticate to AMT while a multiple protocol authentication profile failed. If your Task or Job does not contain any of the other protocols, this is recommended.

Conclusion

This concludes the Troubleshooting article series for the Altiris Manageability Toolkit for Intel vPro Technology, version 6. While this doesn't cover all issues, it should resolve most of the common issues we've seen.

The ability to provide access to the Real-Time tab of Resource Manager will enable administrators to provide this valuable tool to IT specialists or Helpdesk workers. Furthermore the ability to configure access to certain functions within the console will allow administrators to grant or restrict what users can do with Real-Time System Manager. This includes WMI functionality as well as powerful AMT functionality.

Introduction

Your environment will likely have a unique set of requirements on who can access what in Real-Time System Manager. It can be as simple as two levels of workers, from an administrator to an IT Specialist, to a complex system of access rights in a multi-tiered environment tightly controlled. No matter the environment, this article provides the details to customize access to the Real-Time tab, including WMI and AMT access rights.

RTSM contains limited functionality to configure access via WMI. AMT, on the other hand, can be configured at a function-granular level. Whether you're simply trying to give users full access to RTSM, or to provide access to only certain functions, this document assists to achieve this.

NS Role Security

The first item that must be enabled is creating a role or modifying an existing role to have rights to Real-Time System Manager at the general level. Without assignment to such a role, a user cannot gain access to RTSM.

Overview

Briefly I'll explain how NS Role and Scope security work together in Notification Server. Roles give feature access rights. For example in Software Delivery Solution there's a role object labeled ‘Item Tasks - Software Delivery Wizard'. The two options allow use of the Simple or Advanced Software Delivery Wizard. Without this right, the user cannot launch the Software Delivery Wizard, regardless if they have scope rights to the Wizard and Status node in the console.

Scope security is much like the Windows File-System security model. In the Altiris Console the left-hand tree can be accessed like the file system, applying security to folders or to nodes, as opposed to folders and files. Inherence allows security to be inherited from the containing folder, on up the chain until the root node is reached.

Role Configuration

The following steps show how to create a user with RTSM permissions.

1. In the Altiris Console, browse to View > Configuration > Server Settings > Notification Server Settings > Security Roles.

2. Select an existing Role or Right-click on the Security Roles folder and choose to create a new Role.

3. Under Privileges, find the following categories and check the indicated option. After the screenshot the items are details with description of the option:
   

1. Altiris System Privileges - Use Real-Time System Management - This is the ability to use the product at the most basic and general level.

2. Altiris Console Privileges - View Resources Tab - For this example I'm providing the user the ability to see collections so he or she can launch Resource Manager and use the Real-Time tab.

3. Altiris Console Privileges - View Tasks Tab - Access to the ‘Manage' node allowing launch of Resource Manager requires this privilege.

4. Item Tasks - Real-Time System Manager - Manage - This is access to the main tree for RTSM. Most functions are covered by this option.

5. Item Tasks - Real-Time System Manager - Password Reset - Because of the nature of this function, it has been separated out as a single security role object in Notification Server but belongs to the Real-Time tree.

6. Item Tasks - Real-Time System Manager - Port Check - The Port Check feature is normally accessed as a separate contextual item in the right-click menu, or launch from an icon under the Real-Time tab.

7. Item Tasks - Real-Time System Manager - Trace Route - This is treated in the same way as Port Check.

8. Item Tasks - Real-Time System Manager - Hardware Management - This is one of the objects in the tree that provides basic hardware function, which is greatly extended if the system is Intel vPro capable and Provisioned.

4. Click the Membership tab.

5. Use the blue + icon to add users and/or groups to the Role. These can be digest users or local computer groups, or Domain users or groups.

6. Click Apply to save the Role.

Note: The users will not have access yet to the Altiris Console as the scope-level security has not been set for the new Role. Complete the below NS Scope Security section to give access to the Altiris Console

NS Scope Security

Altiris Console

For Altiris Console access, scope security must be configured before a Role can access or login to the console. The security window is the same for any node, be it a folder or otherwise. The two screenshots below show the security window and the permission selection screens:

Note: Depending on the object type, the available permissions may differ

To allow access to the ‘Manage' Real-Time Console Infrastructure Task, follow these steps:

1. In the Altiris Console, browse under View > Tasks > Incident Resolution > Tools.

2. Right-click on the node ‘Manage' and choose Properties.

3. Click on the Security tab.

4. Click the ‘Add' button.

5. Select from the list Role name of your role (ie: Role RTSM Workers) and click the ‘Select' button.

6. Check the option for ‘Full Control' and click ‘Select'.
   Note: Full Control does not give the user the ability to delete or otherwise manipulate the Manage node. This node can only be accessed for the function alone.

7. Click ‘Apply' to save the security changes made.

To access Collections so the users of the role can view collections so they can use the RTSM right-click contextual menu options for a listed resource, follow these steps:

1. In the Altiris Console, browse to View > Resources > Collections.

2. Depending on what collections you want to give the user access to, browse to a containing folder or an individual collection.

3. Right-click on the folder or collection and choose Properties.

4. Click on the Security tab.

5. Click the ‘Add' button.

6. Select from the list Role name of your role (ie: Role RTSM Workers) and click the ‘Select' button.

7. Check the following options:

1. Altiris System Permissions - Read

2. Altiris Resource Management Permissions - Read Resource Data

3. Altiris Resource Management Permissions - Read Resource Association

8. Click Select, and then click Apply on the permissions window.

Now we have allowed the user access to certain parts of the Altiris Console so they can execute Real-Time System Manager on managed systems. To restrict access to certain parts of the RTSM console, see the previous Role section for what options are available to you.

AMT Permissions

RTSM takes advantage of powerful functionality available in Intel vPro, AMT technology. Once a user has access to RTSM, their user account, if permitted, is used to connect to the remote system by WMI. An AMT connection can either use Kerberos integration or an inputted digest user when prompted. The credentials must be specified in the destination system's AMT Profile, otherwise authentication will fail.

To configure who has rights to AMT, follow these steps:

1. In the Altiris Console, browse to View > Solutions > Out of Band Management > Configuration > Provisioning > Configuration Service Settings > Provision Profiles.

2. Double-click on an existing profile, or create a new one.

3. Click on the ACL tab.

4. Click Add to add either a digest user or to use Domain users and groups with Kerberos integration.

5. Once a user is inputted, the ‘Realms' section allows or disallows access to different AMT functions. The boxes that are of importance to RTSM are:

1. Circuit Breaker - Now known as System Defense, or Network Filtering

2. Hardware Asset - For power management capabilities

3. Redirection - To allow IDE Redirection

4. Remote Control - Allows Serial Over LAN (SOL) remote connection

5. Event Manager - Allows viewing of AMT logs

6. General Info - Allows viewing of AMT data on the system

6. The ‘Access Permission' dropdown should be used to select either Network Access or Any. The Local Access option gives that user rights to log into the Intel ME locally when the system boots and isn't needed for RTSM function, however if you wish to allow the user to have access to both, choose ‘Any'.
   

7. Click OK to save the changes.

To apply the updated or new profile to an AMT system Provisioning must occurred. If the system was already provisioned with this same profile previously, a reprovision will update the profile.

This will not limit access to see the functions available in the Real-Time tab for AMT, but will throw a not authorized message if an applicable function is attempted with a user who does not have the rights to execute it.

Conclusion

The Real-Time tab, a one-to-one solution for system access, data gathering, or troubleshooting, provides a powerful tool to IT administrators and IT professionals alike. Providing this ability to users you do not want to have full access to Altiris is essential for any secure environment. With the additional ability to configure granular AMT rights for vPro capable and configured systems, an administrator has the ability to get very specific on what users or groups of what rights.

While at ManageFusion, we had Symantec Director of Strategic Alliances Kevin Unbedacht discuss how Intel vPro Technology enhances the Symantec Altiris Client Management Suite. The videos below include demonstrations around power management with secure power-on, remote diagnosis and repair of troubled PCs, isolation and repair of infected PCs, and discovery of PC assets.

• Hardware-assisted Power Management with Secure Power-On

]]>

• Hardware-assisted Diagnosis and Repair of PCs Remotely (by getting into PC's BIOS settings):

]]>

• Hardware-assisted Diagnosis and Repair of PCs Remotely (by remote booting PC to fix-it image on the network):

]]>

]]>

• Hardware-assisted Isolation and Recovery of Infected PCs:

]]>

• Hardware-assisted Discovery of PC Assets

]]>

Click here to learn more about the combination of Symantec products with Intel vPro technology: http://www.earlyroi.com/

At ManageFusion, we had the Intel vPro technology Challenge at the event - a competition where teams of two competed to find and fix a troubled PC. Each team had an opportunity to interact with Intel vPro technology based PCs from the Symantec Altiris Client Management Suite, and most had fun in the process! Check out the highlights from the Challenge.

]]>

Sometimes within Intel Marketing, we're told that our description of Intel Centrino with vPro technology or Intel Core 2 with vPro technology is a bit lengthy. Therefore, while at ManageFusion, we asked Intel customers as well as technical experts from Intel and Symantec to give us their best, most concise acronym that best describes Intel vPro Technology. Listen to their responses below.

]]>

Remote Configuration is the zero-touch configuration mechanism that allows Intel vPro AMT systems to be setup for AMT management without any manual intervention. This article covers the Best Practices for setting up Remote Configuration and using the Out of Band Delayed Provisioning Task to remotely and automatically provision systems for use within the Altiris infrastructure.

Introduction

In an ideal environment, vPro systems will automatically Provision without any interaction with the Administrator, allowing the versatile and robust functionality of AMT to be available immediately out of the gate. In this article we'll cover how to setup just such a scenario, but also how to use Out of Band Management's Delayed Provisioning Task to ‘kick-start' any AMT system that is no longer sending out configuration requests. Reasons for this need include:

1. The system is powered on in a location that does not have access to the Provisioning Server

2. The system is unable to be Provisioned due to changing identities while being setup in its Fully Qualified Domain Name (FQDN)

3. The IP Address changes during the Provisioning process and the Provision Server is unable to contact it back to Provision

Remote Configuration

Remote Configuration uses a certificate-based authentication model with preloaded certificate hashes to allow quick and automated process to Provision the AMT systems in the environment. The certificates require a vendor-certified cert from Verisign, GoDaddy, Komodo. While you can set your own cert and load your own hashes in the firmware of AMT systems, it turns the ease of Remote Configuration into a cost, whether by having the OEM load the proprietary cert for a fee, or requiring a configuration step to load the hashes manually into the firmware.

Certificates

The firmware will already contain the hashes for Verisign, GoDaddy, and Komodo certificates (more vendors will be added in later versions of AMT). Server-side certificates need to be loaded and registered on the Provision Server, and within Out of Band Management on the Altiris Notification Server. Please see the following article for more information on Remote Configuration:

http://juice.altiris.com/article/3866/frequently-asked-questions-about-remote-configuration

For a specific reference for what items are required, review the section labeled:

What core items MUST be defined in the provisioning certificate?

Also look at the section pointing to how to acquire a certificate (other links):

What resources or guidance are available for acquiring one of the core external certificates?

Additional information:

The Provision Server must be registered with DNS, accessible by the Intel AMT device via a CNAME value of ‘ProvisionServer' pointing to the IP address of the Notification. Note that in a multi-domain (including root-child domain infrastructures) multiple CNAME entries must be setup to include the suffixes to include all network segments the server will be managing.

The Provision Server requires a certificate with the appropriate OID or OU detailing directions to a certificate Authority (CA), which CA must have a root certificate hash stored on the Intel AMT Systems. The OID must be of the type ‘Server Authentication Certificate' with the Intel setup extension: 1.3.6.1.5.5.7.3.1, 2.16.840.1.113741.1.2.3, OR, the OU value in the Subject field must be "Intel(R) Client Setup Certificate".

The Subject CN must be either the fully qualified domain name (FQDN) of the platform running the service (example: Provisionserver.symantec.us), or the domain suffix of the platform (example: *.symantec.us.com or *.symantec.com).

Remote Configuration Process

The following process documents how the Remote Configuration Process works. This high-level overview will be referenced in the subsequent sections covering Delayed Provisioning. The following process assumes that the AMT System can reach the Provision Server and won't change identity through typical setup methods such as imaging or configuration scripts that changes the FQDN and/or Hostname of the system (including adding the system to a Domain).

The following steps must be completed before Remote Configuration will work in the environment. They are detailed with step-by-step processes in the Out of Band Management 6.2 Administrator's Guide, located here: http://www.altiris.com/upload/outofbandrefsep18.pdf

• Setting up Intel AMT using Remote Configuration - Page 44

• Certificate provider - Page 44

• Preparing a Certificate Template - Page 45

• Issuing a New Template - Page 46

• Preparing a Certificate Request - Page 47

• Acquiring a Certificate from an External Certificate Vendor - Page 48

• Installing the Remote Configuration Certificate - Page 48

• Loading the Certificate into Intel SCS - Page 49

• Enabling the Remote Configuration Feature - Page 49

Note that not all the sections need to be accomplished depending on what method you use. If you're creating your own certificate:

• Preparing a Certificate Template

• Issuing a New Template

• Preparing a Certificate Request

...should be used. Otherwise use the ‘Acquiring a Certificate from an External Certificate Vendor' section, including the previous links provided on the subject, should be consulted. Remember this is the recommended method since it requires no special processes to be in place to ready the AMT systems for Provisioning.

Delayed Provisioning

The purpose of Delayed Provisioning is to Provision those systems that failed the original Provision attempt. The includes failure at any part of the Remote Configuration/Provisioning process. Failure points include:

• Hello Packet does not reach the Provision Server during the 24-hour period hello packets are sent

• The IP Address changes after the Provision Server initially receives the hello packet and hasn't sent down a profile to complete the provisioning process

• The FQDN changes, forcing an IP Address change from DHCP so when the OS is up, the Provisioning Server can't reach the system

• The Provision Server is unable to complete the process due to a number of causes, including network access problems, firewalls, subnet locations, etc...

The following items must be in place for Delayed Provisioning to work:

1. AMT System must be in Setup Mode (pre-provisioned). This means the system must be in the state where it is using Remote Configuration and will use the provided hashes.

2. The system must have a functioning Windows Operating System.

3. The Altiris Agent must be installed and functioning within the OS.

4. The Out of Band Task Agent must be installed within the Altiris Agent.

5. The Delayed Provisioning Task must be enabled to target the AMT systems in question.

Delayed Provisioning Process

The following process details how Delayed Provisioning works from start to finish. In essence the process ‘kick starts' the hello packet process, allowing the Provision Server to receive fresh data on the system, allowing it to properly contact and provision it. The following diagram shows a high-level view of the Delayed Provisioning Process:

Full steps:

1. The AMT System must be in Remote Configuration setup mode. This is the default mode for AMT 2.2, 2.6, and 3.0.

2. Install the Altiris Agent on the system. Check the Notification Server reference guide for methods.

3. In the Altiris Console, go to View > Solution > Out of Band Management > Out of Band Discovery.

4. Enable the Out of Band Discovery Policy. This will help with the Provision process after the Delayed Provisioning Task executes.

5. Now go up a level and browse down into Out of Band Task Agent Rollout.

6. Add the collection: Non-Provisioned Intel® AMT Computers to the Policy by clicking on the Collections listed under ‘Applies to Collections' and browsing to it under ‘Out of Band Management', ‘Provisioning'.

7. Enable the Out of Band Task Agent Install Policy.
   !oobagentinst.JPG!

8. Browse in the Altiris Console under View > Solutions > Out of Band Management > Configuration > Provisioning > Delayed Provisioning > and select the ‘Delayed Provision' Task.

9. Concerning the options:

1. Override OTP: - If you don't want to use a random AMT password, check this option.

2. Switch to AMT: - Unless you're using ASF and want to keep using it on those computers that have it enabled, check this option.

3. Ignore intermediate errors: - Don't check this option unless there's a reason to ignore DNS and OTP errors.

10. Leave it on a Daily Schedule. Systems that run this and provision will drop out of the collection and not run the policy again.

11. Enable the Policy.

Once the above steps have been completed, the process should be automated as long as steps 1 and 2 are met. The collections will properly target each system so that the right steps occur in the right order.

Conclusion

The Delayed Provisioning Task allows an administrator to catch those systems that have not provisioned due to a number of reasons. This allows the systems to get provisioned in a targeted fashion, and if properly configured make it completely automated. As of version 6.2 of Out of Band Management, this only applies to provisioning by Remote Configuration. Please check these other articles for details on how to provision systems if not using Remote Configuration:

http://juice.altiris.com/article/3612/using-intels-rct-tool-restart-amt-hello-packets-enterprise-provisioning

Lastly, this process does not touch on certificates used to encrypt AMT management traffic. This is the TLS option set in a Profile for any communication after the AMT system has been properly setup and configured. The certificate obtained for Remote Configuration is only for the Setup and Configuration process (also known as Provisioning).

Installing Multiple Intel SCS components for a large Notification Server environment

Some Notification Servers carry huge loads of managed systems. I've seen Notification Servers managing 10,000, 15,000, and even 20,000 plus systems. For Out of Band Management with the Intel SCS Component, a multiple-service install may be required to handle large loads of provisioning or maintenance requests into the Intel SCS Component. This article covers how to setup such an environment.

Introduction

Normally in a simple Notification Server environment when the install for Out of Band Management is initiated, all the necessary pieces, including the Intel SCS Component, install automatically and silently. In more complex environments the automatic install of the SCS Component often throws an exception and provides a message indicating the install should be conducted manually. This manual process is what will be used when installing the components on the subordinate servers who will share the load for the Intel SCS Component.

Installing Out of Band Management

The first step is to install Out of Band Management and the primary Intel SCS Component on the Notification Server. This will setup the IntelAMT database that will be used with every install of the Intel SCS Component. The following process details the install methods for Out of Band and the Intel SCS Component.

Simple NS environment

For a simple NS environment where the Application Identity for Notification Server has full rights to both the Notification Server system and SQL Server, the initial install is simple. Note that this process should be used for Simple and Complex environments to lay down the essential components on the NS.

1. In the Altiris Console, browse View > Configuration > Install/Upgrade additional solutions.

2. Under available solutions, click the ‘Segments' button.

3. Expand the Partner Solutions section and locate the Altiris Manageability Toolkit for Intel vPro Technology.
   !SolCtrvPro.jpg!

4. Click the link to launch the install.

5. NOTE: This will install the following primary components, all of which tie into aspects of Out of Band Management and Real-Time System Manager:

1. Task Server and supporting installs

2. Real-Time System Manager

3. Real-Time Console Infrastructure

4. Out of Band Management Solution

5. Our of Band Setup and Configuration (AKA the Intel SCS Component)

6. Network Discovery

6. The install will commence. Note that if the Intel SCS Component is unable to be successfully installed you will receive a message indicating it needs to be installed manually. If this is the case, see the next section entitled ‘Complex NS Environment'.

7. If no errors are shown, the Intel SCS Component with the IntelAMT database should have been installed and created successfully.

Complex NS Environment

Despite the name of this section, sometimes the steps here need because of a minor security issue when the automatic install was attempted. The following steps detail the process of install the Intel SCS Component manually.

1. Run through the install as detailed under the ‘Simple NS Environment' section above. This will put all the typical components in place, and likely the automatic install of Intel SCS will fail, requiring the next series of steps to be completed.

2. It's recommended to log into the Notification Server as the Application Identity user.

3. Browse to the following path on the NS: install_path\Program Files\Altiris\Notification Server\NSCap\Bin\Win32\X86\OOB\IntelSCS\

4. Launch the EXE AMTConfServer.exe.

5. Click ‘Next' on the Welcome screen and accept the license agreement and click ‘Next'.

6. Choose ‘Complete' as the type of setup and click ‘Next'.

7. In the User name and Password fields put in the Application Identity for the NS.

8. Check the Web details.

9. Leave ‘Force Secure Connections (HTTPS)' checked if you will use TLS to encrypt AMT traffic, or uncheck it if you will not be using TLS. Click ‘Next'.

10. Under ‘Database Server' select the database name and instance (if applicable) to use. It is recommended to use Windows Authentication, but if the SQL setup requires a SQL account, choose that option. Click ‘Next'.

11. The next details should be left as is. Click ‘Next'.

12. Click the ‘Install' button to proceed with the install using the parameters set.

13. At the Complete screen, leave the ‘Start Intel® AMT Config Service' checked and click ‘Finish'.

Subsequent SCS Installs

Now that NS has all the required components, and the IntelAMT database has been created, the following details cover how to install a subordinate install of the Intel SCS Component. Note the following prerequisites for this type of install:

• Windows 2000 Server, Windows 2003 Server

• Internet Information Services (IIS)

• Microsoft .NET 2.0

Run through the following steps to install Intel SCS.

1. Log onto the system as the Application Identity user for Notification Server.

2. Browse to the following path on the NS:
   <NS_Name>\NSCap\Bin\Win32\X86\OOB\IntelSCS\

3. Launch the EXE AMTConfServer.exe.

4. Click ‘Next' on the Welcome screen and accept the license agreement and click ‘Next'.

5. Choose ‘Complete' as the type of setup and click ‘Next'.

6. In the User name and Password fields put in the Application Identity for the NS. If this is not possible the user should have full access to the SQL Server. This will also be the user set on the Service AMTConfig.

7. Check the Web details.

8. Leave ‘Force Secure Connections (HTTPS)' checked if you will use TLS to encrypt AMT traffic, or uncheck it if you will not be using TLS. Click ‘Next'.

9. Under ‘Database Server' select the database name and instance (if applicable) to use. This should be the SQL Server used to install the IntelAMT database in previous steps.

10. The database details . Click ‘Next'.

11. Click the ‘Install' button to proceed with the install using the parameters set.

12. You'll receive a notice saying that the database IntelAMT already exists. Make sure to click ‘Yes' so it uses the existing one.

13. At the Complete screen, leave the ‘Start Intel® AMT Config Service' checked and click ‘Finish'

14. From the Notification Server, at this location: , copy the file oobprov.exe to the same path on the subordinate install (default will be C:\Program Files\Altiris\OOBSC\).

15. NOTE! You must use the same path that it used on the Notification Server, this is a limitation of this implementation.

16. Copy to the same folder the attached file Interop.AeXClient.dll.
    !RemoteSCS.JPG!

17. Normally the script (oobprov.exe) is properly registered to the correct path, but if it is not, we must manually change it.

18. Open SQL Query Analyzer or SQL Enterprise Manager. Run the following query:

1. USE IntelAMT
   SELECT Props_script_path, use_props_script
   FROM csti_Configuration

19. Check the path and make sure it matches the remote and local Intel SCS install. Also verify that the use_props_script is set to 1, which means ‘True' (0 means ‘False'). Now run the following query if they need to be updated, but take note to change the path to match your environment:

1. UPDATE csti_configuration
   SET props_script_path = ‘C:\Program Files\Altiris\OOBSC\oobprov.exe'
   SET use_props_script = 1
   WHERE configuration_id = 1

20. Everything should now be in place for both the primary and secondary Intel SCS install to work with systems being Provisioned, including subsequent maintenance or reconfiguration functions, sharing the load.

Confirm Registration

The next step is to confirm that the install has successfully registered in the IntelAMT database and is running. Use the following steps to make the checks:

1. First, let's check that the Secondary SCS Server has properly registered in the IntelAMT database. On the SQL Server where the IntelAMT database is housed, open SQL Query Analyzer or SQL Enterprise Manager. Run the following query:

1. USE IntelAMT
   SELECT * FROM csto_servers

2. You should have one entry for every Intel SCS install you've completed.

3. On the secondary Intel SCS Server, go to Start > Administrative Tools > and click on ‘Services'.

4. Locate the Service ‘AMTConfig'. Ensure the following settings:

• Status = Started

• Startup Type = Automatic

• Log On As = NS Application ID

Adjust Queue Settings

The last part is to adjust the general settings to account for the added resources.

1. In the Altiris Console browse to View > Solutions > Out of Band Management > Configuration > Provisioning > and click on ‘General'.

2. Look under the ‘Service Maintenance' section. See the screenshot, followed by the recommended settings:
   !OOBGenSettings.jpg!

• Max queue size: 2000 for one instance, add 1000 per secondary server

• Worker threads: 10 for one instance, add 5 per secondary server. Same for the Slow worker threads

3. The above values are recommendations. Since thorough testing has not been performed, it is recommended to change these in small increments if performance is a problem.

4. Make sure to ‘Apply' the changes once they've been made. This should allow the SCS infrastructure to handle larger loads of incoming requests.

Conclusion

The subordinate Intel SCS install process should be repeated for each Intel SCS install desired in the environment. This will help distribute the load of incoming requests from Intel AMT vPro systems. Moving forward Symantec and Intel will be testing this scenario further. In the interim this article can be used to increase the resource power of the SCS infrastructure.

Sometimes the methods for dealing with hostile or infected systems on the network are drastic, resulting in lost productivity, time, and energy. In one example the IT staff would physically shut down the user's main network port, sealing off all production systems, test systems, etc, until the hostile machine could be dealt with. Phone calls results, requiring the user to deal personally with the affected system. Now take Intel AMT's System Defense. Remotely quarantine a hostile system and use Altiris to remediate it. System Defense, it puts the power in the hands of the administrator remotely.

Introduction

System Defense (formerly known as Circuit Breaker) allows network filtering at the level of AMT. Systems that have been compromised and are a threat to the network can be remotely quarantined, with certain ports and IP addresses available for remediation. For example the entire network can be filtered out except to the NS, and only those ports required for the Notification Server to remediate the client (install anti-virus, patches, remove harmful software, etc).

Note that testing is vital when using a mechanism that can potentially cut off a system from the network. The ease of remediating compromised systems remotely while quarantining from the main network will remain as long as the filters are properly configured. If not, the system may require a desk-side visit to bring back on the network.

System Defense

System Defense shows as Circuit Breaker in some versions of the Altiris Manageability Toolkit for Intel® vPro Technology. This feature allows a network filter to be placed at the hardware level via AMT. AMT will hijack the operating system's hold on the network connection and apply a secure filter based on a configuration file provided by the administrator.

See the following diagram for a representation of how System Defense (Network filtering) works:

This filter becomes a complete block that disallows any network communication in OR out, save those sources that are configured. Note that the parameters for allowing network communication are those of Sending IP Address and Port. This means that not only to systems have to be explicitly defined to be allowed through, but the ports they are using as well.

Use Cases

The following use cases will find real value with System Defense network filtering:

• Virus attack from an infected vPro client - This cuts off the ability of that virus to send packets out on the network

• Vulnerable vPro clients without anti-virus - Close off the ability of a virus from getting through to the vulnerable system

• Vulnerable vPro clients without critical patches or updates - Quarantine systems, but allow NS to remediate to bring the system up to corporate security standards

• Unauthorized Network use - plug a system that is found participating in unauthorized network use, whether it be unauthorized content, gross use of bandwidth for non-approved purposes, etc...

• For fun - Drive a fellow administrator crazy by applying and removing filters randomly from his computer (Just kidding, don't try this at home, or at work for that matter)

Task Server Integration

As of Real Time Console Infrastructure release 6.3 the Task Server now has a Task type of Network Filter. This exclusively uses Intel AMT System Defense to apply a comprehensive filter that only allows strict communication to and from the NIC. Because of Task Server's sequencing engine and collection targeting, jobs using this can be setup to do a large number of things, including patching, critical application install such as anti-virus, and other critical computer maintenance items required by the organization.

Task Server Jobs

As a primer for details in this article, see the following article series on Altiris Juice: http://juice.altiris.com/article/2088/utilizing-intel-vpro-amt-technology-with-task-server-introduction.

See the Introduction for more information on jobs. There are two major types of a Network Filtering job:

1. Apply a System Defense network filter, either the default filter allowing communication to the NS for remediation or a custom filter allowing access to necessary resources

2. Remove a System Defense network filter to open back up general network communication

See the following screenshot for the option when this Task type is created:

• The first radial button allows the application of a filter, either a custom or the default, with the added option of enabling anti-spoofing filter

• The second radial button simply applies a PING filter to the target systems

• The third and final radial button removes any filters previous applied to the system

Job Targeting

Because of the significance of System Defense and what it does to client computers, I'm going to cover how Task Server Jobs target systems. With a Task Server job you can add individual systems or whole collections of computers. Collections are either manually or dynamically defined and can have few or many systems therein. Multiple systems and collections can be attached to the running of a job, either on demand or by a schedule.

Since System Defense is essentially quarantining vPro Systems, any Task or Job should be tested in a lab environment to ensure workability. If a custom filter is used, the potential to decapitate vPro systems from the network becomes a very real, very severe consequence of improper filters. Take the scenario of having a custom filter that does not allow proper communication back to the Notification Server or another critical resource (like Task Server) in the remediation process. Once the trigger is pulled and the System Defense network filter has been applied, those systems now have insufficient network access to remediate, which may mean that a remote Task to remove the filter is unavailable. IF the job contained half the computers in the environment, the impact is huge.

I say again: Test every filter within every job to ensure everything works properly!

Filter Configuration

Real-Time System Manager allows you to create your own filter configuration files to use with a System Defense Task. In some instances it may be required to open additional ports or destination IPs for full remediation to occur. If you use Package Servers to deliver software you may need to allow communication to these systems.

Edit Network Filters Utility

A utility is provided to create, edit, or otherwise revise any filter file to be used by a System Defense Task. This filter is provided via the Altiris Knowledgebase.

Installation The ENF Utility

See the following article for both the guide in using the utility and to download the utility directly:

https://kb.altiris.com/article.asp?article=34891&p=1

The attached file is a zip. The file included Altiris_ENF_6_2.exe will install the utility on the computer it is executed on. The prerequisites for this utility include:

1. Windows 2000 Server or Windows 2003 Server

2. .NET 1.1

3. Notification Server 6.0 Sp3

4. At least Real-Time Console Infrastructure 6.2

Using the ENF Utility

Once the installation has run, the Altiris Console can now be used to edit the filters. It's found in the Altiris Console under View > Solutions > Real Time Console Infrastructure > Configuration > and click on ‘Edit Network Filters'. The console provided a spreadsheet of the current filters for the default filter file, as shown:

When you click the Edit pencil icon, a subsequent window will appear. This wizard will walk through editing of the filters. This same wizard is used to add new filters to the list. This wizard is robust and allows minute tuning of what ports are allowed, both for sending and receiving from the NS and from the host AMT computer. The wizard appears as follows:

The default file is called CBFilters.xml and is found at \Program Files\Altiris\RTSM\UIData\. Other files can be created and used in the System Defense Filtering Tasks. It is configurable per Task or Job instance.

NOTE: If you plan on making changes to the default filter file, it is recommended to browsing to the file and making a copy of it. The copy will be a backup to use in case the default file becomes corrupt through editing or for related recovery options.

The best way to know how to open which ports to enable the access you require is to consult the documentation for the application or mechanism you are trying to work with. For example the Task Server uses ports 50120 through 50124, and these ports need to be opened between the Task Server to be used and the client computer.

Conclusion

As previously indicated, make sure you test every system defense task and job you plan to use out in your environment. It's one thing to test against one or two systems where you can manually resolve any unforeseen problems, but if a targeted collection contains many systems and the job or task as an unforeseen issue, this can cut off all these systems from the necessary access to restore network functionality. So test, test, test, and test again before deploying large jobs using System Defense network filtering.

When used properly, this tool enables administrators to remotely deal with vulnerable or infected systems remotely, and stop unauthorized network use. With System Defense enable your administrators to more quickly deal with threats, and remediate in much less time.