[Today's post is provided by Carol Bailey]

With the December documentation update for the Configuration Manager library, we posted a new step-by-step guide for out of band management, to help customers deploy the PKI certificates with a Windows Server 2008 CA (http://technet.microsoft.com/en-us/library/dd252737.aspx).  One of the main differences with this guide from the equivalent step-by-step that used a Windows Server 2003 CA was that it didn't have a procedure for requesting an AMT provisioning certificate from an external (public) CA.  In the Windows Server 2003 CA step-by-step, we said follow any instructions provided by the CA company; otherwise use the Web enrollment procedure to create a certificate request file.

The reason why we didn't include the Web enrollment instructions for the Windows Server 2008 guide was because the later enrollment pages no longer allow you to request a certificate for the computer store.  You can request it for the User store and then export it, but this is an extra step and can untidily leave the certificate installed where it shouldn't be.  It's always better to request the certificate directly from where you are going to use it.

As with the native mode step-by-step guide for Windows Server 2008, using the command-line tool, Certreq.exe, seemed the best choice if the CA company didn't provide their own instructions (usually a form from their Web site).  There are many KBs that provide instructions on how to request certificates from a public CA (for example, http://support.microsoft.com/kb/321051).  However, these assume that you do not have your own enterprise CA and when we tried creating the certificate request file by using Certreq.exe it failed, because it was expecting a certificate template to be supplied.  The certificate template is used with our internal CA and not the public CA, so we weren't sure how much to supply in the inf file that is used to create the certificate request.

I've been working with our AMT tester, Wei Wei, to find a procedure using Certreq that successfully requested and installed an AMT provisioning certificate from VeriSign.  This certificate then successfully provisioned our AMT-based computers, so we knew that the certificate was correct.  Bear in mind that this certificate request method is not VeriSign's usual method to request a certificate, and we were using it more as a proof of concept.  If your chosen CA company does not supply their own instructions or you are having problems with this, following this example might be helpful.

These steps assume that you're following the step-by-step guide and have previously created the security group and certificate templates.  Note that because VeriSign does not support the Intel AMT provisioning OID, this certificate request uses the alternative method of supplying the OU attribute of "Intel(R) Client Setup Certificate".

You can put more options into the .inf file than our example, but we were looking for the minimum that had to be specified in order for the certificate to work.  It needs the following:

• In the certificate Subject, the FQDN of the server that will be the out of band service point and the OU string of "Intel(R) Client Setup Certificate".
• The Exportable = True option because you must export the certificate with the private key, so can that you can then import it into the Configuration Manager database.
• The MachineKeySet = True option so that the certificate goes into the Computer store.
• The request type to be PKCS10 so that it's suitable for a public CA.

And as we've discussed before, this file also needs to reference a certificate template on your internal CA or the certificate request will fail.

You must supply your own values in the Subject= line.  Ours looked similar to this:

Subject="CN=server4.childdom.microsoft.com,OU=Intel(R) Client Setup Certificate,O=Microsoft,L=Shanghai,c=CN"

To request and install the AMT provisioning certificate from an external certification authority

1. On the member server, create a folder to contain your certificate files.

2. Open Notepad, or a similar text file of your choice. Copy and paste the following text into the file:

[NewRequest]
Subject="CN=<server_name_FQDN),OU=Intel(R) Client Setup Certificate, O=<organization>,L=<locality>,c=<country>" 
KeyLength = 2048 
; Supported key sizes are 1024, 1536, and 2048
Exportable = TRUE 
MachineKeySet = TRUE 
RequestType = PKCS10 
[RequestAttributes]
CertificateTemplate = ConfigMgrAMTProvisioning

3. Save the file with the name amtprovisioning.inf, and save it in the certificates folder that you created.

4. Open a command window in the certificates folder that you created, type the following command, and then press Enter:

certreq -new amtprovisioning.inf amtprovisioning.req

5. Submit this certificate request file to the external CA, using any instructions that they provide.

6. When you receive the AMT provisioning certificate from the CA, it is likely to be in an email format. If they do not include their own instructions for processing their certificate response, use the following instructions:

• If they emailed you a file named amtprovisioning.cer as an attachment, save this file into the certificates folder that you created on the member server.
• If they emailed you base-64 encoded text to be copied, create an empty text file called amtprovisioning.cer in the same folder on the member server. Then paste the base-64 encoded text into it and save the file amtprovisoning.cer.
  
  Note: It is also possible that the certificate response file includes the certificate chain, as well as the certificate itself. When this is the case, the extension of the file will be .p7b rather than .cer

7. Open a command window in the certificates folder that you created, type the following command, and then press Enter:
certreq -accept amtprovisioning.cer

At this point, the AMT provisioning certificate from the public CA is now installed and is ready to be prepared for the out of band management component.  You can confirm this by opening the Certificates MMC and checking the certificates in the Computer store, Personal.  You should see there the certificate with the FQDN of the computer and Server Authentication listed under the Intended Purpose column.  If you double-click this certificate and then click the Details tab, you can also verify the Subject value contains the OU string of Intel(R) Client Setup Certificate.

Resume the step-by-step instructions and move onto the section "Preparing the AMT Provisioning Certificate for the Out of Band Management Component."

--Carol Bailey

This posting is provided "AS IS" with no warranties and confers no rights.

[Today's Post is provided by the Configuration Manager Writing Team.]

The Configuration Manager documentation library (http://technet.microsoft.com/en-us/library/bb680651.aspx) has been updated on the Web. All topics that have been updated have Updated: February 1, 2009 at the top of the topic.

Of particular note for R2 customers using SQL Reporting Services: This documentation has been has been updated with information about creating Reporting Services Report models and now includes a procedure for creating advanced models using multiple views in the Configuration Manager database. Additionally, the procedure for deploying report models for use in the Configuration Manager console has been revised so that the instructions are more suitable for a variety of environments.

Most of the documentation changes in this update are a result of customers contacting us with questions, requests for clarifications, and notifying us of omissions and typos - so thank you for helping to improve the documentation for others. We do value your feedback and try to incorporate it when possible. Keep that feedback coming, and contact the documentation team on our usual address of SMSDocs@Microsoft.com.

What's New in the Configuration Manager Documentation Library for February 2009

The following information lists the topics that are new or contain significant changes since the December 2008 update.

About Report Models in SQL Reporting Services

- Updated with new information about deploying report models for use in the Configuration Manager console.

Step-by-Step Guide to Creating a Report Model in SQL Reporting Services - Simple

- Replaces the topic "Step-by-Step Guide to Creating a Report Model in SQL Reporting Services" to provide updated procedures for creating a SQL Reporting Services report model using a single view from the Configuration Manager database.

Step-by-Step Guide to Creating a Report Model in SQL Reporting Services - Advanced

- New topic providing procedures to create a SQL Reporting Services report model using multiple views from the Configuration Manager database.

Step-by-Step Guide to Deploying a Report Model to Configuration Manager

- New topic providing a procedure for making SQL Reporting Services report models available to report authors from the Configuration Manager console.

About Configuration Items in Desired Configuration Management

- Updated with the information that providers retrieve configuration information by using objects and settings defined within the configuration item. The objects that can be defined are assembly, file or folder, and the registry. The settings that can be defined are XML queries, WQL queries, SQL queries, scripts, registry, Active Directory Domain Services, and the IIS metabase.

Prerequisites for Out of Band Management

- Updated with clarifications that the Intel HECI driver is required for in-band provisioning only; DHCP is also required for in-band provisioning; IPv6 is not supported; in-band provisioning is not supported with Windows 2000 Professional or Windows XP Tablet PC.

AMT Provisioning Issues for Out of Band Management

- Updated with the entry "Configuration Manager Fails to Provision Computers In a Child Domain Because of Missing DCOM Access Permissions", which describes a CA configuration requirement when the issuing CA is in another domain. To identify this troubleshooting scenario, look for ERROR: ICertRequest2->Submit failed: 0x80070005 in the log file amtproxyomgr.log.

How to Configure Windows Server 2008 for Site Systems

- Updated to include the fallback status point.

-- The Configuration Manager Writing Team

This posting is provided "AS IS" with no warranties and confers no rights.

[Post contributed by Carol Bailey]

Thanks to a recent Configuration Manager TechNet forum posting, I realized that we hadn't documented the prerequisites for the fallback status point, apart from saying that it required IIS.  When we released Configuration Manager 2007, we didn't support Windows Server 2008, and configuration for IIS was much simpler.  Consequently, I'm not aware of any problems installing this optional site system role on IIS 6.0. 

Then, with Configuration Manager SP1 we supported Windows Server 2008 with IIS 7.0 and we had to detail the IIS configuration in order for our site systems to work: How to Configure Windows Server 2008 for Site Systems. For some reason, the fallback status point wasn't included.  We knew that it had fewer configuration requirements than many of the other site systems, and following the same instructions for the management point was a safe bet because they share common components.  But we were missing what the minimal requirements were, so sent out an urgent request to the product group - and Jeff Nordrum came to the rescue. 

Jeff confirmed the following requirements, how to verify installation, and even some troubleshooting tips.  We got this information just in time to update the prerequisites in the Configuration Manager library for the February update.  However, we didn't have time to incorporate the useful verification/troubleshooting information, so in case anybody is having problems getting the fallback status point to work, I'm including this additional information here.

Fallback Status Point Prerequisites

Windows 2003 Requirements:

• IIS with BITS Server Extensions allowed

Win2008 Requirements:

• Web Server (IIS) (Role)
• IIS 6 Management Compatibility - IIS 6 Metabase and IIS 6 WMI Compatibility (Role Services for Web Server)
• BITS Server Extensions (Feature)

Additional notes:

• With just plain vanilla IIS installed, the fallback status point will not install successfully.
• With the IIS 6 Management Compatibility selected, the fallback status point will install but not work (client state messages fail to reach the fallback status point).
• With the Web Server role, and IIS 6 Management Compatibility (IIS 6 Metabase and IIS 6 WMI Compatibility) and BITS Server Extensions feature installed, the fallback status point will work and successfully process state messages.

How to Verify & Troubleshoot Installation of the Fallback Status Point

Use the following log files to verify and help troubleshoot the fallback status point.

Fallback status point installation log files:

• fspmsi.log (SMS_CCM\Logs folder) on the site system server with the fallback status point role
• smsfspsetup.log (<InstallationPath>\LOGS folder) on the site system server

Verify the installation using both of these log files.  They will log success or failure. If failure, search for ‘return value 3' in the fspmsi.log - log entry above this will contain the installation error details.

Fallback status point site system log files:

• fspisapi.log (SMS_CCM\Logs folder) on the site system server with the fallback status point role.
• fspmgr.log (<InstallationPath>\Logs folder) on the site system server.

Use these log files to verify whether clients are successfully sending state messages to the fallback status point.  You can also check that the reports that depend on the fallback status point are populated with data if clients are assigned to it - for example, "Client Deployment Status Details" (for list of reports that rely on the fallback status point, see http://technet.microsoft.com/en-us/library/bb633154.aspx).

--Carol Bailey

This posting is provided "AS IS" with no warranties, and confers no rights.

[Carol Bailey has provided today's post]

At first glance, dedicating a whole primary site to running Internet-based client management can seem very attractive when you're deciding on site and server placement in your Configuration Manager hierarchy.  Then one look at the Network Diagram for Internet-Based Servers - Scenario 2 with Child Site and you realize that this means two-way SMB traffic, which is not going to fly with your firewall admins or your security folks (and quite rightly so!).  However, think again because this configuration might work well with a simple IPsec policy between the site server in the perimeter network, and the site server in the parent site (often the central site). Because you have to run native mode in both sites, both sites are already using PKI.  You can take advantage of this and deploy additional certificates on the site servers to support IPsec, and then create IPsec policies that use certificate authentication.

In this scenario, create an IPsec policy for both site servers that requires security, use a PKI certificate, allows any IP protocols for all network connections from "My IP address" to "A specific IP address" (the IP address of the other site server), ensure that the default response rule is not activated, and that the filter is mirrored.  The firewall needs UDP port 500 to be open and protocol number 50 (for ESP).  If NAT is being used, UDP port 4500 also has to be open on the firewall.

There are a couple of advantages to using this configuration.  The first is that you don't have to worry about sending SMB and RPC through the firewall from the site server to the Internet-based site systems for installation and copying packages.  You can secure these troublesome ports by using IPsec policies on each of the Internet-based site systems and the site server (and use RPCcfg.exe to narrow the dynamic port range for the second RPC connections), but this can end up being a lot of admin overhead - especially when your Internet-based site systems are distributed over multiple computers. 

The second advantage is that you can delay and control when information is passed from the child site to the parent, using the sender address properties.  This gives you a window in which to pull the plug if any of the servers in the perimeter network were compromised.

The disadvantage of this approach is that the site server is in the perimeter network (DMZ) and therefore potentially vulnerable to attack.  This could result in a denial of service or information disclosure.  However, if you can isolate the site before it sends information to the parent site, any damage will be limited to the child site only, and potentially the clients that are assigned to that site - rather than potentially affecting the whole hierarchy (all sites and all clients).  Note that this design requires that the Internet-based site does not have a primary site beneath it.

As with many designs that concern security, there are a number of pros and cons to consider.  If you're interested in this design, here's a step-by-step to create this IPsec policy on a member server running Windows Server 2003.  The steps are very similar for Windows Server 2008 and they can also be easily modified so that the IPsec policy is assigned through Active Directory Group Policy.

To Create a Local IPsec policy for Each of the Site Servers (Windows Server 2003)

1. Click Start, click Administrator Tools, click Local Security Policy, right-click IP Security Policies on Local Computer, and then click Create IP Security Policy.

2. In the IP Security Policy Wizard, and in the Welcome page, click Next.

3. In the IP Security Policy Name page, specify a name for the policy, such as "ConfigMgr Site-to-Site", and then click Next.

4. In the Requests for Secure Communication page, deselect Activate the default response rule if this is selected, and then click Next.

5. In the Completing the IP Security Policy Wizard page, ensure that Edit properties is selected, and then click Finish.

6. In the policy properties dialog box, in the Rules tab, click Add.

7. In the Welcome to the Create IP Security Rule Wizard page, click Next.

8. In the Tunnel Endpoint page, ensure the option This rule does not specify a tunnel is selected, and then click Next.

9. In the Network Type page, ensure that All network connections is selected, and then click Next.

10. In the IP Filter List dialog box, click Add.

11. In the second IP Filter List dialog box, type in a name, such as "ConfigMgr IP filter list". Ensure that Use Add Wizard is selected, and then click Add.

12. In the IP Filter Wizard, in the Welcome page, click Next.

13. In the IP Filter Description and Mirrored property page, ensure that the option Mirrored. Match packets with the exact opposite source and destination addresses is selected, and then click Next.

14. In the IP Traffic Source page, select My IP Address if not already selected, and then click Next.

15. In the IP Traffic Destination page, select A specific IP Address, type in the IP address of the other site server, and then click Next.

16. In the IP Protocol Type page, ensure that Any is selected, and then click Next.

17. In the Completing the IP Filter Wizard page, click Finish.

18. In the IP Filter List dialog box, click OK.

19. In the second IP filter List dialog box, select the IP filter list that you have just created ("ConfigMgr IP filter list"), and then click Next.

20. In the Filter Action dialog box, select Require Security, and then click Next.

21. In the Authentication Method page, select Use a certificate from this certification authority (CA), click Browse, select the CA that you are using for native mode, click OK, and then click Next.

22. In the Completing the Security Rule Wizard, click Finish.

23. In the policy properties dialog box, click OK.

24. In the Local Security Settings console, expand IP Security Policies on Local Computer if necessary, right-click the policy that you have just created ("ConfigMgr Site-to-Site"), and then click Assign.

Note:  Check the status of the policy after assigning.  If it is being overridden by IPsec policies by Active Directory, it will display "Policy is assigned, but it is being overridden by Active Directory-assigned policy."  If that's the case, it's time to check in with your AD admins and assign the required policy through Active Directory.

--Carol Bailey

This posting is provided "AS IS" with no warranties, and confers no rights.

Jason Lewis one of our team members has just posted a new screencast to his blog.  The topic is System Center Updates Publisher (SCUP) Installation.

System Center Updates Publisher is a stand-alone tool that enables independent software vendors or line-of-business application developers to import software update catalogs, create and modify software update definitions, export update definitions to catalogs, and publish software updates information to a configured update server such as System Center Configuration Manager or System Center Essentials.

The screencast can be found here: http://blogs.technet.com/jasonlewis/archive/2009/02/16/screencast-scup-installation.aspx

Enjoy!

-- Yvette O'Meally

This posting is provided "AS IS" with no warranties, and confers no rights.

[Today's post is provided by My Phuong Le]

Some users have encountered 32-bit limitations in monitoring System Center Configuration Manager with Operations Manager.  This post is intended to clear up confusion about what is currently supported and why.

By design, the OS operates in two distinct address spaces - 64-bit or 32-bit.  System Center Configuration Manager 2007 is a 32-bit application.  This is true for the RTM, SP1 and R2 releases.

If Configuration Manger 2007 RTM or SP1 is running on a 32-bit OS with the 32 bit Operations Manager 2007 agent

• All 32-bit applications can be monitored normally, including the OS and Configuration Manager 2007.

If Configuration Manager 2007 RTM or SP1 is running on a 64-bit OS, with the 64-bit Operations Manager 2007 agent

• You will be able to monitor 64-bit native applications.
• You will not be able to monitor Configuration Manager 2007. The counters will not be visible.
• The underlying x64 OS and x64 SQL instances are monitored.

If Configuration Manager 2007 RTM or SP1 is running on a 64-bit OS, with the 32-bit Operations Manager 2007 agent

• See Manageability Team Blog for details on how to use the 32-bit Operations Manager 2007 agent on a 64-bit OS.
• You will be able to monitor Configuration Manager 2007.
• You will not be able to monitor native 64-bit applications or the OS itself.
• You will lose some functionality with the Operations Manager 2007 agent.
• You can't automatically install, uninstall or upgrade the agent.
• You can't use your normal method to deploy agents.
• You can't use your normal method to patch agents.
• You can't use your normal method to repair agents.

We are not offering a 64-bit Configuration Manager 2007 Client.  However, we are making changes to allow the 32-bit application to work with both the 32-bit and 64-bit Operations Manager 2007 agent. 

To take advantage of the new functionality, you will need the following applications when they are released:

• System Center Operations Manager 2007 R2 or a System Center Operations Manager 2007 SP1 hotfix. This module change will allow Management Packs to query the 32-bit registry hive on a 64-bit Windows install to successfully perform discoveries, i.e. the "SMS" hive. This release is currently scheduled for the second quarter of calendar year 2009.
• System Center Configuration Manager 2007 Management Pack for Operations Manager 2007 R2. This is updated to take advantage of the new Operations Manager 2007 R2 discovery method. This release is currently scheduled for the third quarter of calendar year 2009.
• System Center Configuration Manager 2007 SP2 - Configuration Manager 2007 SP2 will have native 64-bit performance counters added. This release is currently scheduled for the third quarter of calendar year 2009.

- My Phuong Le

This posting is provided "AS IS" with no warranties, and confers no rights.

[Today's post is brought to you by Carol Bailey]

Have you tried to renew the existing site server signing certificate for a native mode site, and wondered how to do this without creating a new certificate?  This post provides a procedure to do this that is suitable for when the site server is on either Windows Server 2003 or Windows Server 2008, and your PKI uses Microsoft Certificate Services.

Disclaimer:  This procedure is external to Configuration Manager, so you will not find this information in the Configuration Manager product documentation.  However, we realize that PKI is often new to Configuration Manager admins, and aim to share our knowledge and experience to help you be more successful with the product.

You can use the same procedure to renew any certificate that's deployed through Certificate Services, but Group Policy auto-enrollment usually takes care of client certificate renewal automatically.  And the IIS site system certificates for server authentication can be easily renewed from the Certificates MMC, by right-clicking on the certificate and selecting All Tasks, and then either Renew Certificate with New Key (recommended), or Renew Certificate with Same Key.

However, there are 2 challenges for renewing the site server signing certificate:

• The Certificates MMC on Windows Server 2003 does not let you specify the Subject value, so you cannot renew the certificate with a new site code.
• The Certificates MMC is not designed for certificate templates that are configured for manual approval.

A note here about manual approval and why changing this to automatic approval in order to workaround the Certificates MMC design is not recommended.  Manual approval is recommended for the site server signing certificate because it is a "high value" certificate.  It's high value because it represents the key to the kingdom - your Configuration Manager hierarchy.  In comparison with the other certificates, if this certificate is compromised (requested by a compromised or rogue site server), the whole integrity of the hierarchy is in jeopardy.  One of the main differences between mixed mode and native mode (in addition to using PKI certificates instead of self-signed certificates) is that policy is signed by both the site server and the management point.  Even if the management point is compromised, clients are protected by checking this extra signature on their policies.  Policy that is fabricated on a compromised management point, even if the management point has a valid certificate, will be rejected by clients because the policy won't be signed by the site server signing certificate. 

You can use this same procedure to renew any certificate that's deployed with Certificate Services.  However, Group Policy auto-enrollment usually takes very efficient care of certificate renewal automatically.  And the IIS site system certificates for server authentication can be easily renewed from the Certificates MMC, by right-clicking on them and selecting All Tasks, and then either Renew Certificate with New Key (recommended), or Renew Certificate with Same Key.

How to Use CertReq to Renew the Site Server Signing Certificate

To adhere to the security best practice of manual approval for this particular certificate, renew the certificate by using the CertReq command line tool, and the certificate serial number.  To find the certificate serial number, double-click the certificate from the Certificates MMC, click the Details tab, and then note the value for Serial number.  When you specify the serial number with the command-line tools, you must remove the spaces in the string.

You will need to specify this number in the .inf file that you use with CertReq.exe, in the [NewRequest] section and with the option RenewalCert.  You will also need to specify MachineKeySet = True, or the renewal will actually create a new certificate in the User store rather than renewing the existing certificate in the Computer store.

This means that your .inf text file will look similar to this:

[NewRequest]
RenewalCert=237f66a4000000000011
MachineKeySet = True

It's as simple as that.  Then run through the standard CertReq commands for requesting, retrieving, and installing the certificate.  If you need step-by-step instructions because you're not familiar with CertReq, use the Windows Server 2008 CA step-by-step, section Deploying the Site Server Signing Certificate - only use the .inf file contents above instead of the .inf contents in the step-by-step. However, if you need only a quick reminder (and I often do!):

1. Certreq - new sitesigning.inf sitesigning.req
2. Certreq - submit sitesigning.req sitesigning.cer (select CA when prompted and note request ID number).
3. Check and issue the pending certificate request from the CA.
4. Certreq -retrieve <ID_number> sitesigning.cer (select CA when prompted)
5. Certreq -accept sitesigning.cer

In the Certificates MMC, view the certificate details again and the Valid from and Valid to values should now be updated.

Want to renew the certificate but with a new site code?  Add the Subject option to the .inf file, so that it looks similar to this before requesting the certificate:

[NewRequest]
Subject="CN = The site code of this site server is BCD"
RenewalCert=237f66a4000000000011
MachineKeySet = True

Want to renew the certificate with an existing key set?  Use my previous post to find the long string of numbers for the certificate's key container, using the Certutil command.  Then specify this string in the .inf file with the KeyContainer option, along with UseExistingKeySet = Yes so that it looks similar to this before requesting the certificate:

[NewRequest]
RenewalCert = 237f66a4000000000011
KeyContainer= b759e34928886fea1ec1bc7beacc5e80_016106cf-c351-4ab3-a3f1-7e56916dae0b
UseExistingKeySet = True
MachineKeySet = True

Want to renew the certificate when it’s expired?  You’re out of luck.  The CA will reject the request to renew an expired certificate and you will see a message similar to “Error Verifying Request Signature or Signing Certificate. A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file. 0x800b0101 (-2146762495).” This message is also displayed in the Failed Requests node of the issuing CA.  When the certificate has already expired, you must request a new certificate instead of renewing the existing certificate.

Using the Renewed Certificate with Configuration Manager

Even though you've renewed the existing certificate rather than replaced it, it still has a new serial number and a new certificate thumbprint.  This means that you must still specify the renewed site server signing certificate in the site properties, Site Mode tab.  When you've done the hard work of renewing the certificate, don't forget this last piece of the renewal process!  Remember to do it at a quiet time when it's OK that all the policies will be resigned.  Only if the certificate chains to a root CA certificate with a different key pair will you have to take additional configuration steps for the clients.  Otherwise, you're good to go.

For more information about configuring the Configuration Manager site for a new site server signing certificate, see Renewing or Changing the Site Server Signing Certificate.

- Carol Bailey

This posting is provided "AS IS" with no warranties, and confers no rights.

[Today's post is brought to you by Carol Bailey]

I'm going to share some information about an option on the Certificate Services advanced Web enrollment page, because I couldn't find it documented anywhere and it took me a long time to work it out.  However, even though I'm explaining how to use this option, I strongly recommend you never do unless your PKI admins insist.  Why?  Because it explains how to request a certificate using an existing key. It's the same option that you see in the Certificates MMC when you right-click a certificate and see Request Certificate with Same Key.  

Disclaimer:  The procedures in this post are external to Configuration Manager, so you will not find this information in the Configuration Manager product documentation.  However, we realize that PKI is often new to Configuration Manager admins, and aim to share our knowledge and experience to help you be more successful with the product.

It's always more secure to create a new key set rather than request a certificate with the same key.  I'm told that some applications might be configured to use a specific key, especially if you're using a hardware-based CSP - but this will not be case for the majority of customers.  However, if you do want to use an existing key for a new site server signing certificate, you're out of luck if you're expecting to do this with the Certificates MMC that ships with Windows Server 2003.  That's because this version of the Certificates MMC cannot support the Supply in the request option that's needed for the custom string in the certificate Subject.  So once again, Web enrollment comes to the rescue with the option Use existing key set.  Select this and a new field appears as shown in the picture: Container Name.

I hadn't come across this field before, because I had never created a certificate with an existing key.  The customer had no idea what to put here and I couldn't find any information about this field on the Internet or in my PKI books.  The Web page is clever enough to tell you when you enter an invalid value, but gives you no clue how to find the value that you need to specify for the key container - as you will see from the error message below when I tried supplying some educated guesses:

When you select Request Certificate with Same Key from the Certificates MMC, you don't have to supply this information - it's retrieved for you automatically.  But with Web enrollment, you have to find this information yourself and then specify it.  To do this, follow these steps:

1. Using the Certificates MMC, locate the site server signing certificate (or another certificate that's using the key you want to reuse), double-click it, click the Details tab, and then make a note of the serial number of the certificate.

2. On the computer that's installed this certificate, run the following command and send the output to a text file: certutil -store -v My <serial_number>

3. Open the text file and look for the long number after Key Container= and then copy this to the clipboard.

4. In the Web enrollment page, paste the long number into the Container Name field.

Example:

1. My site server signing certificate serial number is 11 54 a7 1d 00 00 00 00 00 07.

2. From a command prompt, I type in the following: certutil -store -v My 1154a71d000000000007 >output.txt

3. I open output.txt with Notepad and search for Container Name - in my case I find b759e34928886fea1ec1bc7beacc5e80_016106cf-c351-4ab3-a3f1-7e56916dae0b - as shown in the picture below.

4. I copy this string of numbers and paste them into the Container Name field in the Web enrollment page.

When the certificate request has gone through and the new certificate is installed, how do you check that it is actually using the same key?  Modify the previous procedure as follows:

1. Find the new serial number using the Certificates MMC again. If you supplied the same certificate details and are not sure which is the new certificate, use the Valid from and Valid to fields in the Details tab to identify the latest timestamps.

2. Run the same certutil command but with the new serial number, sending the output to a new file.

3. Open both text files and search for Container Name - they should have the same long number, showing that they're using the same key set.

Note that selecting the option to use an existing key set using the Web enrollment page does not renew an existing certificate - it creates a new certificate with an existing key.  So how do you renew an existing certificate for the site server signing certificate when it's on Windows Server 2003 and you can't use Web enrollment?  That's the subject of my next blog post: How to Renew the Site Server Signing Certificate (Microsoft Certificate Services).

- Carol Bailey

This posting is provided "AS IS" with no warranties, and confers no rights.

[Today's post is contributed by Carol Bailey]

A number of certificate deployment issues I see are down to timing issues.  Like other distributed systems with many moving parts, Microsoft Certificate Services often requires more time and patience to do its job than administrators are prepared to give it.  And yet this is a little odd, because SMS wasn't affectionately known as "Slow Moving Software" for nothing.  Seasoned SMS admins know that packages can take hours to install on all their distribution points, and that an urgently needed application might install in the next few minutes or hours. But tasked with deploying certificates and we suddenly become signed up members of the "I want it now" society.

I think a good solution to dealing with these potential timing issues is planning well in advance, and having the confidence to know that you've configured everything correctly - and a dollop of experience also doesn't go amiss.  When you don't have as much PKI experience under your belt as you do with SMS, what's the best strategy when it comes to deploying the native mode certificates? 

My first tip is to never practice on the production network when you're using enterprise CAs - it's a false economy.  It sounds obvious, but many people do this, thinking that they can easily uninstall the CA if necessary and when templates or certificates fail to show up they don't know whether it's down to misconfiguration or timing. 

Aim to never uninstall an enterprise CA (and some settings can only be configured at installation time) because it writes to Active Directory.  Your mileage may vary but I've had some bad experiences with computers trying to use an uninstalled CA that's hanging around in the background and had to clean up Active Directory manually.  If you have to uninstall an enterprise CA, be sure to first carefully read KB 889250 ("How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows 2000 Server").  Even the title gives you a hint that this is not in the same category as uninstalling IIS or other server roles - and that's before you start to wade your way through all the procedures.

Trying to diagnose a PKI problem that's due to an invisible CA is a big time waster, so don't chance it, and don't gift it to another consultant or support person so that they unknowingly inherit this scenario.  Instead, know exactly what settings and configuration your enterprise CA will need, then test, test, test on an isolated network until you can do it in your sleep with one hand behind your back and hopping up and down - and only then install for real on the production network.

After installing the enterprise CA(s), allow plenty of time for all computers in the forest to receive the associated certificates through group policy.  Although they will be installed pretty quickly for your locally connected computers, there will usually be some computers across slow links, currently turned off, and currently off the network.  These certificates are the foundation of your PKI solution and without them correctly installed on all the computers that need them, native mode will fail.  For example, native mode clients do not check that their own certificate chains to a trusted root CA, which means that they can present it to their management point before the certificate chain is installed.  However, if the same CA hierarchy is being used for the management point, the client also won't have the root CA to validate the management point's certificate (or the site server signing certificate), which means that communication will fail.

The same inherent delays apply when configuring certificate templates and deploying certificates.  You're less likely to see these delays on your isolated network because everything is well connected with fewer computers - but even then, you might experience a few timing issues.  A useful tip that was passed on to us was to use the "Certutil -pulse" command.  I'm told that this works even when "gpupdate /force" doesn't and certificates (and new templates) that were dragging their feet suddenly turn up.

During the testing phase, when you're reconfiguring certificate templates that you've already issued on the CA, it's not necessary to delete them and add them again to the CA after the change.  The changes will be picked up automatically, but the delete and add method does speed up the process through the new publication to Active Directory.

Deploying certificates through auto-enrollment is neat, but not instantaneous.  Even on a test network where I've had Active Directory and the CA on a single server with a couple of computers, it's taken a while for the certificates to install even after a round of rebooting. How long is a while?  Anything from five minutes to half an hour.  And on a production network, it can be hours - which is why it's important to be confident that the configuration steps are correct before you move them onto the production network. 

When auto-enrollment doesn't appear to work in the first few minutes on a production network, it's very natural to assume that something has gone wrong and start to fiddle - which is the worst thing you can do.  When you know that the configuration is correct (because it worked on the test network), it's time to step away from the computer.  I have a good example of this when I worked with a customer who was configuring a CA across a WAN link and couldn't get his client certificates to install through group policy.  We went through the certificate template configuration and group policy configuration, rebooted, and waited.  Nothing happened.  We chatted some more and waited a bit longer - still nothing happened.  I knew it was configured correctly because I had done it so many times before.  Eventually I convinced him to leave it alone and ring me in the morning if the certificates still weren't installed.  The following morning he didn't ring me, but I did get an email saying they had finally turned up. 

Because auto-enrollment for client certificates can take some time, it's a good idea to deploy these first on your production network - before the server certificates.  Having that extra time also helps to catch the few computers that were turned off because of vacations, or laptops that were off the intranet. 

The step-by-step guides for the native mode certificates in the Configuration Manager library don't start with the client certificates.  The order in these guides is the site server signing certificate first, followed by the Web server certificates, and then finally the client certificates.  The main reason why I decided on this order was because the step-by-step is a very long document, and it made more sense to have the certificate deployment in the order in which I thought most people would have problems.  The site server signing certificate with document signing capability and a unique string in the Subject was a puzzler even for experienced PKI admins, and without this certificate working, it's game over for native mode.  So I put this first in case that was the only information that was needed.  Deploying the server certificates was the next hardest, because the default Web server certificate template doesn't automatically populate the certificate Subject.  And finally, deploying client certificates was the easiest because you can use certificate templates with very little configuration.  I should also re-emphasize that the step-by-steps are specifically designed for a test network where the delays should be minimal.  So I still think that this is the right order for step-by-step guides, but in production I recommend you deploy them in reverse order for timing reasons.

Braindump complete, I'll try to summarize some of these tips and tricks:

• Certificate deployment using an enterprise CA- like Configuration Manager - has inherent latencies that should be expected and planned for.
• Practice installing a CA and deploying certificates on a test network - never practice on the production network.
• Aim to never uninstall an enterprise CA.
• Allow plenty of time for the root CA certificate and any subordinate CA certificates to trickle down to computers in the forest.
• Don't be surprised if newly created certificate templates and certificates deployed through auto-enrollment don't work immediately - but try "Certutil -pulse" to kick it up a notch.
• Having successful testing experience under your belt will give you the confidence to wait rather than assume a problem.
• When deploying the certificates for native mode, start with the client certificates first, then the Web server certificates, and finally the site server signing certificate - the reverse of the order in the step-by-step guides.

For my final thought about Certificate Services and timing, I'll quote a Chinese proverb:  Patience is power; with time and patience the mulberry becomes silk.  I hadn't really thought of a PKI deployment as being silk before, but it's an interesting analogy.

- Carol Bailey

This posting is provided "AS IS" with no warranties, and confers no rights.

[Today's post is contributed by Jeff Gilbert]

Because the Configuration Manager 2007 documentation library on the Web is updated on a regular basis, the Configuration Manager help file installed with the product can become out of date.  In an effort to keep the help files installed locally with the Configuration Manger console as close as possible to the documentation published online, the Configuration Manager 2007 Help File Update Wizard was developed by the Configuration Manager 2007 user assistance team. This wizard can update the help files associated with a Configuration Manager 2007 installation to the December 2008 version of the Configuration Manager 2007 documentation library. To use the wizard, simply install the .msi and then located the wizard's shortcut in your start menu. The installation file can be downloaded from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=71816b0f-de06-40e0-bce7-ad4b1e4377bb&displaylang=en

If a Configuration Manager console is installed on the computer that the wizard is started on, the existing help documentation can be updated to the December 2008 version of the Configuration Manager Documentation Library. If a Configuration Manager 2007 console is not installed on the computer that the wizard is started on, the December 2008 version of the Configuration Manager 2007 documentation library help file can be copied locally. In addition, options are available to run the help update wizard from the command line so that it can be deployed as a standard software distribution package to update remote Configuration Manager console help files.

Questions or comments about the Configuration Manager Help File Updater can be sent to: mailto:smsdocs@microsoft.com?subject=Configuration%20Manager%202007%20Documentation%20Library%20Update%20Wizard%20feedback.

I hope this helps (pun intended),

~Jeff

This posting is provided "AS IS" with no warranties, and confers no rights.