New articles for you to take a look at this week. As always, let me know if you have a best practice or known issue that you want to share or have investigated!

• Using international keyboards to create MEBx passwords via Setup and Configuration Service (SCS)

• What is the Authorized column in SCS?

• Do management workstations running the SMS console and SMS Add-on require patches as outlined in the documentation for the Intel(R) AMT Add-on for Microsoft SMS*?

Here are some high level steps that walk you through procuring a VeriSign certificate and configuring it for the Intel Setup and Configuration Service (SCS). Other certificate vendors like Go Daddy, Starfield, Comdo, etc will have different purchasing processes.

Purchase Verisign Certificate

1. Generate Certificate Signing Request (CSR) by following the instruction in the link, http://www.verisign.com/support/ssl-certificates-support/page_dev019431.html.
2. The Common Name (CN) needs to be the FQDN of the server you want to install this certificate on. (i.e. host name + domain name)
3. Enter ‘Intel(R) Client Setup Certificate' for Organization Unit (OU).
4. Complete all the steps. Visit VeriSign website, http://www.verisign.com/ssl/buy-ssl-certificates/ to start purchasing process. Select ‘Secure Site: SSL Certificates' under ‘Buy Individual SSL Certificates'.
   Note: you could choose the other two, which are in more advanced level, depending on your need.
5. Enter all the information required and copy the CSR generated by the server
6. Complete all the steps and print out the order confirmation page for your record.
7. You will receive an email of Verisign automated order verification within few hours. You have only 24 hours, after receiving the email, to finish this process. Click the link in the email and go through the process. \\\\\\*Important:* If you cannot recognize the second phone number listed on the webpage, cancel the automated verification process and have them call you instead.

Certificate Installation and Exporting

1. You will receive the link of installation instruction in the email containing the certificate. Follow the instruction to complete installation
2. VeriSign will send you the SSL certificate via email. If the certificate is an attachment (Cert.cer), save the file to the hard drive. If the certificate is in the body of the email, create a .cer file (example: NewCertificate.cer) by copying and pasting the certificate text into a plain text editor such as Notepad or Vi. Please be sure to include the header and footer as well as the surrounding dashes. Do not use Microsoft Word or other word processing programs that may add characters. Confirm that there are no extra lines or spaces in the file.
3. Open the Internet Services Manager (IIS). Click Start > All Programs > Administrative Tools > Internet Information Services (IIS) Manager.
4. Under Web Sites, right-click your web site and select Properties.
5. Click the Directory Security tab.
6. Under Secure Communications, click Server Certificate.
7. The Web Site Certificate Wizard will open, click Next.
8. Choose Process the Pending Request and Install the Certificate, then click Next.
9. Important: The pending request must match the response file. If you deleted the pending request in error you must generate a new CSR and replace this certificate.
10. Select the location of the certificate response file, and then click Next.
11. Read the summary screen to be sure that you are processing the correct certificate and then click Next.
12. You see a confirmation screen.
13. After you read this information, click Next.
14. Go back to IIS Manager (Start > Programs > Administrative Tasks > IIS Manager)
15. Expand Web Sites and right click Default Web Site
16. Under Secure Communications, click View Certificate...
17. select Detail tab
18. Click Copy to file at right bottom of window, the Certificate Export wizard will pop up. (N)
19. choose Yes, export the private key (N)
20. mark Include all certificates in the certification path if possible (N)
21. give a password (can be weak password) and confirm (N)
22. Give location and file name for the resulting PFX. (N), Finish, Ok.
23. Close all windows.

Adding Cert To SCS

Install the certificate created above in the System Certificate Store on the platform where the SCS executes. Follow the following steps:

1. Open certificates (local computer) using the Microsoft Management Console (MMC). To add the certificates plug-in to the MMC,
2. Select file/add snap-in.
3. Select Add....
4. Select Certificates.
5. Select computer account; click Next.
6. Select Local computer; click Next.
7. Select Finish; Close; select Certificates and click OK.
8. In the console tree, click the logical store where the mmc will import the certificate.
9. On the Action menu, point to All Tasks and then click Import to start the Certificate Import Wizard.
10. Type the path and file name of the certificate to be imported or click Browse and navigate to the file. Select automatically select the certificate store based on the type of certificate.

1. Located at <install_root>:\Program files\Intel\AMTConfServer\Tools.
2. Double-click on loadcert.exe
3. Select the certificate that was just imported. The utility will report any problems in the certificates that it detects that would prevent using it as a ZTC certificate.

• SoL/IDER can’t be disabled on Lenovo* M55p

• Will PKI-CH consistently support wildcard certificates across Intel(R) AMT versions?

• Is SNMP Trap Service required for SCS?

• Intel(R) AMT Active Directory error message

• Organizational Unit Field in Configuration Parameters must be populated to complete provisioning

Here's the weekly update of issues posted to the Known Issues, Best Practices, and Workarounds wiki:

As a network administrator for a small local government agency, I have been tasked to deploy Intel's Active Management Technology (AMT) into our network environment. Having sold our IT management on the benefits of vPro technology and how it can revolutionize our system management capabilities, I am ready to move forward and get AMT installed . In addition, today I learned that we will begin receiving brand spanking new HP systems in January that will have the latest greatest vPro technology aboard. I've got a few months to become an AMT expert and be ready for the new systems. Life is good!

Where To Start

The first thing I did after learning about vPro and AMT was to visit the Intel vPro Expert Center web site. There I found a great variety of resources to help me with my deployment. This is a good site to get help and guidance. The only problem I have with the site is that there's no link to download the AMT docs or software. You'll want to get your hands on the Intel Active Management Technology Setup and Configuration Service (SCS) - Installation and User Manual. You can get this document as well as the software from http://softwarecommunity.intel.com/articles/eng/1025.htm. Since SCS is the foundation and support structure of everything that goes on in the AMT and vPro world, this was the most logical place to start.

In addition, since I plan on integrating SCS with my existing SMS 2003 infrastructure, I also downloaded the Intel Active Management Technology Add-on for Microsoft SMS 2003 - Installation and User's Guide. Getting this was a bit of a challenge so stay with me on this one. I had to navigate to another good link you'll want to keep and refer to, The Intel Management Developer Community. From here I searched for "SMS 2003" and found the link to the SMS 2003 Add-on document. For non-developers like me, this site can appear to be not exactly what we do everyday, but hang in there, this site has a lot of info too. Now I had the documents I needed. They created the basis on which I would start to plan and deploy AMT into my network.

Read, read, read

The first thing I did after printing the documents was to read them over several times so I could get the gist of just how all the pieces played together. Then I read them again. After the first pass, it all looked pretty daunting and difficult, but after reading many of the sections over, it all started to come together and make sense. Read. Read. Read.

Time to lay things out

Ok, now I had a pretty good idea of what everything did and why, it was time to make sure I had everything I needed to make the pieces work together. I began to try and lay out what I needed to have to make AMT work.

Servers - I need to decide where to install SCS. I had a recently rebuilt Windows 2003 R2 server available that also had SQL 2005 on it. Plenty of disk space and horsepower. This was good. We were using this server to host our Help Desk application and it didn't appear to be over taxed in any way. The hardware and base OS part was taken care of. The server happened to be in our central office which was also a benefit. Our office is put together in a spoke and wheel configuration with all outer offices connecting to the central office over fast network connections. This would be good when we start to provision systems from outer office locations.

Active Directory - SCS / AMT relies on and utilizes Active Directory quite a bit. Our Active Directory is at Windows 2003 R2 level so I'm good to go. Also, as a Domain Admin, I have the ability to make any changes necessary to Active Directory.

Security - AMT supports Transport Layer Security (TLS) for secure communications between AMT devices and management console applications. TLS is optional for AMT, however we wanted to make all our communications as secure as possible so we're going for a full TLS implementation. This requires certificates and fortunately we have a Microsoft Certificate Authority server in our network that will make things easy to manage.

Database - SCS stores all its information in a database. We're going to use the existing SQL 2005 database on the server we're going to install SCS on.

AMT Device Location - Where were the new systems coming into and who was handling them? In the past when new systems came in, our Help Desk techs were very efficient in imaging them and deploying them right out the door. I need to make sure that everyone in our Help Desk group was tuned into what we were trying to do. We'll need to have a meeting to discuss what's going to happen after they plug in a system to the network for the first time.

Now that I've gotten my infrastructure laid out, it's time to start installing software. Yeah!

Next time I'll detail the steps I took in actually installing SCS into my network. As always, any comments and suggestions are warmly welcomed.

This is the third and final part of this series (at least for now). The previous two posts include Basics and Common Intel SCS errors

BEFORE GOING ANY FURTHER - PLEASE READ AND ENSURE THE FOLLOWING
At this point, you have ensured the infrastructure is setup correctly and have attempted to troubleshoot the common Intel SCS errors as listed in the SCSconsole log file. Intel vPro systems are being recognized and listed in the SCSconsole. However, strange or unexpected behavior continues to occur - whether during provisioning, maintenance, or other activities. If Intel SCS has been included in a system management console or a provisioning script provider with whom you are working - AND - further debug analysis is needed, the following points may help. The debug log output may be one of the datapoints requested to replicate and remediate issues.

Before we go on - please note that these steps require modifications to the Microsoft Windows Registry on the system labeled as "ProvisionServer". That system will be running the AMTconfig service. Enabling the debug logging features will require root drive access and space to capture and store the log outputs. The logs will be stored at the root of C:

Ready to create an Intel SCS debug log?
SCS debug logging is off by default. If enabling for troubleshooting purposes, be sure to disable when done troubleshooting. The following steps will require a new registry key and string value to be added. Once these changes have been made - restart the AMTconfig service. At most, two log files will appear on the root of c: drive. The first is scs_win_server.log the second is scs_server.log. The second commonly appears only after errors have occurred.

Create the following registry key on the service's machine:

HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\AMTConfServer\Log with string value "LogLevel"="V"

Click on the following image to view the entire image

This blog is divided into 3 sections - understanding the basics, addressing common Intel SCS errors, and how to generate an Intel SCS debug log.

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 with Intel Setup and Configuration Services (SCS). More importantly, the article intent is to provide some insight on the correction needed or tasks to handle common errors.

The Basics
Deploying 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. 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. The drivers to be checked are mentioned Management Engine Interface (MEI), Local Management Service (LMS), Serial over LAN (SoL), and User Notification Service (UNS). NOTE: UNS applies to AMT 3.0 and higher versions.

• Intel® SCS version - Don't know what version if running? Check the AMTconfig service properties or version listed in the SCSconsole. More on SCS and AMT versions here. Version 3.2 is the latest. If running version 1.x, an update to version 3.x is recommended. Check first with preferred system management vendor on supported setups, upgrade paths, and so forth.

• Infrastructure - Ensure a ProvisionServer DNS record exists for the target DNS domain, and that this pointer record resolves to the server running AMTconfig (e.g. Intel SCS). Ensure proper resolution of the DNS entry for the FQDN of ProvisionServer (e.g. ProvisionServer.company.com)

• Verbose Logging for SCS events - Within the SCSconsole, access the 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.

Image of SCSconsole and setting logging to verbose mode




Image of SCSconsole viewing log events in verbose mode

Traditionally speaking - if security is improved, manageability suffers. The reverse of this is true also - traditionally.

Intel vPro presents a different approach and perspective to this common understanding - consider some of the usage models and scenarios described at the follow link. http://www.intel.com/business/vpro/index.htm (see the "improve security" and "extend manageability" links on this page under Resources - lower right side)

The above links demonstrates and introduces the usage models and capabilities. But - what about ensuring the security of the platform. As commonly inquired - "Could vPro be used maliciously?". Considering that any tool of value - even the screwdriver sitting in a garage or a desk drawer - could be used maliciously, the question might be better phrased - "What are the built-in security features of Intel vPro?" The following is only a summary and overview - yet should provide some comfort in the platform. (BTW: Are you aware of all the security features in current environments, or would introducing vPro perhaps expose a long term policy or technological oversight? Just a thought.)

• Internal security - Use of Intel digitally signed firmware. In some cases, the OEM will also require their digital signature for firmware updates. The non-volatile RAM (NVRAM) has strict security and access control. There is a small section referred to as "3rd party datastore" or 3PDS. Access to this area requires registration with Intel and granting of a token. Communications into the management engine occur through secure channels - whether from the operating system or from the network interface. Generally speaking - compromising the internal security would indicate there are bigger problems in the environment.
• Enterprise setup and configurationsecurity - Enterprise mode setup and configuration is handled via either a pre-shared secret or certificate based authentication. (see related blog on the latter). The configuration uses secure handshakes, authentication, and so forth. Replay attacks are prevented. With the latest configuration service, option to require authentication or approval of systems to be provisioned\configured. Pre-shared keys are changed after configuration, and subsequently based on definable schedules. Minimal setup rights can be used to limit exposure of accounts to perform setup\configuration. Security audit logs and event logs monitor activities. The process also has dependencies on the enterprise DHCP, DNS, PKI\CA, and so forth. Generally speaking - if the enterprise setup and configuration service is compromised, there are bigger problems wtihin the environment (whether technological, social networking, policy\procedure, etc)
• Operator Security - Roles, permissions, and AMT security realm access control come into play here. This effectively defines who is allowed to configure the "configuration services", who is allowed to authorize or change vPro configurations, and who is allowed to utilize functions on configured vPro systems. The "who" could be defined by a user, group, service, etc.In addition - use of Kerberos for user rights mgmt and so forth provides an integration into the Microsoft Active Directory. Thus a group of users can be defined withe various levels of access control and capability. Plus - all security related actions and configuration changes can be logged. Generally speaking - if an operator compromising vPro security, there are likely bigger problems in the environment (eg. policies, procedures, etc)
• Communication Security - Once a system configured, transport layer security (TLS) or Mutual TLS can used to secure management traffic. User sessions can authenticated using a digest protocol or Kerberos.
• Infrastructure Security - Since vPro effectively hasa separate management computer inside, this management engine can be configured for environments supporting wireless profiles (WPA or WPA2), VLAN, Network Access Control, 802.1x, etc.
• Operational Client Security - On top of all the configuration security items is the end-user usage and capabilities. Items such as System Defense, Agent Presence, remote power management, and so forth.

Open to hear from the community on your thoughts - whether in agreement or disagreement.