Intel,Altiris Group

Handling Common Provisioning and Configuration Errors 

Sep 05, 2007 11:04 AM

If only solutions were perfect, errors resolved automatically, and tuning was never required nor needed. Then again, that's what many of us get paid to do and handle. The intent here is to focus on common Intel® vPro™ configuration and provisioning errors in an Altiris environment. More importantly, the article intent is to provide some insight on the correction needed or tasks to handle common errors.

The Basics

Deploying an Altiris Out-of-band management solution with Intel® vPro™ enabled solutions presents many working parts. In a lab environment - these "always" work well. In a production environment, determining the cause of an error could be difficult at best. Generally speaking, to isolate the scenario take into consideration the management console, the vPro configuration services (e.g. Intel® SCS), the OEM firmware and drivers, and the infrastructure. The lab environment comes in handy to isolate components and aspects, especially when so many variables are present.

In stepping through each item, consider the following basic points:

  • OEM hardware and drivers - Check the update page for the latest BIOS and Firmware on the platform. The BIOS update will often include the Intel® AMT firmware. For more on AMT versions see http://www.symantec.com/connect/article/2160/ intel-174-amt-versions-and-features). The drivers to be checked are mentioned here - http://www.symantec.com/connect/article/1581/ part-2-enterprise-integration-future-state-and-client-platform
  • Intel® SCS version - If version the AMTconfig service shows version 1.2.x, please review the Tech Tip and linked Altiris KB article referenced at http://www.symantec.com/connect/tech-tip/2221/ out-of-band-manager-scalability-q-a-for-scs-1-2. The current production version for an Altiris environment is v1.3. If you are using the beta version of OOBM, then Intel® SCS will be version 3.x.
  • Infrastructure - Ensure a ProvisionServer DNS record exists for the target DNS domain, and that this pointer record resolves to the Altiris OOBM server. The "DNS Configuration" section of the OOBM'Provisioning'Configuration Service settings is a handy resource to determine whether DNS resolution and the AMTSCS virtual directory are correctly configured.
  • Verbose Logging for SCS events - Change the Log Level to "Verbose" mode. This will log all informational, warning, and error messages and events in the SCS log. This is good to see when a hello packet is received, when the ProvisionServer attempts to provision the target system, and so forth. When changing this setting, you may also want to decrease the log retention level to a few days or shorter timeframe than the default value. Depending on the number of systems managed or attempting to provision, setting the log level to "verbose" may rapidly grow the size of the IntelAMT database.
  • Open the SCS Event Log - This is found under OOBM'Provisioning'Logs'Log. The example below has a filter set to show only errors. The next section will address some common errors that might occur and potential resolutions.
  • Ensure Resource Synchronization is Set - In addition to the Altiris oobprv.exe process which handles the scripted batch for provisioning, this configuration setting provides a few important items. A default profile assignment is selected. A replication schedule of the IntelAMT to Altiris CMDB is specified. A count of objects discovered and replicated to the Altiris CMDB is shown.

Handling common Intel® SCS errors

With the SCS event log set to verbose mode, not only will successful provisioning events show but also warnings and errors if you are having difficulty in provisioning or configuring an Intel® vPro™ client. When a successful provisioning process occurs, you will see a sequence of Intel AMT properties being set followed by the statement "Commit Changes". Once this occurs, the target system is configured and ready to send\receive AMT webservice calls.

However, if this does not occur, the following is a list of common errors with guidelines on how to interpret and resolve.

  • Error 102 - Intel AMT device is already provisioned
    • This indicates that the IntelAMT database has the target system identified as provisioned. If the target system was manually unprovisioned via the local MEBx, than manually delete\remove the entry from the provisioning console. From a provisioning security perspective, this error may also indicate an attempt to replay a provisioning sequence. The ProvisionServer with Intel® SCS running will allow reject additional requests if the system is already listed as Provisioned.
  • Error 103 - Request is already in the queue
    • This is really a status or awareness indicator. Provisioning and maintenance requests are queued within the IntelAMT database and processed by Intel® SCS servers. In larger implementations, multiple Intel® SCS servers can be configured to process requests within a single IntelAMT database queue. (NOTE: Current Altiris implementations have a 1:1 ratio between the SCS and IntelAMT instances. Plus, the IntelAMT database instance MUST reside on the same SQLServer as the CMDB instance. Configuring outside this base setup will be explained in a separate article.) The queue includes immediate and delayed requests. Thus if a request is already delayed, this error will be generated. Similarly, if the request is being processed or handled by the poller, a competing request will generate this message.
  • Error 137 - Another process currently working on AMT
    • The target AMT device has a preceding request that has not completed. For example, if a partial un-provision request has not completed and a reprovision request is sent, this will generate the error. Reasons for the previously queued request not completing might including connectivity, difference of provisioning state, and so forth. If the error is persistent for a target AMT device\system and connectivity to the target system is available - try executing a management function is the system is in a configured state. (e.g. Remote inventory, remote power on\off, etc). If unsuccessful, the target system may be in an unsupported state. A manual process of partial unprovision may be required. Removing the assigned profile at the provisioning console should occur also.
  • Error 139 - Failed to update Kerberos Password with Kerberos Integration is disabled on server
    • Intel® SCS has the ability to integrate with Microsoft Active Directory for Kerberos based authentication. The current Altiris integration of SCS does not include this feature, thus a separate and perhaps non-supported version of SCS has been installed and not properly configured for an Altiris environment. The next release of Altiris OOBM is expected to include Kerberos integration - please refer to http://beta.altiris.com.
  • Error 407 - Batch exit code 0xfffff
    • This is a -1 return caused between the Altiris provisioning script (oobprv.exe) and the SCS instance. Incomplete Intel® AMT profile, missing Resource Synchronization data, or other console configurations will likely cause this error. Check the Altiris provisioning console configuration. If the error is persistent afterwards, refer to the SCS debug log creation below and contact Altiris support.
  • Error 602 - Exception in clock sync worker
    • Clock synchronization is important in Kerberos environments, since the authentication process has a time stamp dependency. This error is benign in currently Altiris environments and can be ignored if needed. It refers to a SOAP call failure - thus further environment and infrastructure investigation may be needed for future environments.
  • Error 913 - No rows found in get UuidMap
    • For provisioning to occur, the UUID and the FQDN of the target vPro system are mapped together. In an Altiris environment, the UUID and FQDN are typically obtained via the Altiris CMDB due to a network discovery, Altiris agent, WMI call, and so forth. The Altiris process oobprv.exe executes a provisioning script to connect the UUID found in the hello packet with the Altiris CMDB provided information. More explanation is provided in the related Altiris Juice articles linked below.
  • Cannot contact back AMT with IP:xxx.xxx.xxx.xxx Exception
    • The recorded IP address from the hello packet sequence is not responding to requests. If the target system sends a new hello packet with an updated IP address, Intel SCS will update the queue entry. This error commonly occurs when the system has been connected, an IP address and DNS resolution have occurred, hello packet was sent, and then the system was disconnected from the network prior to the ProvisionServer response. A common scenario is pre-staging a system before sending to the intended location.

If the suggestions above are not helping, and a deeper investigation of Intel® SCS is needed - a debug log can be created. The linked article provides some details on how this is accomplished - http://www.symantec.com/connect/tech-tip/1627/creating-an-intel-scs-service-amtconfig-log-a-k-a-how-to-enable-debug-logging.

Common Altiris Notification Server and RTSM errors

With all the emphasis on provisioning sequence and Intel® SCS, other common errors and situations may occur once an Intel vPro client is provisioned. The following points provide a summary of common errors, explanations, and potential solutions.

  • Graceful power action not shown in Real-Time Systems Manager
    • If only the Intel® AMT power options are shown (e.g. Reboot, Power Off, and Power On), the infrastructure or Altiris management environment is not configured for WMI. Another likely scenario is the target Intel vPro client's Microsoft Windows operating system is neither stable nor functional. When this option is available, the beauty is that an Intel vPro client can be graceful shutdown via WMI, then rebooted or powered off via Intel AMT.
  • Altiris console or database timeouts
  • The database or console application response is delayed beyond the defined timeout values. Check the load on the application server and database for competing requests and processes.
  • Intel AMT redirection session fails to connect
    • When initiating a redirection session (Serial-over-LAN or IDE-Redirection), the target Intel vPro client might reboot and respond to the initial sequence yet the console fails to connect. This is typically due to an infrastructure or connectivity issue. The session setup requires a series of bi-directional communications to establish redirection. Incorrect DNS entries, dropped IP packets, or related communication issues may cause the redirection session to fail.
  • Intel AMT provisioned systems are not appearing in the Altiris collections.

Conclusion

As with most troubleshooting scenarios, the key is isolating and replicating the error in order to appropriate resolve. Altiris OOBM with Intel® vPro™ presents a number of variables to consider. In isolating those variables, a resolution will be found or sufficient data will be available when the call to support is required.

If there are other common errors or experiences out there - please comment and provide insight.

The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries.

Statistics
0 Favorited
1 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.