[Today's post is provided by Carol Bailey]

I've openly admitted that I don't find the command-line utility, Certreq.exe, the easiest of the Certificate Services methods to use when it comes to deploying certificates for Configuration Manager native mode.  But to some extent I made my peace with Certreq and started to recommend it when the later versions of Web enrollment no longer allowed installing certificates into the computer store.  I always recommend installing directly into the computer store rather than installing into the user store and then exporting the certificate - because apart from the extra admin overheads, this workaround requires that the private key is exportable, which is not advisable for security reasons.  Using Certreq.exe to request a certificate means that you can install directly into the computer store by using the parameter MachineKeySet = True.

Disclaimer:  The information in this blog post 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.

I'm passing on a couple of tips about the following Certreq errors that I know have puzzled some of our customers:

• The public key does not meet the minimum size required by the specified certificate template. 0x80094811 (-2146875375) Denied by Policy Module.
• The permissions on the certificate template do not allow the current user to enroll for this type of certificate. 0x80094012 (-2146877422) Denied by Policy Module.

Error: The public key does not meet the minimum size required by the specified certificate template

You are likely to see a key size error with Certreq when you request the site server signing certificate (or any other certificate) for a server running Windows Server 2003 and request the certificate from a CA running Windows Server 2008.  This is because the default key size for Windows Server 2003 is 1024, and for Windows Server 2008 it is 2048.  So when the certificate template defaults to using a minimum key size of 2048 and you try requesting the certificate with the default size of 1024, it's going to fail with the error shown in the following picture:

It's easy enough to correct this error.  Either change the Minimum key size value from 2048 to 1024 on the Request Handling tab of the certificate template properties, or request a certificate with the key size of 2048.  To tell Certreq to a request a certificate with the larger key size, add the line KeyLength=2048 to the inf file, within the [NewRequest] section.  For example, your .inf file for the site server signing certificate on a Windows Server 2003 computer might look like the following:

[NewRequest]

Subject = "CN=The site code of this site server is ABC"

MachineKeySet = True

KeyLength = 2048

[RequestAttributes]

CertificateTemplate = ConfigMgrSiteServerSigningCertificate

You won't see this key length error if the requesting computer is also running Windows Server 2008, because both use the same default key length.  This is why the KeyLength line isn't included in the step-by-step example deployment for a Windows Server 2008 CA, because the requesting computer in this example deployment is also running Windows Server 2008.  You could specify it, but there's no need to do so when the operating system versions match.

Error: The permissions on the certificate template do not allow the current user to enroll for this type of certificate

When you install certificates into the computer store and use auto-enrollment or manually request the certificate using the Certificates snap-in, the requesting computer account needs Read and Enroll permissions on the certificate template.  However, when you're using Certreq.exe to request certificates, even if they are computer certificates and use MachineKeySet = True, the requesting user needs Read and Enroll permissions on the certificate template.  When you use Certreq.exe, the computer permissions are not used at all.  This explains the rather perplexing error message you see with Certreq.exe on Windows Server 2008 (with a similar error on Windows Server 2003) when the computer has Read and Enroll permissions and you think the user permissions should be not used:

When you realize that Certreq operates in the user context only, this error is easily corrected.  If you will only ever request a certificate with this certificate template using Certreq.exe, specify user permissions only.  However, if you might also use this certificate template with other certificate installation methods, specify both user permissions and computer permissions.

More Information about Certreq

The following Certificate Services documentation has additional information and examples for using Certreq.exe:

• Certreq (Windows Server 2008)
• Appendix 3: Certreq.exe Syntax (Windows Server 2003)

--Carol Bailey

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

[Jeff Gilbert has provided today's post] 

The Volume Shadow Copy Service (VSS) is a Windows service that made its debut with Windows XP and Windows Server 2003. This service provides the ability to create a point in time image (shadow copy) of one or more volumes. These shadow copies can then be used to perform backup operations. Shadow copies are created very quickly in general because instead of backing up an entire volume file by file, VSS only needs to track changes to existing files. By tracking disk changes at the volume level, VSS is able to present a static snapshot of changed data to a backup process and then copy a point-in-time snapshot of those files to a backup destination even while the actual files are being written to.

The Configuration Manager 2007 backup process utilizes the VSS service, and associated components, to perform site backups. This is a good thing because using VSS means we only need to stop site services just long enough for the backup snapshot to be created. Generally, this is only a few seconds or minutes at most instead of the hours it took previously to create the backup snapshot in SMS 2003.

Of course, this new functionality comes with a bit of a price tag. VSS requires sufficient storage space to create and maintain shadow copies. By default the storage association (where VSS keeps the differences) is set to the same drive being shadow copied (self). Using the default storage association, with the source and backup destination on the same volume, causes VSS to shadow all changes to the volume while the snapshot is active, and also increases the disk churn while the backup files are being written out. This can lead to high disk I/O and disk space consumption during the backup process.  If too much space is used, then the snapshot creation, and subsequently the Configuration Manager site backup task, can fail.

To avoid that happening, it is recommended to change the VSS storage association to a different volume than the data being backed up whenever possible. So, the best practice is to set the storage association to another volume that has free space equivalent to 50% of the size of the data being backed up and also configure the Backup ConfigMgr Site Server maintenance task to save the backup files to another volume. For example, on a server with three volumes (C, D, and E) if Configuration Manager is installed on the C drive, you could configure the VSS shadow copy storage association for the C drive to use the D drive and then have the Configuration Manager backup task use the E drive for the final backup destination.

The vssadmin.exe command line utility is used to create or modify VSS storage associations. So staying with the three volume scenario I described earlier, to change the VSS storage association for the C drive to use the D drive, you use the Add ShadowStorage command like so (remember that the minimum size supported for the MaxSize value is 300MB and the size you use should be equal to at least 50% of the size of the data to be backed up):

Vssadmin Add ShadowStorage /For=C: /On=D: /MaxSize=30000MB

To view the newly created shadow copy storage association information, you use the List ShadowStorage command:

Vssadmin List ShadowStorage

If you've reviewed the size of the backup snapshot and discovered that you actually need more than the 30 GB you initially dedicated for the storage association, you can just resize it by using the aptly named, Resize ShadowStorage command:

Vssadmin Resize ShadowStorage /For=C: /On=D: Mazsize=50000MB

This would now give you 50 GB of dedicated space for the storage association.

If you then decide that you want to move the storage association because the D drive is filling up with data for some reason, you can use the Delete ShadowStorage command before recreating the shadow storage association on a different volume:

Vssadmin Delete ShadowStorage /For=C: /On=D:

In addition to viewing and changing VSS shadow storage asspociations, Vssadmin.exe can also be used to check the health of the Configuration Manager VSS backup components. The SMS Writer is used to backup site data and the SQL Server writer is used to backup the site database. To verify these components, the List Writers command is used:

Vssadmin List Writers

The output of that command will list the installed VSS writer components, their current state (hopefully ‘stable') and what their last error was (hopefully ‘No error').

I've given some examples of how you can use vssadmin, but for more information about the supported commands, you should check out the official reference here: http://technet.microsoft.com/en-us/library/cc754968.aspx.

If you are still curious about vssadmin commands, or what to know more about backing up and recovering Configuration Manager sites in general, head over to the Configuration Manager documentation library and read up about it at http://technet.microsoft.com/en-us/library/bb632545.aspx or the Backup and Recovery forum at http://social.technet.microsoft.com/Forums/en-US/configmgrbackup/threads/. If you are coming to MMS 2009, you can also sign up for my instructor-led lab: Backing up and Recovering ConfigMgr Sites (IY17)!

~Jeff Gilbert

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

[Today's post is provided by Carol Bailey]

Torsten Meringer (MVP) brought to my attention an interesting scenario that he ran into when his duplicated configuration baseline disappeared from his reports, and his original configuration baseline seemed to come back from the dead after deleting it. 

Torsten had created the original configuration data on a test network, exported it and imported it to his main Configuration Manager hierarchy.  The imported configuration items and baselines imported fine, and they were locked, because they weren't created at the site.  He wanted the ability to change them if necessary, so he did the following:

1. Duplicated the configuration items
2. Duplicated the configuration baseline
3. Edited the duplicated configuration baseline to replace the original configuration items with the duplicated configuration items.
4. Deleted the original configuration items and configuration baselines (no further need of them).

This was exactly the right thing to do so that he could then edit the configuration items and configuration baseline if required.  However, when he looked at his desired configuration management reports, he couldn't find his newly duplicated configuration baseline.  But almost by accident, he did find a report for what looked like his original configuration baseline - which he thought he had deleted.  So what was going on?

I did some testing of my own and discovered that the duplicated configuration baseline reverts to the original baseline name.  Although you are more likely to run into this scenario when using imported configuration data that you then duplicate for editing, it actually has nothing to do with the original configuration baseline being imported - the same set of circumstances will happen with any duplicated configuration baseline.  But to help explain what happened, let's walk through what happens if you import, duplicate, and then edit a configuration baseline:

1. Import a configuration baseline called Original Baseline.  It displays in the results pane with a lock symbol to denote that you can't edit it because it wasn't created at that site, as shown in the follow picture.

2. Right-click the imported baseline, click Duplicate, and then type in your own choice of name in the Item name dialog box - for example, type New Baseline. Click OK.
3. Edit the duplicated baseline by adding one or more configuration items to it that you have created (or duplicated) at the site, or by deleting one or more of the configuration items displayed.
4. In the results pane of the Configuration Manager console, you can still see the duplicated baseline, displayed with the new name that you specified (New Baseline).  But press F5 to refresh, and you will see that the name reverts to the original name of Original Baseline.  You can tell which baseline is which because your duplicated configuration baseline doesn't have the lock symbol and the CI Version and Content Version is incremented by one, as shown in the following picture.

Without further intervention, the duplicated configuration baseline will continue to use the reverted name.  For example: "Original Baseline" will be displayed in the Configurations tab on the client when it is downloaded for compliance evaluation, and the reports will display results for "Original Baseline" instead of "New Baseline".

Thanks to Richard Xia's investigation from the product group, he pointed out a key factor that I missed at step 2 above - probably because I was so focused on editing my configuration baseline for step 3.  I should have paid more attention to the Properties pane beneath the results pane.  The properties for New Baseline actually display the old name of Original Baseline, as shown in the following picture:

When I saw this mismatch in the console, that's when I remembered .... I had already documented this as a known troubleshooting issue - in Problems Editing Configuration Data in the Configuration Manager Console :

Duplicated Configuration Items Display Original Name

When you create a duplicate configuration item, it might display the original name rather than the new name in the Configuration Manager console in the following circumstances:

• When the configuration item is first created, the duplicate name displays correctly in the results pane, but the properties pane and the properties of the configuration item display the original configuration item name.
• When the duplicate configuration item is then edited for one of its properties except the display name and then saved, the duplicate name displays the original name in the results pane and in the properties when subsequently opened.

Solution

After creating a duplicate configuration item, edit it and change the duplicate configuration item display name to the required value. The duplicate configuration item name will then display correctly in all places.

I think what threw me off track, was that the problem we investigated was for a configuration baseline, rather than a configuration item, and I didn't associate it immediately with a display issue. In Torsten's case, he didn't notice the console display disparity but discovered it because he couldn't find the configuration baseline in the reports.  This was when I realized this would be good to blog, because you might come across this in different ways - as missing report data, or as missing compliance results from clients, or as a console display problem.

I'll update the troubleshooting entry in the documentation so that it refers to configuration baselines as well as configuration items, and make it clearer that it's not just a display problem.

Fortunately, once you realize what's happening, it's a really easy fix.

Solution to the name reverting behavior:

After the initial duplication and naming of the configuration baseline, re-type your choice of name when you edit it (step 3 above).  This time it will "stick".

--Carol Bailey

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

[Today's post comes to us from Carol Bailey]

When you reassign a Configuration Manager client from one hierarchy to another, the client already has a trusted root key from its original hierarchy. Reassigning the client to a new hierarchy means that the client will also be assigned to a new management point. When both the trusted root key and the management point changes, by default, the client will become unmanaged. In this scenario, the Advanced Client component will send the status message ID 10822 to the site, with a description that it encountered a certificate for a management point that it could not verify. Additionally, the client log file Locationservices.log will display the following error: The trusted key, mp certificate and the mp machine have changed on server. The client cannot validate the authentication information.

If you want to just reassign a client to a new hierarchy without reinstalling it, you have two options:

• Pre-provision the client with the trusted root key for the new hierarchy, using one of the procedures in the topic How to Pre-Provision the Trusted Root Key on Clients. This is the recommend method because it is more secure.
• Remove the trusted root key from client, using the procedure in the topic How to Remove the Trusted Root Key.

Alternatively, when you reassign the client, you can also reinstall it by using a method that includes the trusted root key.  For example:

• Client push, which automatically includes the trusted root key without your having to specify it.
• CCMSetup and include the option SMSPublicRootKey or SMSROOTKEYPATH. For more information, see About Configuration Manager Client Installation Properties.

--Carol Bailey

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

[Today's post is provided by Brian Huneycutt]

There has been some confusion lately over a little known feature in Configuration Manager 2007: the ability to automatically apply hotfixes to the client during initial install by creating a ClientPatch folder on the site server. 

As it turns out, this little known feature was little known for a reason - it was not fully tested for use with Configuration Manager 2007.  As a result, it is not supported.

In this context, "not supported" means that if you reported problems with the use of the ClientPatch folder directly - or problems as a result of its use - we would not change the product code to resolve those.

In the event you have already deployed your clients and patched them in this manner but have no known issues, chances are there's nothing to worry about. 

The specific issue uncovered so far is that if certain command line properties were specified (such as FSP or SMSSLP) they may not be honored when the patch is applied.  There could be other issues that we are not aware of yet, but that one is apparent quickly if you are in that state.

Use of the ClientPatch folder was initially referenced in a Knowledge Base article, followed by an entry on the SMS and MOM supportability blog. At the time of this writing those references have been removed, but the details were cross posted to Rod Trent's blog here.  (Rod was kind enough to update his post with key points from this blog entry).

An option to achieve a result similar to the ClientPatch folder is to use the PATCH= command line parameter.  This has been tested, and is noted in KB article 907423 (note this article applies to both SMS 2003 and Configuration Manager 2007).

Thank you all for your understanding,

-- Brian Huneycutt

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

[Today's post is provided by Nathan Barnett. This information was originally published on the TechNet Configuration Manager Documentation forum, and its popularity has resulted in also posting it here for wider visibility.]

Issue

When the Configuration Manager 2007 operating system deployment feature is used to deploy a Vista SP1 image, a new boot configuration data (BCD) store is created using the BCD template.  Configuration Manager 2007 explicitly creates the Boot Manger and Operating System objects from the BCD template, but allows the Resume object to be created implicitly by Windows Vista when it goes through mini-setup.  Vista SP1 correctly generates the Resume object during mini-setup but the associated Resume settings objects are not generated. Because there are no Resume settings objects, hibernate functionality does not work.

Solution

To resolve this issue, run the following script on Vista SP1 computers deployed using Configuration Manager 2007 operating system deployment to create the missing Resume settings objects.  To run the script type the following at a command prompt:

cscript.exe /nologo scriptname.vbs

This script can be deployed in two scenarios:

• Run as part of the Vista SP1 deployment: Incorporate the script into the operating system deployment task sequence as a Run Command Line step once the new operating system is installed.
• Run after Vista SP installation: Incorporate the script into a software distribution package/program and then advertise it to existing computers previously deployed with Vista SP1 using Configuration Manager 2007 SP1.

Code Snippet

' Connect to WMI
set oLocator = CreateObject( "WbemScripting.SWbemLocator" )
set oRootWMI = oLocator.ConnectServer( ".", "root\wmi" )
oRootWMI.Security_.ImpersonationLevel = 3
' Connect to BCD
set oBCD = GetObject( "winmgmts:{impersonationlevel=Impersonate,(Backup,Restore)}!root/wmi:BcdStore")
if Err.number <> 0 then
    WScript.Echo "ERROR: Failed to connect to BCD"
    WScript.Quit(1)
end if
' Open the system store
if not oBCD.OpenStore( "", oBcdStore ) then
    WScript.Echo "ERROR: Failed to open the system BCD store"
    WScript.Quit(1)
end if
set oBCD = nothing
const ResumeLoaderSettingsBcdObject = "{1afa9c49-16ab-4a5c-901b-212802da9460}"
const GlobalSettingsBcdObject = "{7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}"
' Check to see if the {resumeloadersettings} object already exists
if oBcdStore.OpenObject( ResumeLoaderSettingsBcdObject, objWBM ) then
    WScript.Echo "Resume Loader Settings object already exists in BCD"
    WScript.Echo "No changes have been made to the system"
    WScript.Quit(1)
end if
WScript.Echo "Creating new {resumeloadersettings} object..."
if not oBcdStore.CreateObject( ResumeLoaderSettingsBcdObject, &h20200004, oResumeSettings) then
    WScript.Echo "ERROR: Failed to create the BCD object"
end if
if not oResumeSettings.SetObjectListElement(&h14000006, Array(GlobalSettingsBcdObject )) then
    WScript.Echo "ERROR: Failed to set the Inherit element"
end if
WScript.Echo "Finished updating BCD"
 

--Nathan Barnett

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