Yesterday the Configuration Manager product team announced the release of the public beta for Configuration Manager Service Pack 2 and it’s available for download for all customers.  Service Pack 2 for Configuration Manager 2007 delivers new platform support for Windows 7 client, Windows Vista SP2, Windows Server 2008 R2 and Windows Server 2008 SP2.  In addition, Service Pack 2 delivers continued innovation with Intel vPro technology, support for Branch Cache enabled environments, and continued development for 64 bit architectures. 

For more information and a download link see http://blogs.technet.com/configmgrteam/archive/2009/06/17/announcement-configuration-manager-2007-service-pack-2-public-beta.aspx.

J.C. Hornbeck | Manageability Knowledge Engineer

Yvette O’Meally just posted a note about the release of some updated hotfixes for Server 2008 SP2 and Windows Vista SP2.  If you’re trying to install some hotfixes on either of these platforms and got "This KB###### is for a different hardware platform” errors then you’ll want to check this out:

The Configuration Manager Sustained Engineering team has re-released a number of Configuration Manager SP1 hotfixes due to a problem with the hotfix installer's ability to detect Windows Server 2008 SP2 and Windows Vista SP2.  This will cause Configuration Manager 2007 SP1 hotfixes to fail to install on those operating systems even though they are applicable.

To continue reading see Announcement: Some Configuration Manager SP1 hotfixes have been re-released for Windows Server 2008 SP2 and Windows Vista SP2 on the Configuration Manager product team blog.

J.C. Hornbeck | Manageability Knowledge Engineer

Here’s a tip sent to me by a buddy here at Microsoft.  Apparently we don’t document this anywhere so I thought for now we could at least put it out on the blog.

Summary: This article describes how to determine which version of System Center Configuration Manager 2007 is installed on your server, and explains the differences between the versions.

Determining the version:

1) Open the ConfigMgr admin Console.

2) Navigate to Site Database, then Site Management.

3) Right-click on your site and select Properties.

4) The version will be listed on the properties screen.

ConfigMgr RTM - 4.00.5931.0000

ConfigMgr SP1 - 4.00.6221.1000
The “R2 installed” field will state “No”.

ConfigMgr R2 - 4.00.6221.1000
The “R2 installed” field will state “Yes”.

References:

What's New in Configuration Manager 2007 R2

What's New in Configuration Manager 2007 SP1

Configuration Manager 2007 downloads

J.C. Hornbeck | Manageability Knowledge Engineer

We had one new Knowledge Base article published last week, this one documenting the hotfixes and updates that are contained in Microsoft System Center Configuration Manager 2007 Service Pack 2 (SP2):

KB971348 - List of hotfixes and updates that are contained in System Center Configuration Manager 2007 Service Pack 2

Enjoy!

J.C. Hornbeck | Manageability Knowledge Engineer

With the release of the Windows 7 and Windows Server 2008 R2 operating systems, new capabilities and usage scenarios are emerging for system management. Economic, regulatory, green IT, and security issues continue to be the challenges organizations face. In this webcast, we provide a technical update and overview for Microsoft System Center Configuration Manager 2007. We focus on Service Pack 2 and R3 enhancements, market capabilities, and describe our near-term release road map.

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032428200&EventCategory=4&culture=en-US&CountryCode=US

J.C. Hornbeck | Manageability Knowledge Engineer

The updated Configuration Manager 2007 SP2 Management Pack adds support for monitoring Configuration Manager 2007 SP2 in a 64-bit environment with Operations Manager 2007 R2 or Operations Manager 2007 SP1 with hotfix (KB971541) installed. This enables the Configuration Manager 2007 SP2 Management Pack to work with either the 32-bit or the 64-bit Operations Manager 2007 agent. Except for the 64-bit support, the other features and guidance for Configuration Manager 2007 Management Packs remain intact.

Note: As of today, KB971541 is not yet available.  This update should be available within the next few days.  When it becomes available it should be found here.

For all the details and to download the updated MP see http://www.microsoft.com/downloads/details.aspx?FamilyID=a8443173-46c2-4581-b3b8-ce67160f627b&displaylang=en

J.C. Hornbeck | Manageability Knowledge Engineer

Looks like the Configuration Manager product team made a couple announcements regarding supported configurations over on their blog.  You can read the details yourself but here's the long and short of it:

Windows Storage Server 2008 is now supported on Configuration Manager 2007 SP1 and SP2

System Center Configuration Manager 2007 SP1 and SP2 now support the Windows Storage Server 2008 operating systems for client installation.  Site system roles of a standard distribution point and a branch distribution point are supported.  Installations of the administrator console or other site system roles are not supported.

No software updates are required.

Windows Remote Management (WinRM) 2.0 is now supported on Configuration Manager 2007 SP1 and SP2

System Center Configuration Manager 2007 SP1 and SP2 now support installing Windows Remote Management 2.0 on site systems running the out of band service point role.

No software updates are required.

The original post can be found here.

Enjoy!

J.C. Hornbeck | Manageability Knowledge Engineer

When you upgrade a computer that is running the App-V 4.5 client to System Center Configuration Manager 2007 SP2, it may break all the File Type Associations (FTA's) for the virtualized applications.  This can occur because the SP2 installer updates the following key in the registry as part of the Configuration Manager 2007 Service Pack 2 upgrade:

HKEY_CLASSES_ROOT\SCCM.VAppLauncher\shell\Open\command

But it does not update the other two keys that App-V uses:

HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\Client\UserInterface - DDELaunchMSICommand and LaunchMSICommand

This causes all the FTAs that were created through a published APP-V application to break, until a time when a new application is published to the machine which triggers the client to update the key itself.  At this point the FTAs for the newly published app would work but the FTAs for all other already existing apps would still be broken.

Resolution

If you publish an application that has FTAs to a client then it will force an update of the previously mentioned key in the registry.  The problem with this is that the application only reads that registry key on startup so the newly published application will be fixed but none of the others.  To fix all of the other applications you would need to restart the App-V client machine after publishing a new app.

Instead of re-publishing an app, I have created the following script that will update those registry keys without requiring you to re-publish an application. Note that you will need to restart the computer after running the script for the fix to take effect.  This can be done manually or automated via a script or management system, etc.

Here is the code of the Visual Basic script:

==========================

On Error Resume Next

'Script Name: App-V_Client_Fix.vbs
'Script Author: BRShaw
'Script Purpose: Fix the FTAs for App-V clients that have been upgraded via a Service Pack
'Script Creation Date: 12/08/2009
'Script Modified Date: 12/08/2009
'Script Version: 1.0
'Revision History

'Ver Date      Person                  Description
'-------------------------------------------------------------------------------------
'1.0    12/08/2009   Brian Shaw                 Created Script.

If UCase(Right(WScript.FullName, 11)) = "WSCRIPT.EXE" Then
  wscript.echo "This script must be run under CScript." _
    & VbCrLf & "You can set this by running: CScript //H:CScript" _
    & VbCrLf & "at the command line."
  WScript.Quit
End If

''******************************************************************************
'* Global Variables
''******************************************************************************
Dim strOutFile, strDir
Dim strAppLauncherValue, strAppLKeyPath, strAppLValueName, strAppLValue
Dim strUIValue, strUIKeyPath, strUIValueName, strUserInterfaceValue
Dim objTextFile, objWMIService, objFile
Dim arrAppLValues
Debug_On = False
Const DeleteReadOnly = TRUE
Const HKEY_CURRENT_USER = &H80000001
Const HKEY_LOCAL_MACHINE = &H80000002
Const ForReading = 1
Const OverwriteExisting = True
Const ForAppending = 8
StrComputer = "."
set oShell = createobject("wscript.shell")
strDir = oShell.currentdirectory
strOutFile = strDir & "\App-V_Fix_Output.txt"
strAppLauncherValue = "None"
strUserInterfaceValue = "None"

''******************************************************************************
'* Create a Text file for output of the script
''******************************************************************************
Set objFSOFileDelete = CreateObject("Scripting.FileSystemObject")
'If the output file exists befor then delete it.
If objFSOFileDelete.FileExists (strOutFile) Then
objFSOFileDelete.DeleteFile(strOutFile)
End If
'Create the Text file to write standard out to.
Set objFSOFileWrite = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSOFileWrite.OpenTextFile (strOutFile, ForAppending, TRUE)
objTextFile.WriteLine(Now)

''******************************************************************************
'* Determine What the App launcher setting is
''******************************************************************************
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
strAppLKeyPath = "SOFTWARE\Classes\SCCM.VAppLauncher\shell\Open\command"
strAppLValueName = "command"
oReg.GetMultiStringValue HKEY_LOCAL_MACHINE,strAppLKeyPath, strAppLValueName,arrAppLValues

If instr(arrAppLValues(0), "VirtualApp") > 0 Then
  strTemp = Trim(arrAppLValues(0))
  strAppLauncherValue = strTemp
End If

If Debug_On Then
  objTextFile.WriteLine("This is the value of the first Array key: " & arrAppLValues(0))
  objTextFile.WriteLine("This is the value of the App Launcher key pulled from the registry: " & strTemp)
  objTextFile.WriteLine("This is the value of the App Launcher key we are using: " & strAppLauncherValue)
End If

If strAppLauncherValue = "None" Then
    objTextFile.WriteLine("The value did not exist in the regsitry!!")
End If

''******************************************************************************
'* Determine What the UserInterface Setting is
''******************************************************************************
strUIKeyPath = "SOFTWARE\Microsoft\SoftGrid\4.5\Client\UserInterface"
strUIDDEValueName = "DDELaunchMSICommand"
oReg.GetStringValue HKEY_LOCAL_MACHINE,strUIKeyPath,strUIDDEValueName,strUIValue

If instr(strUIValue, "VirtualApp") > 0 Then
  strUserInterfaceValue = strUIValue
End If

If Debug_On Then
  objTextFile.WriteLine("This is the value of the User Interface key pulled from the registry: " & strUIValue)
  objTextFile.WriteLine("This is the value of the User Interface key we are using: " & strUserInterfaceValue)
End If

If strUserIValue = "None" Then
    objTextFile.WriteLine("The value did not exist in the regsitry!!")
End If

''******************************************************************************
'* Set the new value and write it back to the registry
''******************************************************************************

If instr(strUserInterfaceValue, strAppLauncherValue) > 0 Then
  objTextFile.WriteLine("The registry has alreday been updated with the correct App Launcher Command!")
  objTextFile.WriteLine("Here is the value of the App Launcher key: " & strAppLauncherValue)
  objTextFile.WriteLine("Here is the value of the User Interface key: " & strUserInterfaceValue)
Else
  Dim intStringLength, intStartPlace, intNumCharFromRight
  Dim strRightSide, strNewValue
  'Get the length of the user interface key
  intStringLength = Len(strUserInterfaceValue)
  'Find the starting place to cut the string
  intStartPlace = InStr(strUserInterfaceValue, "launch")
  'Find how many characters to pull from the right side, had to subtract the 3 places back from the search string we used
  intNumCharFromRight = intStringLength - (intStartPlace - 3)
  strRightSide = Right(strUserInterfaceValue, intNumCharFromRight)
  If Debug_On Then
    objTextFile.WriteLine("This is the length of the string: " & intStringLength)
    objTextFile.WriteLine("This is the Starting location we are using: " & intStartPlace)
    objTextFile.WriteLine("This is the Number of Characters from the right side we are pulling: " & intNumCharFromRight)
    objTextFile.WriteLine("This is the string we pulled back:  " & strRightSide)
  End If
  'we are now going to add the strings together to get the completed new string
  strNewValue = strAppLauncherValue & strRightSide
  If Debug_On Then
    objTextFile.WriteLine("This is the strings added together: " & strNewValue)
  End If
  'Update the registry key with the new values
  oReg.SetStringValue HKEY_LOCAL_MACHINE,strUIKeyPath,strUIDDEValueName,strNewValue
  strUIValueName = "LaunchMSICommand"
  oReg.SetStringValue HKEY_LOCAL_MACHINE,strUIKeyPath,strUIValueName,strNewValue
  objTextFile.WriteLine("The User Interface option has been updated with this value: " & strNewValue)
End If

==========================

I have tested the script and it does work, just don't forget to restart the client machine.  Just copy all text between the "===" lines and then put in a file called App-V_Client_Fix.vbs and execute it with cscript like this:

cscript App-V_Client_Fix.vbs

The output of the file will be contained in a file called App-V_Fix_Output.txt

Note:  This script is intended as an example only and will not fix all situations.  Its intended use is to fix the Launch MSI commands that do not get updated during an upgrade of SCCM.  It will not fix your FTA issues that might arise by disabling the SCCM App-V integration.

Hope this helps,

Brian Shaw | Senior Support Escalation Engineer

This document was created to help in troubleshooting Configuration Manager Service Pack 2 (SP2) install failures. This document is not entirely specific to Service Pack 2 and can apply to Service Pack 1 installs, upgrades from SMS 2003 to SCCM, and future service pack or Configuration Manager versions that rely on .mof file compilations, SQL SPNS, provider DLLs, etc.

Contents:

Section 1 Pre-Upgrade Best Practices

Section 2 General Troubleshooting

Section 3 List of Known Issues and Solutions:

A: SPN issues with SQL

B: Time Skew between remote SQL and Site Server

C: Re-Registering relevant files / errors attempting to re-register needed files.

D. Deleting Temp Files, setting Temp variables.

E. Searching for a "bad" custom or customized report

F. Checking for pre-existing duplicate reports that are new to SCCM SP2

G. Upgrade fails due to registry setting.

H. Site System does not have rights to remote SQL System or Clustered SQL Nodes

______________________________

Section 1 Pre-Upgrade Best Practices

It is important to note that some of the problems outlined below can leave your Configuration Manager or SMS installation in an unusable state (i.e. Admin Console will not launch and connect) this is because the upgraded files have already been copied to the bin\I386 directory of your SCCM installation. In some case setup may rollback successfully and in others you *may* be able to reinitiate upgrade over the top of a failed installation however in others you may have to fully restore to your previous state; SCCM RTM, SP1, SMS 2003, etc, to begin troubleshooting.

Always insure you have a complete current and full SMS or Configuration Manager backup (performed when SMS services are disabled, all directories, SQL DB, registry settings, etc..) before upgrading your product. Always utilize the testdbupgrade setup switch on a copy(!) of the site database command to insure your database can be upgraded without error. Testdbupgrade can help you insure you are ok to upgrade however you cannot upgrade a database after you have run testdbupgrade against it.

How to Test the Site Database Upgrade Process: http://technet.microsoft.com/en-us/library/bb693648.aspx

______________________________

Section 2 General Troubleshooting

Most problems we have seen thus far have been after file copy, around step 4; registering the SMS provider, and compiling .mof files. It takes setup about 10-15 minutes to get to this step. This document primarily focuses on issues of this type.

There are several things to consider in the scenario of  .MOF comp failures. First off you should not have to keep going through SP2 setup after testing solutions. Instead try to manually compile the .mof that fails. In most (not all) cases you will get an error doing this as well. Once you have implemented a solution and can manually compile the .mof file that setup was failing on, it may be safe to assume that SCCM SP2 setup can again be run and may pass this stage.

Things to look at (not necessarily in this order):

• Relevant log files: C:\ConfigMgrSetup.log, %ConfigMgrInstallDir%\Logs\Smsprov.log and SMSProv.lo_, %Windir%\System32\Wbem\Mofcomp.log
• Verify that DCOM and Windows Management Instrumentation (WMI) is enabled
• Take a SQL Profiler (yes, because we are going through the Provider we do look in SQL. Specifically at the SMS_Reports table)
• Double check WMI permissions
• Check Security Rights in the SMS Admin console for the user that is executing the mofcomp command against smsrprt.mof
• Verify permissions on the extnprov.dll file
• We write .tmp files to various locations during compile. Run a Filemon.

As stated above, the files to compile during setup should be able to compile outside of setup. it is likely that you will not be able to complete setup successfully until you can compile smsrprt.mof (or whatever mof file is failing to compile) manually successfully from a command prompt.

If you try to manually compile the SMSrprt.mof and it fails you usually get the following error:

E:\SMS\bin\i386>mofcomp smsrprt.mof
Microsoft (R) 32-bit MOF Compiler Version 5.2.3790.3959
Copyright (c) Microsoft Corp. 1997-2001. All rights reserved.
Parsing MOF file: smsrprt.mof
MOF file has been successfully parsed
Storing data in the repository...
An error occurred while processing item X defined on lines X - X in file smsrprt.mof:
Compiler returned error 0x80041001

It may be worth noting that 0x80041001 = generic failure, so this is not helpful other than to let you know that you have not resolved your issue as of yet since you are not able to manually compile this file.

______________________________

Section 3 List of Known Issues and Solutions

The most common issue we see with SP2 upgrades is a failed to compile .mof error around the time that SP2 is trying to upgrade the SMS provider component:

<12-09-2009 15:17:37> CompileMOFFile: Starting to compile MOF C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\smsRprt.mof
<12-09-2009 15:18:11> CompileMOFFile: Failed to compile MOF C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\smsRprt.mof, error -1
<12-09-2009 15:18:11> Setup cannot compile MOF file C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\smsRprt.mof.  Do you want to continue?
<12-09-2009 15:18:11> Setup failed to install SMS Provider.  For more information about this error, see Microsoft Knowledge Base at <http://microsoft.com> or contact Microsoft Technical Support for further assistance.

A. SPN issues with SQL:

The first thing you will want to check is that the SQL SPNs are registered correct in Active Directory. In a nutshell 2 things can go wrong here:

1. Duplicate SPNs for SQL
2. SQL is running under a Domain User account and the SPNs have not been created manually.

Resolution: Use the setspn tool.  You can find it online if it's not installed.

1. setspn -l nameofcomputerrunningsql > C:\ComputerSPN.txt
2. setspn -l domain\accountSQLisRunningUnder > C:\SQLaccountSPN.txt
3. setspn -x > C:\duplicates.txt

So if your SQL server is called sqlcomputer and the account SQL is running under is called SQLAccount number 1 and 2 above would be :

1. setspn -l sqlcomputer > C:\ComputerSPN.txt
2. setspn -l domain\sqlaccount C:\SQLaccountSPN.txt

Use the txt files above to insure SQL SPNs are registered correctly. You should have the entries listed as follows under the domain account running SQL or the actual SQL Servers computer account:

MSSQLSvc/sqlcomputer.domain.com:1433
MSSQLSvc/sqlcomputer:1433

If you are running a SQL cluster insure the same for all physical nodes and the virtual instance name.
To add a FQDN and NETBIOS SPN for SQL use the following syntax:

setspn -a MSSQLSvc/SQLcomputer.domain.com:1433 Domain\SQLaccount

and

setspn -a MSSQLSvc/SQLcomputer:1433 Domain\SQLaccount

To delete a duplicate SPN use the -d switch:

SETSPN -D MSSQLSvc/SQLcomputer:1433 Domain\SQLcomputer

You can also easily view SPNs (Service Principal Names) using ADSIEDIT.msc (install from a Windows  Server CD, \Support Tools\Suptools.msi) right click the computer or user account object and view attributes, scroll down to ServicePrincipalName.

Note: SQL creates its OWN SPN for the computer account when SQL is running under the Local System account. Having more then one SPNs registered under different accounts with the same machine name as the one SQL is running on will cause these problems as well.

Switches for SetSPN:

-R = reset HOST ServicePrincipalName
Usage: setspn -R computername

-A = add arbitrary SPN
Usage: setspn -A SPN computername

-S = add arbitrary SPN after verifying no duplicates exist
Usage: setspn -S SPN computername

-D = delete arbitrary SPN
Usage: setspn -D SPN computername

-L = list registered SPNs
Usage: setspn [-L] computername

-Q = query for existence of SPN
Usage: setspn -Q SPN

-X = search for duplicate SPNs
Usage: setspn -X

B. Time Skew between remote SQL and Site Server:

If SQL is remote from the site server you are trying to upgrade insure there is not a time skew between the two machines. A default Windows Active Directory domain has a Kerberos policy to allow no more than a 5 minute time difference between machines for successful Kerberos authentication.

C. Re-Registering relevant files:

In some case re-registering a couple of files has resolved SP2 install issues.

Configmgrsetup.log:

<11-14-2008 23:20:11> CompileMOFFile: Starting to compile MOF
E:\SMS\bin\i386\smsRprt.mof
<11-14-2008 23:20:12> CompileMOFFile: Failed to compile MOF
E:\SMS\bin\i386\smsRprt.mof, error –2147217407

If you try to manually compile smsRprt.mof you get the following error:

E:\SMS\bin\i386>mofcomp smsrprt.mof
Microsoft (R) 32-bit MOF Compiler Version 5.2.3790.3959
Copyright (c) Microsoft Corp. 1997-2001. All rights reserved.
Parsing MOF file: smsrprt.mof
MOF file has been successfully parsed
Storing data in the repository...
An error occurred while processing item 1 defined on lines 7 - 32 in file
smsrprt.mof:
Error Number: 0x80041013, Facility: WMI
Description: Provider load failure
Compiler returned error 0x80041001

From the command prompt type the following:

• Change directory to \Program Files\Microsoft Configuration Manager\Bin\I386\
• Run regsvr32 smsprov.dll
• Run regsvr32 extnprov.dll

Similar to the above issue during the fourth step of SCCM setup you may see the following pop up error
message:

Fatal Error Setup Failed to install SMS Provider

The ConfigMgrSetup.log may read as follows:

TaskSequenceProvider.mof comp failure

Once this occurs the SCCM services will not start and the site server is not in a usable state.

Additionally, after you quit setup you are unable to manually mofcomp smsprov.mof or TaskSequenceProvider.mof. The following error occurs:

Provider Load Failure

If you try to manually regsvr32 smsprov.dll you receive the following:

LoadLibrary("D:\SMS\Bin\I386\smsprov.dll") failed - The specified module could not
be found.

The error is valid although this is *also* the default regsvr32 error when a path to a file you are trying to register cannot be found or the file you are trying to register does not exist in the defined path.

The solution is to use Depends.exe (Dependency Walker) against the file that wont re-register SMSprov.dll (Note: not all files are "registerable"!) http://www.dependencywalker.com/

In our case it was missing MSVCR80.dll and it wanted this file in the \Microsoft Configuration Manager\Bin\I386
directory. Copy the missing files that depends identifies to the \Bin\I386 directory.

Once placing the file there we were able to manually register SMSProv.dll and Extnprov.dll and complete setup.

D. Deleting Temp Files, Setting Temp Environment Variables:

The following error appeared in the ConfigMgrSetup.log:

<02-19-2008 12:52:42> VC redist is being installed from C:\DOCUME~1\customer\Local
Settings\Temp\vcredist_x86.exe.

***You may get an MSIEXEC help screen popup although no error will show up in the log.***

<02-19-2008 13:08:23> CompileMOFFile: Starting to compile MOF C:\Program
Files\Microsoft Configuration Manager\bin\i386\smsRprt.mof
<02-19-2008 13:08:24> CompileMOFFile: Failed to compile MOF C:\Program
Files\Microsoft Configuration Manager\bin\i386\smsRprt.mof, error -2147217407
<02-19-2008 13:08:26> Setup cannot compile MOF file C:\Program Files\Microsoft
Configuration Manager\bin\i386\smsRprt.mof. Do you want to continue?

The .mof's referenced in the ConfigMgrSetup.log above could not be compiled manually using mofcomp.exe.

Change the TEMP folder location from %USERPROFILE%\Local Settings\Temp to C:\TEMP and deleting all temp files fixed this issue. An alternate solution and better explanation for this behavior is as follows:

In one instance, the issue was caused when the admin logged onto the server BEFORE 8.3 support was turned off and therefore his user profile was created in this manner, including the path to the temp directory.  Configuration Manager does not support 8.3 and in fact, the pre-req checker will determine if 8.3 support is enabled. In this instance, however, it was off by the time the setup was run and it does NOT check the logged on user for how their profile was created.

Log on with a user who has a profile created AFTER 8.3 support was disabled or delete the current users profile and have them log back on to re-create a new profile in the proper format and run setup again

E. Searching for a bad custom or duplicate report: Look in the C:\ConfigMgrSetup.log for something like this:

<12-27-2009 14:02:36> ***SqlError: [42S01][2714][Microsoft][ODBC SQL Server Driver][SQL Server]There is already an object named 'ExistingRights_Setup' in the database.
<12-27-2009 14:03:04> CompileMOFFile: Failed to compile MOF F:\Program Files\Microsoft Configuration Manager\bin\i386\smsRprt.mof, error -2147217407

And a corresponding entry in the SMSprov.log:

[3338][Sun 12/27/2009 14:03:03]:ERROR> SQL command failed: update Report set Category = 'Software Distribution - Packages', Comment = 'Displays all packages at a site.', DrillThroughReportID = 127,

DrillThroughURL = null, GraphCaption = '', GraphType = null, GraphXCol = 1, GraphYCol = 2, MachineDetail = 0, MachineSource = 0, Name = 'All packages', RefreshInterval = 0, ReportGUID = '{54AB50FF-A9E8-4116

-8D56-AB10B6CD66A0}', StatusMessageDetailSource = 0, UnicodeData = 0, XColLabel = '', YColLabel = ''  where ReportID = 132

***Note above that the report called "All Packages" is referenced***

e:\nts_sms_fre\sms\siteserver\sdk_provider\smsprov\sspclassbase.cpp(841) : SQL command failed: 
SQL Error: [23000][2627][Microsoft][ODBC SQL Server Driver][SQL Server]Violation of UNIQUE KEY constraint 'Report_AK2'. Cannot insert duplicate key in object 'dbo.Report'.
SQL command failed:  [23000][2627][Microsoft][ODBC SQL Server Driver][SQL Server]Violation of UNIQUE KEY constraint 'Report_AK2'. Cannot insert duplicate key in object 'dbo.Report'.

To resolve this issue we looked at the "All Packages" report, this report is included in a default install of SCCM Sp1 and SCCM SP2. However in this customers case it was noted that the report itself had been somewhat modified. To resolve this issue we deleted this report after which, we were able to compile the smsrprt.mof manually and thus SCCM SP2 install succeeded. After the install SCCM SP2 did recreate this report with the default queries. An alternate resolution may have been to simply modify the customized query in this report back to the SCCM SP1 defaults. It is not known why the report was not able to be upgraded as that troubleshooting path was not pursued.

F. Checking for pre-existing duplicate reports that are new to SCCM SP2: In a different case that was very similar to Item E, another issue was discovered. The customer had created a custom report in SCCM SP1 called “Computers that do not meet the minimum system requirements for Windows 7”. This report does not exist in SP1 however SCCM SP2 tries to create this very same report as part of its default install.

The customer was seeing this message in ConfigMgrSetup.log:

<12-09-2009 15:17:37> CompileMOFFile: Starting to compile MOF C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\smsRprt.mof
<12-09-2009 15:18:11> CompileMOFFile: Failed to compile MOF C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\smsRprt.mof, error -1
<12-09-2009 15:18:11> Setup cannot compile MOF file C:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\smsRprt.mof.  Do you want to continue?

In the SMSProv.log there was a message similar to the following:

Violation of UNIQUE KEY constraint 'Report_AK2'. Cannot insert duplicate key in object 'dbo.Report'.

Report names can in fact be the same as long as their conditions and queries are different. For example create a new report and call it “Computers that do not meet the minimum system requirements for Windows 7”  for the category type select Asset Intelligence. This report can be created without error. However if you clone an existing report and try to name it the same you get a failure in the console.

"A report with this name and category already exists.  Change the Name of this report to create a unique combination."

As with item E above, the resolution is to delete the pre-existing custom report and let SP2 recreate this report for you. A few other reports that do not exist in SCCM SP1 but are created in SCCM Sp2 to look out for are:

• “Computers that meet the recommended system requirements for Windows 7”
• “Computers that do not meet the minimum system requirements for Windows 7”
• "Windows 7 Upgrade Assessment - Hardware summary for all systems in a collection"

Note:Likely there are others as well. If you feel you have this issue compare SCCM SP2 Reports with SCCM SP1 Reports.

G. Upgrade fails due to registry setting:

In the ConfigMgrSetup.LOG:

<01-14-2009 16:50:22> CompileMOFFile: Compiled MOF D:\SMS\bin\i386\smsprov.mof
<01-14-2009 16:50:22> CompileMOFFile: Starting to compile MOF
D:\SMS\bin\i386\smsRprt.mof
<01-14-2009 17:06:12> CompileMOFFile: Failed to compile MOF
D:\SMS\bin\i386\smsRprt.mof, error -2147217407
<01-14-2009 17:06:12> Setup cannot compile MOF file D:\SMS\bin\i386\smsRprt.mof.

In the MofComp.LOG file:

(Wed Jan 14 16:50:23 2009.1023203) : Storing data in the repository...
(Wed Jan 14 17:06:12 2009.1971531) : An error occurred while processing item 1
defined on lines 7 - 32 in file D:\SMS\bin\i386\smsRprt.mof:
(Wed Jan 14 17:06:12 2009.1971546) : Error Number: 0x800706be, Facility: Win32
Description: The remote procedure call failed.

Cause: This can occur if the following registry value is set:

HLKM\Software\Microsoft\SMS\Providers
SQL Cache Logging =1

Resolution: To resolve this issue, set SQL Cache Logging=0

Note: SQl Cache Logging should be enabled only for troubleshooting purposes and should not be left "on".

For more information see SMS: How to Enable SQL Cache Logging in the Systems Management Server Provider
http://support.microsoft.com/kb/295040

H. Site System does not have rights to remote SQL System or Clustered SQL Nodes:

ConfigMgrSetup.log:

<05-19-2008 15:10:45> CompileMOFFile: Starting to compile MOF D:\Program
Files\Microsoft Configuration Manager\bin\i386\smsRprt.mof
<05-19-2008 15:11:26> CompileMOFFile: Failed to compile MOF D:\Program
Files\Microsoft Configuration Manager\bin\i386\smsRprt.mof, error -1
<05-19-2008 15:11:26> Setup cannot compile MOF file D:\Program Files\Microsoft
Configuration Manager\bin\i386\smsRprt.mof. Do you want to continue?

SMSPROV.log showed a log in failure for the computer account of the site server.  Check the rights for the Clustered SQL instance per http://technet.microsoft.com/en-us/library/bb680513.aspx

In this case we found that the computer account for the site server was not a member of the local admin group on either node. Adding the site server computer account to the local administrators group on both nodes and installation proceeded to a successful conclusion.

Note: A special thanks goes to to those who helped in the creation of this troubleshooter: Jason Adams, Ryan Anderson, Jeevan Bisht, Manish Raval, Steve Hornaday and Jason Schroeder.

Buz Brodin | Senior Support Escalation Engineer

I recently ran into this issue a couple days ago and didn't see a whole lot documented on it so I thought I would do a quick write up here.  If you're trying to upgrade some of your site servers to SP2 and run into an issue, this should get you going again pretty easily.

Note: This article describes making changes to the primary site database.  Before making changes in SQL Management Studio to the database, make sure to create a backup of your ConfigMgr 2007 Primary Site/Database. The process in this post has not been officially tested and is posted as is with no guarantee. This solution did work for me and it should also work for you, just make sure to back up your Primary site/database to be safe.

Issue

ConfigMgr2007 SP2 Setup on some Secondary sites failed due to insufficient disk space. Once we freed up enough disk space, we needed to get setup for SP2 restarted, preferably without having to copy the source files to the Secondary Site server and manually upgrading.  Since the setup failed to even start due to disk space issues on the Secondary Site server, it got stuck in an Upgrade status and did not resume setup automatically even after freeing up the disk space on the server.

Resolution

We found that manually copying the ConfigMgr SP2 source files to the server and running setup worked to get the Secondary Site upgraded, but if there are a lot of servers with the issue this can become quite time consuming.  Since we did not want to have to perform this manual process on each server where disk space was already an issue, we devised the following solution:

Using SQL Management Studio at the ConfigMgr 2007 Primary Site database, we opened the dbo.Sites table and modified the Secondary Sites Status column from 5 to 1.

The Sites table in the Primary Site database will have entries for each site including the Secondary sites.  In the database there is a Status column where the current status will be defined as 1, 2, 3, 4, or 5 :

• SITE_STATUS_ACTIVE 1 Site is active & normal
• SITE_STATUS_PENDING 2 Being installed
• SITE_STATUS_FAILED 3 Failed install
• SITE_STATUS_DELETED 4 Delete has been initiated
• SITE_STATUS_UPGRADE 5 Upgrade in progress

Based on the above information, we changed the status back to 1 for the sites that failed , and then started another upgrade from the ConfigMgr 2007 Admin Console.  This allowed us to re-trigger the SP2 upgrade without having to copy the files locally to each server and running setup manually.

Clifton Hughes | Senior System Center Support Engineer

After upgrading to SCCM 2007 SP2, AD discovery methods will fail to bind across external trusts. When the failure occurs, the ADSysDis.log will contain entries similar to this:

ERROR: Failed to bind to AD Object LDAP://DC02-140-52S.LITWARE.COM/CN=COMPUTERS, error=An operations error occurred.~~ -- Extended Error --- LDAP Provider : 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece.

ERROR: Failed to enumerate directory objects in AD container LDAP://DC02-140-52S.LITWARE.COM/CN=COMPUTERS

STATMSG: ID=5204 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_AD_SYSTEM_DISCOVERY_AGENT" SYS=SMS4-120-52S SITE=2P4 PID=1340 TID=308 GMTDATE=Thu Dec 17 18:31:10.528 2009 ISTR0="LDAP://DC02-140-52S.LITWARE.COM/CN=COMPUTERS" ISTR1="An operations error occurred.~~ -- Extended Error --- LDAP Provider : 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0

The failure occurs because of a change made in Service Pack 2 which makes the product more secure by requiring authentication for AD binds. As discovery is performed by the site server System account, authentication on the network requires Kerberos which is not supported across external trusts.

You can use one of the following methods to work around this new behavior:

- Use Windows 2003 or higher forest trusts instead of external trusts, as Kerberos is supported across them.

or

- Install a primary site server in the trusted domain to perform discovery there. This server can leverage an address configured with a user name and password, which works with NTLM, to forward the data to the original site server in the trusting domain.

Keith Thornley | Senior Support Escalation Engineer

When attempting to deploy Windows Server 2008 x64 SP2 (KB948465) as a Software Update via System Center Configuration Manager, the update may not be offered as applicable to some Windows Server 2008 64-bit machines.

Cause

When you are running an x64-based version of Windows Vista or of Windows Server 2008 on a computer that has multiple Intel x64 processors of a certain kind, or has an Intel x64 multi-core processor, certain known issues were encountered when applying SP2 so detection logic was added that blocks Service Pack 2 on these machines.

Resolution

For computers that meet this description, you need to have update KB973879 installed. This detail is noted in the following Knowledge Base article:

KB948343 - Windows Vista and Windows Server 2008 service packs are not available for installation through Windows Update

"Computers that have certain multiple processors need to have update 973879 installed for Service Pack 2 for Windows Vista and for Windows Server 2008 to be offered

973879 (http://support.microsoft.com/kb/973879/ ) You receive a "Stop 0x0000003E" error message when you try to install Windows Vista Service Pack 2 or Windows Server 2008 Service Pack 2 on a computer that has certain multiple processors"

Some users have noticed an additional issue when attempting to install KB973879. In these cases, the installation fails with, “The update does not apply to your system.” 

This can occur if Microsoft Security Update KB971486 is already installed on the same machine.  We are working to release a new version of KB973879 with updated detection logic to allow it to be installable when KB971486 is installed but in the interim we have the following workaround:

1. Remove KB971486
2. Install KB973879
3. Configure a Software Update deployment for the client.
4. After SP2 installs, re-install KB971486.

Note: A special thanks to Mike Johnson for documenting this issue.

Hope this helps,

J.C. Hornbeck | System Center Knowledge Engineer

Consider the following scenario:

• You install the Japanese version of the System Center Configuration Manager 2007 Service Pack 2 (SP2) client.
• You open Configuration Manager in Control Panel.
• You click the Configurations tab and then click the View Report menu to view the Compliance Evaluation report.

In this scenario, the report is displayed in English instead of in Japanese.

For more details on the issue and to download the hotfix that resolves it, see the following new Knowledge Base article:

KB978759 - The Compliance Evaluation report is not localized correctly on the Japanese version of the System Center Configuration Manager 2007 SP2 client

J.C. Hornbeck | System Center Knowledge Engineer

Suppose you want to use the USMT 4 feature of hardlinking in a System Center Configuration Manager 2007 Task Sequence, but you notice that the "Capture User State"/"Capture User Files and Settings" and "Restore User State"/"Restore User Files and Settings" tasks do not have any options to perform a local capture with hardlinking.  What's up with that?

Well what's going on is that USMT 4, which introduced hardlinking, shipped after ConfigMgr 2007 so the hardlinking option was not available in ConfigMgr 2007. However, USMT 4 support was added in ConfigMgr 2007 SP2, and via the OSDMigrateAdditionalCaptureOptions and OSDMigrateAdditionalRestoreOptions variables, a hardlink user migration can be accomplished in a ConfigMgr 2007 SP2 Task Sequence.

Out of the box, ConfigMgr 2007 SP2 only supports USMT 4 online captures, or captures that take place while in the full Windows OS. ConfigMgr 2007 SP2 does not support USMT 4 offline captures, or captures that take place while in WinPE. Offline captures are possible using the UDI feature of MDT 2010 Update 1 when it is integrated with ConfigMgr 2007 SP2.

With that said, there are several ways that a USMT 4 hardlink migration can be accomplished in a ConfigMgr 2007 Task Sequence, including:

1. Create a new ConfigMgr 2007 Task Sequence that supports USMT 4 hardlinking.
2. Modify an existing ConfigMgr 2007 Task Sequence that have the "Capture User State" and "Restore User State" tasks to support USMT 4 hardlinking.

Since USMT 4 support was not added until SP2 of ConfigMgr 2007, SP2 of ConfigMgr 2007 is required for hardlinking.

USMT 4 is supported in the following refresh scenarios:

• Windows XP --> Windows Vista
• Windows XP --> Windows 7
• Windows Vista --> Windows Vista
• Windows Vista --> Windows 7
• Windows 7 --> Windows 7

USMT 4 is not supported for Windows XP --> Windows XP scenarios.

The first step is to ensure that the USMT 4 package is created:

Create the USMT 4 Package

When ConfigMgr 2007 SP2 is installed on the site server, the Windows Automated Installation Kit 2.0 (WAIK 2.0) is automatically installed. USMT 4 is part of WAIK 2.0 and its binaries can be found within the WAIK 2.0 installation folder.

1. In the ConfigMgr 2007 Admin console on the site server, navigate to the "Computer Management" --> "Software Distribution" --> "Packages" node.
2. Right click on the "Packages" node and select "New" --> "Package".
3. In the "General" window, fill out the appropriate fields. The name of the package should describe it as the USMT 4 package. Click on the "Next >" button.
4. In the "Date Source" window:
   • Check the option "This package contains source files"
   • Click on the "Set..." button under "Source directory".
     • Click on the option "Local drive on site server"
     • Click on the "Browse..." button under "Source directory: "
     • Navigate to and select C:\Program Files\Windows AIK\Tools\USMT folder and click on the "OK" button. Make sure to select the root of the USMT folder. DO NOT directly select either the amd64 or x86 folders. When running, the Task Sequence will automatically choose the appropriate binaries.
   • Click on the "OK" button.
   • Click on the "Next >" button.
5. In the "Data Access" window, click on the "Next >" button.
6. In the "Distribution Settings" window, click on the "Next >" button.
7. In the "Reporting" window, click on the "Next >" button.
8. In the "Security" window, click on the "Next >" button.
9. In the "Summary" window, click on the "Next >" button.
10. In the "Wizard Complete" window, click on the "Close" button.
11. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Software Distribution" --> "Packages" node and find the newly created USMT 4 package.
12. Expand the USMT 4 package and then right click on "Distribution Points" and select "New Distribution Points".
13. Go through the "New Distribution Points Wizard" and make sure that the USMT 4 package is placed on some Distribution Points.

Notes:

• It is not required to create a Program as part of the USMT 4 package.
• In Step 5, if the WAIK 2.0 is installed on a different drive or directory, make sure to adjust the path C:\Program Files\Windows AIK\Tools\USMT accordingly.
• It is recommended that the above steps be taken in a ConfigMgr 2007 console running on the site server where the WAIK 2.0 is installed. However, the above steps can be taken in a ConfigMgr 2007 admin console that is not running on the site server. In Step 5 , instead of selecting the option "Local drive on site server", select the option "Network path (UNC name)" and browse to a network share that has the WAIK 2.0 installed or the USMT 4 binary source files.
• Please remember that the USMT 4 source files should contain BOTH the amd64 and x86 directories. The package should point to the root of the USMT 4 directory. It should NOT point directly to either the amd64 and x86 directories.

After creating the USMT 4 package, select the method below to enable USMT 4 hardlinking in a Task Sequence.

Method 1: Create a new ConfigMgr 2007 Task Sequence that supports USMT 4 hardlinking

1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
2. Right click on the "Task Sequences" node and choose "New" --> "Task Sequence".
3. In the "Create a New Task Sequence" window, select the option "Install an existing image package" and click on the "Next >" button.
4. In the "Task Sequence Information" window:
   • Next to "Task Sequence name:" text box, give the Task Sequence the desired name.
   • Click on the "Browse..." button next to "Boot Image:" and choose an appropriate Boot Image.
   • Click on the "Next >" button.
5. In the "Install the Windows Operating System" window:
   • Click on the "Browse..." button next to "Image package:" and select the Operating System Image that is desired to be deployed.
   • Next to the "Image:" drop down box, make sure the desired image is selected.
   • UNCHECK the option "Partition and format the target computer before installing the operating system".
   • If desired, enter the product key next to the "Product Key:" text box.  If using a KMS activation server, this field should be left blank when deploying Windows Vista or Windows 7.
   • If desired, select the option "Always use the same administrator password" and specify the password in the "Password:" and "Confirm password:" text boxes.
   • Click on the "Next >" button.
6. In the "Configure the Network" window, select "Join a domain" and fill out the appropriate fields. Click on the "Next >" button.
7. In the "Install the ConfigMgr client" window, click on the "Browse" button and choose a package that contains the ConfigMgr 2007 SP2 install files. Make sure that the package is an SP2 installer of the ConfigMgr 2007 client. Selecting a package that contains either the RTM or SP1 client install files will cause the "Restore User State" task to fail since clients that are not SP2 do not support USMT 4. Click on the "Next >" button.
8. In the "Configure State Migration" window:
   • Click on the "Browse..." button next to the "USMT Package:" field. Select the USMT 4 package and then click on the "OK" button.
   • Select the option "Save user settings locally". If this option is grayed out, the option "Partition and format the target computer before installing the operating system" was not unchecked in Step 5.
   • If desired, leave the options "Capture network settings" and "Capture Microsoft Windows settings" checked.
   • Click on the "Next >" button.
9. In the "Include Updates in Image" window, select whether or not to install updates during the Task Sequence, and then click on the "Next >" button.
10. In the "Install Software Packages" window, add any packages that are desired to be installed during the Task Sequence, and then click on the "Next >" button.
11. In the "Summary" window, click on the "Next >" button.
12. In the "Wizard Complete" window, click on the "Close" button.
13. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
14. Right click on the newly created Task Sequence and choose "Edit".
15. Click on the "Set Local State Location" task. Next to the "Value:" text field, change it from %_SMSTSUserStatePath% to %SystemDrive%\UserState.
16. Make sure that the "Set Local State Location" task is still selected and go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task in after the "Set Local State Location" and before "Capture User Files and Settings" tasks.
17. In the newly created "Set Task Sequence Variable Task":
    • Next to the "Name:" text box, enter in:
      Set USMT Additional Capture Options
      
    • Next to the "Task Sequence Variable:" text box, enter in:
      OSDMigrateAdditionalCaptureOptions
      
    • Next to the "Value:" text box, enter in:
      /nocompress /hardlink
      
18. Click on the "Capture User Files and Settings" task to select it:
    • Check the option "Enable verbose logging"
    • Click on the "Options" tab and then uncheck the option "Continue on error".
19. Click on the "Restore User Files and Settings" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task after the "Restore User Files and Settings" group and before the "Restore User Files and Settings" task.
20. In the newly created "Set Task Sequence Variable Task":
    • Next to the "Name: " text box, enter in:
      Set USMT Additional Restore Options
      
    • Next to the "Task Sequence Variable:" text box, enter in:
      OSDMigrateAdditionalRestoreOptions
    • Next to the "Value:" text box, enter in:
      /nocompress /hardlink
      
21. Click on the "Restore User Files and Settings" task to select it and then click on the option "Enable verbose logging".
22. Click on the "OK" or "Apply" button to save the task sequence.

Please make sure to look at the notes section at the end of this post for detailed explanations on some of the above actions.

Method 2: Modify an existing ConfigMgr 2007 Task Sequence that has the "Capture User State" and "Restore User State" tasks in it

If a ConfigMgr 2007 Task Sequence that was used with USMT 3 or USMT 4 exists and was setup for either network capture with a State Migration Point (SMP) or for local capture on the hard drive without hardlinking, it can be modified to support USMT 4 local capture with hard linking.

The below instructions assume that there is already a "Capture User State"/"Capture User Files and Settings" and "Restore User State"/"Restore User Files and Settings" tasks in the appropriate spots in the Task Sequence. If these tasks do no already exist in the Task Sequence, it is recommended to create a new Task Sequence using the method detailed above.

The below instructions are also not valid for a ConfigMgr 2007 Task Sequence that was created using the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard. Please see the section "More Information" for additional information regarding Task Sequences created using the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard:

1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
2. Right click on the affected Task Sequence and choose "Edit".
3. Find any "Request State Store"/"Request User State Store" and "Release State Store"/"Release User State Storage" tasks and disable them. They can be disabled by clicking on the individual tasks, clicking on the "Options" tab, and then clicking on the option "Disable this step". If none of these tasks exist in the Task Sequence, continue to Step 4.
4. Find any "Format and Partition Disk"/"Partition Disk"/"Partition Disk 0" tasks and disable them. They can be disabled by clicking on the individual tasks, clicking on the "Options" tab, and then clicking on the option "Disable this step". If none of these tasks exist in the Task Sequence, continue to Step 5.
5. If a task "Set Local State Location" already exists before the "Capture User State"/"Capture User Files and Settings" task, skip to Step 6. Otherwise, click on the "Capture User State"/"Capture User Files and Settings" task to select it and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task before the "Capture User State"/"Capture User Files and Settings" task.
6. In the newly created "Set Task Sequence Variable Task":
   • Next to the "Name:" text box, enter in:
     Set Local State Location
     
   • Next to the "Task Sequence Variable:" text box, enter in
     OSDStateStorePath
     
   • Next to the "Value:" text box, enter in:
     %SystemDrive%\UserState
     If there was already a "Set Task Sequence Variable Task" task in the Task Sequence that sets the OSDStateStorePath variable, make sure that it is configured to the above value.
7. Click on the "Capture User State"/"Capture User Files and Settings" task to select it and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task before the "Capture User State"/"Capture User Files and Settings" task and after the "Set Local State Location".
8. In the newly created "Set Task Sequence Variable Task":
   • Next to the "Name:" text box, enter in:
     Set USMT Additional Capture Options
     
   • Next to the "Task Sequence Variable:" text box, enter in:
     OSDMigrateAdditionalCaptureOptions
     
   • Next to the "Value:" text box, enter in:
     /nocompress /hardlink
     If there was already a "Set Task Sequence Variable Task" in the Task Sequence that defined the variable OSDMigrateAdditionalCaptureOptions with some options, such as /ue, then add the additional options /nocompress /hardlink in the "Value:" text box after the options that already exist. Make sure that there is a space between each option.
9. Click on the "Capture User Files and Settings"/"Capture User State" task to select it:
   • Ensure that the package under "User state migration tool package:"  is a USMT 4 package.
   • Check the option "Enable verbose logging".
   • Click on the "Options" tab and then uncheck the option "Continue on error".
10. Click on the "Setup Windows and ConfigMgr" task. Ensure that the package selected next to the "Package" field is a package that installs the SP2 version of the ConfigMgr 2007 client. RTM and SP1 versions of the client will not work with USMT 4.
11. Click on the "Restore User State"/"Restore User Files and Settings" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task before the "Restore User State"/"Restore User Files and Settings" task.
12. In the newly created "Set Task Sequence Variable Task":
    • Next to the "Name: " text box, enter in:
      Set USMT Additional Restore Options
      
    • Next to the "Task Sequence Variable:" text box, enter in:
      OSDMigrateAdditionalRestoreOptions
      
    • Next to the "Value:" text box, enter in:
      /nocompress /hardlink
      If there was already a "Set Task Sequence Variable Task" in the Task Sequence that defined the variable OSDMigrateAdditionalRestoreOptions with some options, such as /lac, then add the additional options /nocompress /hardlink in the "Value:" text box after the options that already exist. Make sure that there is a space between each option.
13. Click on the "Restore User Files and Settings"/"Restore User State" task:
    • Ensure that the package under "User state migration tool package:"  is a USMT 4 package.
    • Check the option "Enable verbose logging".
14. Click on the "OK" or "Apply" button to save the task sequence.

Notes on the two above methods:

• A "Format and Partition Disk" task is not desired in the above Task Sequences. If a format and partition of the disk occurred, it would wipe all data on the drive, including the State Store, and the captured data would be lost. Instead, to erase content off of the drive in preparation to install the new Windows OS, during the "Apply Operating System Image"/"Apply Operating System" task, a recursive delete of all files and directories occurs on the drive minus a few protected folders.

The protected folders that are not deleted include the Task Sequence cache folder and the State Store folder. The Task Sequence cache folder path is stored in the variables _SMSTSMDataPath , _SMSTSClientCache, and _SMSTSNewClientCachePathToCleanup and usually resolves to the path C:\_SMSTaskSequence. The State Store path is stored in the variable OSDStateStorePath. The protected folders that will not be wiped are stored in the variable _SMSTSProtectedPaths.

In the SMSTS.log you will see the recursive delete and wipe process logged as something similar to the following:

Wiping C:\                                                                                               ApplyOperatingSystem
Set "C:\_SMSTaskSequence" to not be wiped                                             ApplyOperatingSystem
Set "%OSDStateStorePath%" to not be wiped                                             ApplyOperatingSystem
Set "%_SMSTSClientCache%" to not be wiped                                            ApplyOperatingSystem
Set "%_SMSTSNewClientCachePathToCleanup%" to not be wiped                ApplyOperatingSystem
Skipping C:\_SMSTaskSequence for wipe                                                   ApplyOperatingSystem
Calculating expected free space.                                                                ApplyOperatingSystem
Reporting deletion progress.                                                                      ApplyOperatingSystem
Successfully wiped C:\                                                                              ApplyOperatingSystem

• In Step 15 (Method 1) and Step 6 (Method 2), the State Store path location is changed from %_SMSTSUserStatePath% to %SystemDrive%\UserState. The _SMSTSUserStatePath variable normally resolves to the path C:\_SMSTaskSequence\UserState. The C:\_SMSTaskSequence folder is the Task Sequence cache folder. This is done to fix several issues that can be caused by saving the State Store in the Task Sequence cache folder. These problems include:
  1. Whether or not a Task Sequence succeeded, the Task Sequence usually exits cleanly. When the Task Sequence exists cleanly, it deletes the Task Sequence cache folder of C:\_SMSTaskSequence. This can be a problem if the Task Sequence fails for whatever reason before the captured user data is restored.
     If the Task Sequence fails but exists cleanly before the user data is restored, then the cache folder of C:\_SMSTaskSequence is deleted, which will cause the C:\_SMSTaskSequence\UserState user State Store folder located within the C:\_SMSTaskSequence folder to also be deleted. The captured data will then be deleted and lost before it can be restored.
     If instead the State Store is specified to be a folder outside of the Task Sequence cache folder, such as C:\UserState, when the Task Sequence exists cleanly, it will not automatically delete the State Store since it is no longer within the Task Sequence cache folder. The Task Sequence cache folder will still be deleted, but the State Store will not. In case of Task Sequence failures before user data is restored, user data can still be restored from the State Store using manual methods.
     See KB958808 for additional information:
     User data from the USMT may be deleted unexpectedly by the task sequence engine during the operating system deployment process in System Center Configuration Manager 2007 SP1
     http://support.microsoft.com/kb/958808
     
     Note: KB958808 does not have to be installed in ConfigMgr 2007 SP2 as this hotfix is already included as part of SP2.
  2. Given the following scenario on a PC:
     1) PC has two (or multiple) drives or partitions
     2) User profiles and Windows are located on the first drive or partition (assume drive letter C:)
     3) Second drive or partition has more available free space than the first (assume drive letter D:)
     then the Task Sequence cache folder will probably be created on the second drive/partition (D:).
     In these scenarios the variable _SMSTSUserStatePath would resolve to the path D:\_SMSTaskSequence\UserState. This is a problem when using USMT 4 hardlinking because the hardlink store has to be on the same drive/partition as Windows and the user profiles. In the above scenario, Windows and the user profiles would be on C:, but the State Store would be created on D:. USMT 4 will actually capture the data in this scenario and not cause any errors, but the captured data will be invalid and it will not be able to be properly restored.
     By making sure that we save the State Store to the drive that contains Windows and user profiles via the variable SystemDrive, we make sure that this problem does not occur.
  3. There are known scenarios when going from a Windows OS with UAC off to a Windows OS with UAC on that will cause permissions not to be set properly on the State Store if the State Store is located within the Task Sequence cache folder. In these scenarios, user data is restored successfully, but the user will receive an "Access Denied" error message when trying to access their files. Saving the State Store outside of the Task Sequence cache folder will resolve the problem.
• Even though in Step 15 (Method 1) and Step 6 (Method 2) it is recommended that the State Store be saved to a location outside of the Task Sequence cache folder so that it is not automatically deleted, it is still advisable to delete the State Store at some point after the Task Sequence has completed and the user state has been verified that it has been restored successfully. This can be done properly via the usmtutils.exe utility included with USMT 4. To properly remove the State Store, run the command:

usmtutils.exe /rd <Path_to_State_Store>

where <Path_to_State_Store> is the path as specified in the OSDStateStorePath variable via the "Set Local State Location" task (without the brackets <>).

Not deleting the State Store can cause the following problems:

• If an administrator tries to access the State Store, it may change the permissions of all of the user files in the State Store to the administrator's permissions. This may cause users not to be able to access their files and they may receive "Access Denied" error messages. For this reason it is recommended that an administrator not try to access the State Store directly.
• A user deleting files in their profile will not cause the actual file to be deleted since a second link exists to the file in the State Store. Although the user will no longer see the file in their profile, the link to the file will still exist in the State Store, and disk space will not be freed up.
• In Step 18 (Method 1) and Step 9 (Method 2), the option "Continue on Error" is disabled. This option is originally enabled because with USMT 3, USMT 3 could report a lot of false positive errors, causing the task to un-necessarily fail. However this has been improved in USMT 4 and this situation should rarely happen with USMT 4.
  If the option is left checked and the USMT 4 state capture fails for some reason, the Task Sequence will continue and eventually wipe the drive at the "Apply Operating System Image"/"Apply Operating System" task, causing all user files and settings to be deleted and lost. For this reason it is safer to leave this option unchecked when using USMT 4. Leaving the option unchecked will cause the Task Sequence to fail in the event that users' files are not captured successfully, which is a desired outcome.
• In Steps 18 and 21 (Method 1) and Steps 9 and 13 (Method 2), the option "Enable verbose logging" is enabled. This is optional, but it is advisable to leave this option enabled to help troubleshoot USMT 4 capture and restore failures. Enabling verbose logging will cause the capture and restore tasks to take a bit longer, but will the add the benefit of having more detailed logs to help resolve problems.
• The tasks "Request State Store" and "Release State Store" are not needed in the Task Sequences that performs local capture with hardlinking because these tasks are only used when a State Migration Point (SMP) is being used. An SMP is only used when the State Store is saved to a network location. When using hardlinking, the State Store is always saved to the local hard drive and an SMP is not used.
• In Steps 17 and 20 (Method 1) and Steps 8 and 12 (Method 2), please make sure to make the distinction between the variables specified in the tasks "Set USMT Additional Capture Options" and "Set USMT Additional Restore Options". The variables have similar names but they are different. One is OSDMigrateAdditionalCaptureOptionsand the other is OSDMigrateAdditionalRestoreOptions.

More Information

What is a hardlink and why use the USMT 4 feature of hardlinking?

Hardlinking is a feature of NTFS where multiple links can exist to one file on the hard drive. As long as one link exists, the file is not deleted. When a file has multiple links to it, the file will appear to exist in different locations in the file system, but the file only exists once on the hard drive. When the file is deleted from one location, as long as other links to the file still exist, the file is not actually deleted, and the file will still appear in the other locations that it has links to. The file is not deleted until it has been deleted from all of the locations that it has links to.

When USMT local capture is used without hardlinking, files are copied from their original location into the local State Store. For this reason, there has to be sufficient space on the hard drive to store all of the captured files. Even when compression is used, this can mean needing enough space on the hard drive somewhere in the area of almost double the amount of space taken up by the original files. If the original files take 30GB of space, then the hard drive will need about 30GB of free space on it.

When USMT 4 with hardlinking is used, instead of a file being copied to the local State Store, a second link to the file is created in the local State Store. The time taken to create the link to the file in the State Store is almost instantaneous, does not vary with the size of the file, and is much faster than trying to copy the file to the local State Store. The time it takes to capture 30GB of data will only take a bit longer than the time it takes to capture 1GB of data. When not using hardlinking, the amount of time taken to capture 30GB of data would be significantly longer than capturing 1GB of data.

Additionally hardlinking requires almost no additional hard drive space. The only additional hard drive space taken by USMT 4 with hardlinking are administrative files that keep track of where the files need to be restored to. This usually only takes a few MB of disk space vs. the potential GB of disk space taken when hardlinking is not used.

When USMT 4 with hardlinking is used in a ConfigMgr 2007 SP2 Task Sequence via the "Capture User State" task and the OSDStateStorePath
and OSDMigrateAdditionalCaptureOptions variables, during the "Capture User State" task, new links are created for the captured files in the State Store location . All of the original links to the files are then deleted during the "Apply Operating System Image" task via recursive delete and wipe of the hard drive. However, because a second link exists in the State Store, and because the State Store is not deleted or wiped during the "Apply Operating System Image" task, the original files remains intact and are not deleted. Later in the Task Sequence via the "Restore User State" task and the OSDStateStorePath and OSDMigrateAdditionalRestoreOptions variables, the original links to the files are recreated back to their original location.

USMT 4 hardlinking also has the advantage over saving the State Store on a network location, such as a State Migration Point (SMP), in that it does not have to take the time to copy the files up to the network share, bandwidth is not used, and a server with plenty of disk space for saving the State Stores is not needed.

To summarize, USMT 4 with hardlinking has the following advantages:

1. It is significant faster than either copying the captured files to the local State Store or a State Store located on a network share (SMP).
2. It requires only a few additional MB of disk space vs potential GB of disk space, whether on the local hard drive or on a network share on a server (SMP).
3. It saves network bandwidth when opting to use hardlinking over a network share (SMP).

The only disadvantage that hardlinking has is that it could potentially run into problems if there is file corruption on the hard drive, the hard drive has bad sectors, or the hard drive is having some other type of problems. However these problems would also be exposed when using local capture without hardlinking. In these scenarios, running a CHKDSK /R on the hard drive is advisable, and a full format of the drive may also be advisable. A network share (SMP) may be needed in these cases.

Why are the two above methods not valid when using a ConfigMgr 2007 Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard?

The above methods are not valid when using a ConfigMgr 2007 Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard because the Task Sequences created using the Wizard already have hardlinking enabled by default.

If a ConfigMgr 2007 Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard is inspected, it will be missing the "Set Task Sequence Variable" tasks that set the variables OSDStateStorePath, OSDMigrateAdditionalCaptureOptions, and OSDMigrateAdditionalRestoreOptions. So if the Task Sequence is missing the steps that sets these variables, and these variables are required to do hardlinking, how does the Task Sequence accomplish hardlinking?

It does this via the task "Determine Local or Remote UserState" task and the MDT script ztiuserstate.wsf. If the USMT 3 package is selected at the "Determine Local or Remote UserState" task, the ztiuserstate.wsf script determines if there is enough space on the hard drive to do a local capture (without hardlinking since it is USMT 3), and if not, it will perform a network capture via a State Migration Point (SMP). Based on which capture method determined by the ztiuserstate.wsf script is used, it defines the appropriate variables, OSDStateStorePath, OSDMigrateAdditionalCaptureOptions, and OSDMigrateAdditionalRestoreOptions, and along with conditions set on the relevant tasks, the Task Sequence will perform the appropriate capture.

However if the USMT 4 package is selected at the "Determine Local or Remote UserState" task, since disk space is not an issue, the ztiuserstate.wsf script will always default to local capture with hardlinking. It will then set the appropriate variables for the Task Sequence to perform a hardlink migration.

There is one problem though with using the ztiuserstate.wsf script. The ztiuserstate.wsf script defaults the State Store to the subdirectory StateStore within the Task Sequence cache folder. For the reasons stated in the notes above about saving the State Store within the Task Sequence cache folder, it is not always desirable to save the State Store within the Task Sequence cache folder.
The Task Sequence created by the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard actually works around the first issue (State Store is deleted even if the data was not restored) by moving the State Store out of the Task Sequence cache folder via the ztimovestatestore.wsf script and the "Move State Store" task. The State Store is moved whether or not the Task Sequence succeeds or fails. However the other two problems can still happen.

To resolve the other two problems and save the State Store outside of the Task Sequence cache folder when using a Task Sequence created with the MDT 2010/MDT 2010 Update 1 "Create Microsoft Deployment Task Sequence" Wizard, follow the below steps:

1. In the ConfigMgr 2007 Admin console, navigate to the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node.
2. Right click on the affected Task Sequence created using the MDT Wizard and choose "Edit".
3. Click on the "Determine Local or Remote UserState" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task after "Determine Local or Remote UserState" task but before the "Request State Store" task.
4. In the newly created "Set Task Sequence Variable Task":
   • Next to the "Name:" text box, enter in:
     Set Local State Location
     
   • Next to the "Task Sequence Variable:" text box, enter in
     OSDStateStorePath
     
   • Next to the "Value:" text box, enter in:
     %SystemDrive%\StateStore
     
5. Click on the "OK" or "Apply" button to save the task sequence.

The above steps resets the variable OSDStateStorePath to a path outside of the Task Sequence cache folder after the "Determine Local or Remote UserState" task and the ztiuserstate.wsf script sets it to the StateStore subdirectory within the Task Sequence cache folder.

Can an existing ConfigMgr 2007 Task Sequence that does not have any USMT tasks including the "Capture User State" and "Restore User State" tasks be modified to do USMT 4 hardlinking?

Yes, but the order of the steps and where they are placed in the Task Sequence are critical. The five tasks that need to be added, and the order that they need to run in are as follows:

• Set Local State Location
• Set USMT Additional Capture Options
• Capture User State
• Set USMT Additional Restore Options
• Restore User State

In addition, any "Format and Partition Disk" tasks need to be disabled.

The first three tasks, Set Local State Location, Set USMT Additional Capture Options, and Capture User State, have to run in the original full Windows OS before the Task Sequence boots into WinPE. This is usually before a "Restart Computer" task, such as the "Restart in Windows PE" task. The tasks also have to be placed into a group that has a condition where it only runs in the full Windows OS and not in WinPE. This can be accomplished by setting a condition on the group where the Task Sequence variable _SMSTSInWinPE equals false. The prevents the tasks from running in Bare Metal scenarios where the PCs are booted directly into WinPE and state capture is not needed.

The last two tasks, Set USMT Additional Restore Options and Restore User State, have to run in the newly deployed full Windows OS at some point after the "Setup Windows and ConfigMgr" task, preferably towards the end of the Task Sequence after all applications have been installed.

The Capture User State and Restore User State tasks are built in tasks of ConfigMgr 2007. They can be found under the "Add" --> "User State" menu in a Task Sequence.

The Set Local State Location, Set USMT Additional Capture Options, and Set USMT Additional Restore Options are all actually Set Task Sequence Variable tasks. For instructions on how to properly set up these tasks, see the two above methods.

As a general guide and template to modifying the existing Task Sequence, Method 1 above can be used to create a Task Sequence that serves as the template and guide to modifying the existing Task Sequence.

Frank Rojas | System Center Support Escalation Engineer

Symptoms

A System Center Configuration Manager 2007 site fails to upgrade to Service Pack 2 and reports SQL Error: The server service principal name already exists.  You may also see the following in the Configmgrsetup.log file:

<MM-DD-YYYY HH:MM:SS> ***SqlError: [42000][15025][Microsoft][ODBC SQL Server Driver][SQL Server]The server principal '<Domain>\Server1$' already exists.
<MM-DD-YYYY HH:MM:SS> SqlExecute < IF NOT EXISTS(SELECT * FROM sys.database_principals dp JOIN sys.server_principals sp ON dp.sid=sp.sid AND dp.name='dbo' AND sp.name='<Domain>\Server3$') BEGIN IF NOT EXISTS(SELECT * FROM master.sys.server_principals where name='<Domain>\Server3$') CREATE LOGIN [<Domain>\Server3$] FROM WINDOWS IF NOT EXISTS(SELECT * FROM sys.database_principals where name='<Domain>\Server3$') CREATE USER [<Domain>\Server3$] EXEC sp_addrolemember 'smsdbrole_MP', '<Domain>\Server3$' END

Cause

This can occur when a server in a site server role is renamed and the SPN's and SQL logins remain associated with the old computer name.

Resolution

1. Remove the <Domain>\<OldServerName> login record from the Configuration Manager database using SQL Management Studio.

2. Remove the old Service Principle Name using ADSIEdit:

1. Click Start, click Run, and enter adsiedit.msc to launch the ADSIEdit MMC console.
2. If necessary, connect to the site server's domain.
3. In the console pane, expand the site server's domain, expand DC=<server distinguished name>, expand CN=Users,and right-click CN=<Service Account User>. On the context menu, click Properties.
4. In the CN=<Service Account User> Properties dialog box, remove the servicePrincipalName value.

3. Add the new, proper SPN using the following command:

setspn –A MSSQLSvc/<SQL Server computer name>:1433 <Domain\Account>.

Note: See How to Configure an SPN for SQL Server Site Database Servers for more information.

4. Run SP2 setup again.  This time it should complete successfully.

More Information

How to Configure an SPN for SQL Server Site Database Servers: http://technet.microsoft.com/en-us/library/bb735885.aspx

Configuration Manager Service Principal Name Requirements: http://technet.microsoft.com/en-us/library/bb735877.aspx

=====

For all the details and the latest version of this document please see the following new Knowledge Base article:

KB2269959 -  A System Center Configuration Manager 2007 site fails to upgrade to Service Pack 2

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis

The following post was written by Charlie Chen (MCS):

=====

Though System Center Configuration Manager 2007 has been out for some time now (currently at R3 SP2), and System Center Configuration Manager 2012 is due to be out soon, there still lingers occasional questions such as, “How do Clients communicate with the Site Servers,” and “How big are the packets being sent,” related to the issue of network latency. This post attempts to address this issue for companies where network latency is a factor in systems management, gathered from various internal and external Microsoft sources (i.e. Product Team and Premiere Field Engineers), and the numbers presented here will likely to be similar to what you might see in ConfigMgr 2012. The numbers and figures here are provided as-is, and therefore subject to revision.

The following diagram represents a depiction of the ConfigMgr server-server (i.e. site-to-site) and server-client communications, focused mainly on what is happening in a Secondary Site. In an ideal design, server-client communications only occurs intra-site (over the LAN), and does not traverse inter-site (over the WAN). This allows for the scenarios where:

• Inter-site communications should only occur via server-to-server, over the WAN. Clients at a Secondary Site never directly communicate with a Primary Site.
• Intra-site communications can only occur over the LAN.
• Primary Site Distribution Point sends data over the WAN or LAN to a Secondary Site Distribution Point, via throttled SMB.
• Clients at a Secondary Site gets installation media from the local Secondary Site Distribution Point using BITS, over the LAN.
• Clients at a Secondary Site sends inventory to/gets policy from the Secondary Site Proxy Management Point, over the LAN.
• Secondary Site Proxy Management Point sends consolidated data over the WAN/LAN to the Primary Site Management Point, via throttled SMB.

However, the following caveats should be taken into account:

• There’s nothing in ConfigMgr to prevent multiple ConfigMgr sites on a LAN network.
• There’s nothing in ConfigMgr to prevent ConfigMgr Clients, physically local to a site, from being located across a WAN link if the boundaries are configured this way (not the best design).
• The diagram assumes that you have Proxy MPs and DPs roles on the Secondary Site Servers. Clients at a Secondary Site communicate with their Primary Site if there is no Proxy MP or DP on the Secondary Site, and those roles exist on the Primary Site.
• By default, Clients get their initial installation bits from a MP. Frequently, this is over a WAN connection.
• Clients at a Secondary Site sends inventory to/gets policy from the Secondary Site Proxy Management Point, over the LAN/WAN, if the Proxy MP exists.
• BDPs should be connected to sites with the least number of network hops to the DP, and so they may not be necessarily connected to a Secondary Site.

Additionally, the following points should be noted for the diagram:

• Server-to-server traffic is SMB & PPTP, to DP is SMB & RPC.
• BITS is to run intra-site (LAN) only, and not inter-site (WAN).
• BITS does not kick-in until the action is greater than 512 KB.
• BITS can be throttled for computers via Group Policy.
• BITS can be throttled for Branch DPs via ConfigMgr.

The diagram is only meant to illustrate the ConfigMgr server-server and server-client communications. For details of the protocols and ports used, see Ports Used by Configuration Manager.

Primary and Secondary Site Considerations

From Understanding Configuration Manager Sites:

Primary Sites

- A primary site stores Configuration Manager 2007 data for itself and all the sites beneath it in a SQL Server database.

Secondary Sites

- The secondary site forwards the information it gathers from Configuration Manager 2007 clients, such as computer inventory data and Configuration Manager 2007 system status information, to its parent site.

The Secondary Sites accomplish this with a ConfigMgr role called the Proxy Management Point, which is:

A proxy management point is a management point installed at a secondary site. The proxy management point is used by Configuration Manager Clients to retrieve policy at secondary sites attached to their assigned primary site. The proxy management point receives inventory data and status messages and sends them to the secondary site server to be forwarded to the parent site. Using a proxy management point increases bandwidth usage efficiency for clients at secondary sites.

For each Secondary Site, as defined in Planning Configuration Manager Boundaries:

Boundaries are used to assign clients to a specific Configuration Manager 2007 site and should be unique to each site.

As such, from Configuration Manager Site System Planning, Distribution Points are site systems and should be placed in Secondary Sites so that Client traffic stays in the LAN with a Protected Distribution Point:

…clients outside of the protected boundaries will not be able to access the distribution point or state migration point roles on that site system.

A Protected Distribution Point is not a role, but how the Boundaries of a Distribution Point are configured. This is so that Client requests for installation media do not go over the WAN, and also allows BITS from the Distribution Point to the Client, thus throttling the traffic between the Distribution Points and the Clients:

Server distribution point site systems can be BITS-enabled to allow Configuration Manager 2007 clients to throttle network usage during package downloads. To install a BITS-enabled distribution point, IIS must first be installed on the site system computer and BITS-enabled in IIS.

And all of this changes in ConfigMgr 2012, as detailed in, What’s New in Configuration Manager 2012.

Throttling Server to Server RPC

Site server traffic between the Primary Site and the Secondary Sites can be throttled, as described in How to Set Address Data Transfer Rates:

By default, the data transfer rate that Configuration Manager 2007 sites will use to send data to an address (another site) is unlimited at all times. This means that when a site is transmitting data to another site, it could potentially consume 100% of the available bandwidth during the data transfer. However, you can limit how much connection bandwidth is used at different times of the day by setting maximum data transfer rate for the address.

Throttling Server to Client BITS

Generally, it is not recommended to throttle BITS. As described in About BITS:

BITS uses idle network bandwidth to transfer the files and will increase or decrease the rate at which files are transferred based on the amount of idle network bandwidth available.

Because BITS already “provides one foreground and three background priority levels that you use to prioritize transfer jobs,” throttling BITS is almost like double throttling. Basically, throttling BITS means that BITS’ algorithm is being limited from taking advantage of the idle network bandwidth.

Drawbacks of throttling BITS include Clients taking a long time to install packages, and a limited ability to push out “Emergency” packages, e.g. Windows Updates. The critical piece is to TEST the requirement in a pilot first, to ensure that the right combination of settings makes a network team happy.

To throttle BITS, Group Policy settings can be used for Windows 7, as shown below, from the Bits.admx in WindowsServer2008R2andWindows7GroupPolicySettings.xlsx. Deprecated Windows XP policies have been removed from the list below. Specifically, you can use the Policy, Set up a work schedule to limit the maximum network bandwidth used for BITS background transfers, to limit the bandwidth. It is discouraged to use Allow BITS Peercaching to allow client peers to share BITS data, but instead, use a Branch Distribution Point role. ConfigMgr 2012 will have the ability to throttle BITS per ConfigMgr Collection, if it is required.

Table 1: Bits.admx from WindowsServer2008R2andWindows7GroupPolicySettings.xlsx

BranchCache and Branch Distribution Points

There are several articles that reference BranchCache and Branch Distribution Points, including:

• Reducing Bandwidth Utilization with Windows 7 and Windows Server 2008 R2 BranchCache
• Configuring SCCM and BranchCache
• Branch DP internals - SCCM 2007
• FAQs for Branch Distribution Points

But what are the reasons to deploy one or another? Or even both or neither? To answer this, it helps to look at the dichotomy between BranchCache and Branch Distribution Points. Most importantly, it should be understood that the BranchCache and Branch Distribution Point (BDP) roles are completed different.

The BDP is specific to ConfigMgr, and BranchCache is a technology built into Windows 2008 R2. The BDP is actually a function of the ConfigMgr client and even a Windows XP machine can function as a BDP. With a BDP, you can also conduct On Demand Packaging and pre-stage content on the BDP, if you need to do so.

BranchCache is specific to Windows 2008 R2, and only Window Vista (with BITS 4.0) and Windows 7 support BranchCache. For BranchCache, all of the servers that participate in BranchCache need to be Windows 2008 R2, with BranchCache enabled.

If you have a server operating system in a remote office, you are better off making the office a Secondary Site and putting a Distribution Point (not BDP) there. If you have just workstations, the typical practice is to use BDP on the best workstation, as you are allowed more control of packages within the ConfigMgr console, and after all, you are using ConfigMgr to manage your software distribution. However, as referenced above in Configuring SCCM and BranchCache, you can use ConfigMgr and BranchCache together if it is appropriate for your environment, and as noted in this article:

BranchCache is just one more option available to administrators to help deliver content to clients efficiently and reduce load on the network.

A VSD of the diagram above can be found here:

Charlie Chen (MCS) | Microsoft Consulting Services

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials
The Server App-V Team blog: http: http://blogs.technet.com/b/serverappv

Consider the following scenario:

1. You deploy many updates to a Microsoft System Center Configuration Manager 2007 Service Pack 2 (SP2) client.

2. You perform an operation that generates the WM_TIMECHANGE message from the client computer. For example, you perform one of the following operations:

- You change the system time.
- You resume a computer from sleep.
- You resume a computer from hibernation.

In this scenario, the computer runs slowly for some time. Additionally, the CPU usage is high, and the computer processes a heavy workload of disk I/O.

For all the details, including the cause and hotfix, see the following new Knowledge Base article:

KB2309968- Slow performance after you change the system time or resume the computer from sleep or hibernation on a System Center Configuration Manager 2007 SP2 client

J.C. Hornbeck | System Center Knowledge Engineer

The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis
The Service Manager Team blog: http: http://blogs.technet.com/b/servicemanager
The AVIcode Team blog: http: http://blogs.technet.com/b/avicode
The System Center Essentials Team blog: http: http://blogs.technet.com/b/systemcenteressentials
The Server App-V Team blog: http: http://blogs.technet.com/b/serverappv

Here’s a new Knowledge Base article we published recently. This one is a hotfix for an issue where a ConfigMgr 2007 SP2 task to install a virtual application that is located on an App-V distribution point that has streaming enabled hangs (stops responding):

=====

Symptoms

Consider the following scenario. You create an operating system deployment (OSD) task on a site server that has Microsoft System Center Configuration Manager 2007 Service Pack 2 (SP2) installed. You configure the task to install a virtual application that is located on a Microsoft Application Virtualization (App-V) distribution point that has streaming enabled. In this scenario, the OSD task stops responding….

=====

For the most current version of this article and a download link for the hotfix itself please see the following:

2678547 : OSD tasks stop responding in System Center Configuration Manager 2007 SP2

J.C. Hornbeck| System Center & Security Knowledge Engineer

Get the latest System Center news onFacebookandTwitter:

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/