Announcing the new P2V Migration Tool for Software Assurance

September 7, 2010, 12:23 pm

≫ Next: The Configuration Manager 2007 Client Installation and Assignment SuperFlow is now available

≪ Previous: Fix: Configuration Manager 2007 Management Point install fails on Windows Server 2008 with “The error code is 800CC801”

Our pals over on the Nexus SC blog posted some great info on migrating users to Windows 7 while keeping the users previous Windows XP (or newer) environment available to them in the new OS. It's like having your cake and eating it too:

Hey everyone, if you are considering any type of client migration on you way to Windows 7 , and you have thought about how to manage the end user experience through the process, you may want to check this out.

P2V Migration for Software Assurance uses the Microsoft Deployment Toolkit and Sysinternals Disk2VHD to convert a user's existing Windows XP or newer client environment to a virtual hard disk then automates the delivery of an updated and personalized Windows 7 operating system containing virtual machine with the user's previous Windows environment, applications and Web browser. The user's previous virtual desktop retains its existing management components, domain membership and policies. The process also publishes applications and the browser for the user to access them seamlessly within Windows 7's start menu.

To continue reading and to get all the details on how this works see Announcing the P2V Migration Tool for Software Assurance.

J.C. Hornbeck | System Center Knowledge Engineer

↧

The Configuration Manager 2007 Client Installation and Assignment SuperFlow is now available

September 7, 2010, 1:35 pm

≫ Next: Solution: After a ConfigMgr 2007 OSD Task Sequence completes, the client may not automatically pull down policy

≪ Previous: Announcing the new P2V Migration Tool for Software Assurance

The Client Installation and Assignment SuperFlow is a dynamic, interactive content model that provides you with detailed steps that you can use to prepare for and install the Configuration Manager 2007 client. This SuperFlow also provides you with the dataflow for background processes, additional resources related to client installation, and troubleshooting information for common issues.

You can find more details and download the Client Installation and Assignment SuperFlow here.

We also have six other SuperFlows currently available covering the following topics:

You can find the most current list of Configuration Manager 2007 SuperFlows here.

J.C. Hornbeck | System Center Knowledge Engineer

↧

Solution: After a ConfigMgr 2007 OSD Task Sequence completes, the client may not automatically pull down policy

September 13, 2010, 12:35 pm

≫ Next: How to create a custom default user profile for a Windows Vista or newer OS when using ConfigMgr 2007 OSD

≪ Previous: The Configuration Manager 2007 Client Installation and Assignment SuperFlow is now available

When a System Center Configuration Manager 2007 OSD Task Sequence completes, the ConfigMgr client may not seem to pull down policy. Inspecting the ConfigMgr client on the affected PC reveals that under the "Advanced" tab the client is assigned to a site, and the "Discover" button successfully discovers the site. However the following abnormalities are observed:

- Under the "General" tab, the property "Site Mode" is equal to "Unknown".

- Under the "Components" tab, most of the components are Installed but not Enabled. The only enabled components are "ConfigMgr Software Distribution Agent" and "ConfigMgr Software Updates Agent".

- Under the "Actions" tab, only a few actions are available, including "Machine Policy Retrieval & Evaluation Cycle", "Software Updates Deployment Evaluation Cycle", and "User Policy Retrieval & Evaluation Cycle".

- Inspecting the following registry key:

HKLM\SOFTWARE\Microsoft\CCM\CcmExec!ProvisioningMode

reveals that it is set to true and that the ConfigMgr client is in provisioning mode.

- Inspecting the following registry key:

HKLM\SOFTWARE\Microsoft\CCM\CcmExec!SystemTaskExcludes

reveals that it is not empty and has the following value instead:

SchedulerStartup;SchedulerShutdown;SchedulerLogon;SchedulerLogoff;ClientRegistrationStartup

Clicking on the "Machine Policy Retrieval & Evaluation Cycle" action may cause the PC to start receiving some policy, including additional components being enabled and additional actions being made available. It may also cause the client to show up as a valid client in the ConfigMgr console, however not all policy is received and certain items such as advertised programs and software updates are never made available. Additionally, in the ConfigMgr client control panel, under the "General" tab the property "Site Mode" remains "Unknown".

Reinstalling the ConfigMgr client or modifying the above registry keys usually resolves the issue, however this is not an ideal solution since the client should be fully operational when the Task Sequence completes.

Cause

During a ConfigMgr 2007 OSD Task Sequence, the ConfigMgr client is purposely placed in a provisioning mode. In this mode, the ConfigMgr client does not pick up policy from the MP. This is done so that advertised programs, software updates, and tasks targeted to existing client PCs do not run until the Task Sequence completes. If advertised programs, software updates, or tasks attempt to run while the Task Sequence runs it may interfere with the Task Sequence and cause it to fail.

Normally when the Task Sequence completes and exits cleanly, the ConfigMgr client is automatically taken out of provisioning mode. As soon as the ConfigMgr client is taken out of provisioning mode, it then proceeds to pull down policy from the MP and configure the ConfigMgr client appropriately.

If the Task Sequence does not exit cleanly, the ConfigMgr client may not be taken out of provisioning mode. This may lead to the ConfigMgr client not being configured properly and where it does not pull down policy from the MP. Manual attempts at trying to download policy will only partially succeed since the ConfigMgr client is in provisioning mode and not configured properly.

Please note that Task Sequence not exiting cleanly is not the same as the Task Sequence failing. When Task Sequences fail they usually still exit cleanly. A Task Sequence not exiting cleanly is usually caused by one of the following scenarios:

1. At some point after the "Setup Windows and ConfigMgr" task, a power failure or crash occurs on the PC. At this point the PC may be bootable and the user may be able to log into the PC. However because the Task Sequence never exited cleanly, the ConfigMgr client is left in provisioning mode, and the problem may exist.

2. A "Restart Computer" task at some point after the "Setup Windows and ConfigMgr" task that is accidentally set to restart into the WinPE boot image assigned to the Task Sequence instead of the full Windows OS. This will cause the Task Sequence to end in WinPE. Because the ConfigMgr client is actually installed as part of the full Windows OS and not WinPE, and because the Task Sequence ends in WinPE instead of the full Windows OS, it cannot properly take the ConfigMgr client out of provisioning mode.

This error is common because the "Restart Computer" task defaults to restarting into the WinPE boot image instead of the full Windows OS. The "Restart Computer" task option "The boot image assigned to this task sequence" will cause it to reboot into WinPE, while the option "The currently installed default operating system" will cause it to reboot into the full Windows OS being deployed by the Task Sequence. If the option is not specifically switched from the default setting when the "Restart Computer" task is added to the Task Sequence, then the issue will occur.

3. In Windows XP and Windows Server 2003, if an application is installed during the Task Sequence that installs a custom Gina, the problem will happen. In Windows XP and Windows Server 2003, the ConfigMgr OSD Task Sequence will install a custom Gina called OSDGina. This Gina is used for several reasons during a Task Sequence such as accomplishing automatic log ins between reboots, disabling all user interfaces such as Explorer, etc. If the OSDGina is replaced by another custom Gina, then the Task Sequence cannot end or exit cleanly and the ConfigMgr client will not be taken out of provisioning mode.
Note: Custom Ginas can only be used in Windows XP or Windows Server 2003. Custom Gina issues will not occur in Windows Vista or newer since custom Ginas, including OSDGina, are not used in Windows Vista or newer.

Resolution

To confirm the issue, inspect the registry key to see if it is set to True:

HKLM\SOFTWARE\Microsoft\CCM\CcmExec!ProvisioningMode

Additionally, inspect the registry key:

HKLM\SOFTWARE\Microsoft\CCM\CcmExec!SystemTaskExcludes

see if has the following value:

SchedulerStartup;SchedulerShutdown;SchedulerLogon;SchedulerLogoff;ClientRegistrationStartup

If either or both of the above is true then the ConfigMgr client is stuck in provisioning mode.

Setting the first registry value to False and blanking out the second registry value will resolve the issue on that particular client, however this will not resolve the issue from occurring again during the Task Sequence on another client.

To determine if one of the tasks in the Task Sequence is causing the problem, disable all tasks after the "Setup Windows and ConfigMgr" task and rerun the Task Sequence. If the Task Sequence completes successfully and the ConfigMgr client successfully processes policy then the problem is with one of the tasks in the Task Sequence after the "Setup Windows and ConfigMgr" task.

To resolve the issue, first determine what is causing the Task Sequence not to exit cleanly:

1. A misconfigured "Restart Computer" task after the "Setup Windows and ConfigMgr" task that finishes the Task Sequence in WinPE instead of the full Windows OS.

2. When deploying Windows XP or Windows Server 2003, an "Install Software" or "Run Command Line" task that installs a custom Gina.

Once the cause of the problem is determined, follow the appropriate section below to resolve the issue.

Note: Do NOT try and resolve the problem by trying to add tasks in the Task Sequence that change the registry keys that sets the ConfigMgr client to provisioning mode. Doing so can cause unexpected behavior and may cause the Task Sequence to fail.

To resolve the issue when caused by a misconfigured "Restart Computer" task:

1. In the ConfigMgr 2007 console, navigate to "Computer Management" --> "Operating System Deployment" --> "Task Sequences".

2. Right click on the affected Task Sequence and choose "Edit".

3. Locate any "Restart Computer" tasks that exist after the "Setup Windows and ConfigMgr" task and then click on them. Please note that the "Restart Computer" tasks may have been given a custom name.

4. In each "Restart Computer" task, verify that the setting "Specify what to run after restart:" is set to "The currently installed default operating system".

Note: If for some reason the intention is to actually restart the Task Sequence back into the WinPE boot image at some point after the "Setup Windows and ConfigMgr" task, an additional "Restart Computer" task needs to be added to the Task Sequence at some point after the original "Restart Computer" task with the "Specify what to run after restart:" setting properly selected to "The currently installed default operating system". In other words, for Task Sequence that have "Restart Computer" tasks after the "Setup Windows and ConfigMgr" task, the final "Restart Computer" task in Task Sequence should always have the setting "Specify what to run after restart:" set to "The currently installed default operating system". This will ensure that the Task Sequence complete in the full Windows OS and not in WinPE.

To resolve the issue when caused by an application installing a custom Gina:

1. On a PC that already has the custom GINA installed, take a look at the following registry key and record the name of the custom Gina:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon!GinaDLL

2. In the ConfigMgr 2007 console, navigate to "Computer Management" --> "Operating System Deployment" --> "Task Sequences".

3. Right click on the affected Task Sequence and choose "Edit".

4. Locate the "Install Software" or "Run Command Line" task that installs the application with the custom Gina.

If the task is a "Run Command Line", under the "Command line:" text box, modify the command line and add the appropriate switches or options to suppress reboots. Once done, move on to Step 5. Please note that the appropriate command, options, or switches vary with application installer. Please refer to the product documentation of the application installer for the appropriate command, option, or switch to suppress reboots.
If the task is an "Install Software" task, determine the Package and Program that installs the custom Gina.
1. In the ConfigMgr 2007 console, navigate to "Software Distribution" --> "Packages".
2. Locate the appropriate Package, expand it and then click on "Programs".
3. Right click on the appropriate Program and choose "Properties".
4. Under the "General" tab, next to the "Command line:" box, modify the command line and add the appropriate switches or options to suppress reboots. Please note that the appropriate command, options, or switches vary with application installer. Please refer to the product documentation of the application installer for the appropriate command, option, or switch to suppress reboots.
5. Click on the "OK" button.
6. Switch back to the affected Task Sequence.

5. Click on the “Install Software” or "Run Command Line" task that installs the application with the custom Gina, and then go to "Add" --> "General" --> "Run Command Line". This should create a "Run Command Line" task immediately after the “Install Software” or "Run Command Line" task that installs the application with the custom Gina.

6. In the newly created "Run Command Line" task from Step 5:

Next to the "Name: " text box, enter in: Set Custom Gina
Under the "Command Line:" text box, enter in:

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v OSDOldGinaDLL /t REG_SZ /d <Custom_Gina> /f

where <Custom_Gina> is the value obtained from Step 1, i.e. CustomGina.dll. Do not include the brackets <> in the registry key value.

7. Click on the "Capture Custom Gina" Run Command Line task created in Steps 5 and 6 and then go to "Add" --> "General" --> "Run Command Line". This should create a "Run Command Line" task immediately after the "Set Custom Gina" Run Command Line task.

8. In the newly created "Run Command Line" task from Step 7:

Next to the "Name: " text box, enter in: Restore OSD Gina

Under the "Command Line:" text box, enter in:

REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v GinaDLL /t REG_SZ /d OSDGINA.DLL /f

9. Click on the "Apply" button to save the Task Sequence.

When the Task Sequence completes, it will use the value stored in the below registry key to restore the custom Gina:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon!OSDOldGinaDLL

Frank Rojas | System Center Support Escalation Engineer

↧

How to create a custom default user profile for a Windows Vista or newer OS when using ConfigMgr 2007 OSD

September 16, 2010, 8:01 am

≫ Next: New Solution: A System Center Configuration Manager 2007 site fails to upgrade to Service Pack 2

≪ Previous: Solution: After a ConfigMgr 2007 OSD Task Sequence completes, the client may not automatically pull down policy

When building a Windows Vista or newer reference image (Windows 7, Windows Server 2008, Windows Server 2008 R2), to create a custom Default User profile based on modifications done on the local Administrator profile normally the CopyProfile option is used in an Unattend.xml file. However, since System Center Configuration Manager 2007 creates its own Unattend.xml file the CopyProfile option cannot be specified.

Resolution

After making the required changes and customizations to the local Administrator profile, capture the Windows reference image using the normal methods (i.e., ConfigMgr 2007 Capture Media). The custom Default User profile does not have to be created at Sysprep/Capture time. It can be created at deployment time.

The CopyProfile option can be specified in a custom Unattend.xml file that is then injected and merged with the Unattend.xml file generated by the ConfigMgr 2007 OSD Task Sequence when the Windows OS is deployed.

To create the custom Default User profile during the ConfigMgr OSD Task Sequence that deploys the Windows OS:

1. Open Notepad.

2. Choose the appropriate architecture below of the Windows OS being deployed, copy the lines below the architecture, and paste them into the Notepad. When pasting in Notepad, make sure that the Word Wrap option is turned off so that the below lines paste properly:

x86

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <CopyProfile>true</CopyProfile>
        </component>
    </settings>
</unattend>

x64
<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <CopyProfile>true</CopyProfile>
        </component>
    </settings>
</unattend>

Note: In both examples above, the "component name" line (everything between the "settings pass" and "CopyProfile" lines) should all be on one line. Make sure that the line does not wrap when pasting in Notepad.

3. Save the Notepad file with the name copyprofile.xml. When saving the file, make sure that "All Files (*.*)" is selected next to "Save as type:" so that it does not append the .txt extension to the file.

4. In the ConfigMgr 2007 Admin console, under the "Computer Management" --> "Software Distribution" --> "Packages" node, create a new package that contains the copyprofile.xml file created in Steps 2 & 3. A Program does not need to be created for the Package. After creating the Package, make sure to copy the Package to the Distribution Points.

5. In the Configuration Manager 2007 Admin Console, under the "Computer Management" --> "Operating System Deployment" --> "Task Sequences" node, right click on the Task Sequence that deploys the OS and choose "Properties".

6. In the "Apply Operating System" task:

Check the option "Use an unattended or sysprep answer file for a custom installation
Next to the "Package:" field, click on the "Browse..." button and select the package created in Step 4
Next to the field "Filename:", enter: copyprofile.xml

7. Click on the "Apply" button to save the Task Sequence.

Notes:

1. If an existing custom XML file is already being used in the "Apply Operating System" task, then the appropriate lines from Step 2 should be added to the appropriate sections in the existing XML file. When doing so, make sure not to duplicate any lines. When finished modifying the existing custom XML file, make sure to update the DPs for the package that the XML file is contained in.

2. As an alternative, Steps #1-3 above can be replaced by using Windows System Image Manager (WSIM) instead. WSIM, which is part of the Windows Automated Installation Kit (WAIK), can be used to create the appropriate XML file with the CopyProfile section in it. If an existing custom XML file is already being specified as noted in Note #1 above, WSIM can also be used modify the existing custom XML file by adding the CopyProfile section to the existing XML file.

Frank Rojas | System Center Support Escalation Engineer

↧

New Solution: A System Center Configuration Manager 2007 site fails to upgrade to Service Pack 2

September 16, 2010, 1:36 pm

≫ Next: New Solution: System Center Configuration Manager 2007 client may fail to load policy with error 80040217 in PolicyEvaluator.log

≪ Previous: How to create a custom default user profile for a Windows Vista or newer OS when using ConfigMgr 2007 OSD

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:

Click Start, click Run, and enter adsiedit.msc to launch the ADSIEdit MMC console.
If necessary, connect to the site server's domain.
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.
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

↧

New Solution: System Center Configuration Manager 2007 client may fail to load policy with error 80040217 in PolicyEvaluator.log

September 16, 2010, 2:13 pm

≫ Next: New KB: System Center Configuration Manager 2007 Management Point install fails on Windows Server 2008 with “The error code is 800CC801”

≪ Previous: New Solution: A System Center Configuration Manager 2007 site fails to upgrade to Service Pack 2

Symptoms

System Center Configuration Manager 2007 clients may fail to load policy with error 80040217 in the PolicyEvaluator.log:

Failed to load policies from XML. Unknown error (Error: 80040217; Source: Unknown)
Bad policy dumped to C:\Windows\SysWOW64\CCM\Temp\badpolicy-SMS_P01-{2f76229b-385a-43f3-b281-d295098693ed}-2.00-{913d3bcd-af48-4180-8715-31a2508e4608}.txt
Already sent a policy rule application failure status message within the last 6 hours, not sending.
Failed to apply policy rule {913d3bcd-af48-4180-8715-31a2508e4608}.
The policy CCM_Policy_Policy4.PolicyID="{2f76229b-385a-43f3-b281-d295098693ed}",PolicySource="SMS:P01",PolicyVersion="2.00" failed to compile. State has been set to 'Inactive' and policy will be rolled back.
Failed to update policy CCM_Policy_Policy4.PolicyID="{2f76229b-385a-43f3-b281-d295098693ed}",PolicySource="SMS:P01",PolicyVersion="2.00"

You may also find the following in the PolicyAgent.log:

Raising event:
instance of CCM_CcmHttp_Status
{
ClientID = "GUID:5396B6AF-3376-445F-AEA6-A2A84912AC09";
DateTime = "20100505185728.297000+000";
HostName = "";
HRESULT = "0x00000000";
ProcessID = 1804;
StatusCode = 0;
ThreadID = 4876;
};
Raising event:
instance of CCM_PolicyAgent_PolicyDownloadSucceeded
{
ClientID = "GUID:5396B6AF-3376-445F-AEA6-A2A84912AC09";
DateTime = "20100505185728.303000+000";
DownloadMethod = "HTTP";
DownloadSource = "http:///SMS_MP/.sms_pol?{2f76229b-385a-43f3-b281-d295098693ed}.2_00";
PolicyNamespace = "\\\\\\ROOT\\ccm\\Policy\\Machine\\RequestedConfig";
PolicyPath = "CCM_Policy_Policy4.PolicyID=\"{2f76229b-385a-43f3-b281-d295098693ed}\",PolicySource=\"SMS:P01\",PolicyVersion=\"2.00\"";
ProcessID = 1804;
ThreadID = 4876;
};
)
Failed to trigger policy evaluation for CCM_Policy_Policy4.PolicyID="{2f76229b-385a-43f3-b281-d295098693ed}",PolicySource="SMS:P01",PolicyVersion="2.00"
Policy state for CCM_Policy_Policy4.PolicyID="{2f76229b-385a-43f3-b281-d295098693ed}",PolicySource="SMS:P01",PolicyVersion="2.00" was successfully reset. Policy download will be retried at next evaluation cycle.
Raising event:
instance of CCM_CcmHttp_Status
{
ClientID = "GUID:5396B6AF-3376-445F-AEA6-A2A84912AC09";
DateTime = "20100505191228.383000+000";
HostName = "";
HRESULT = "0x00000000";
ProcessID = 1804;
StatusCode = 0;
ThreadID = 5016;
};
Raising event:
instance of CCM_PolicyAgent_PolicyDownloadSucceeded
{
ClientID = "GUID:5396B6AF-3376-445F-AEA6-A2A84912AC09";
DateTime = "20100505191228.388000+000";
DownloadMethod = "HTTP";
DownloadSource = "http:///SMS_MP/.sms_pol?{2f76229b-385a-43f3-b281-d295098693ed}.2_00";
PolicyNamespace = "\\\\\\ROOT\\ccm\\Policy\\Machine\\RequestedConfig";
PolicyPath = "CCM_Policy_Policy4.PolicyID=\"{2f76229b-385a-43f3-b281-d295098693ed}\",PolicySource=\"SMS:P01\",PolicyVersion=\"2.00\"";
ProcessID = 1804;
ThreadID = 5016;
};
Failed to trigger policy evaluation for CCM_Policy_Policy4.PolicyID="{2f76229b-385a-43f3-b281-d295098693ed}",PolicySource="SMS:P01",PolicyVersion="2.00"
Policy state for CCM_Policy_Policy4.PolicyID="{2f76229b-385a-43f3-b281-d295098693ed}",PolicySource="SMS:P01",PolicyVersion="2.00" was successfully reset. Policy download will be retried at next evaluation cycle.

Cause

This can occur if the site has no Network Access Account defined.

Resolution

Using WBEMTEST, connect to the client's root\ccm\policy\machine\actualconfig namespace and reviewed the CCM_NetworkAccessAccount class (root\ccm\policy\machine\actualconfig\CCM_NetworkAccessAccount). If no instance is found here it can confirm bad or missing Network Access Account data.

To resolve the issue add a new Network Access Account in the Admin console using steps below. Once clients received the change they should process policy as expected.

To specify the Network Access Account:

1. In the Configuration Manager console, navigate to System Center Configuration Manager / Site Database / Site Management / <site code> - <site name> / Site Settings / Client Agents.

2. In the results pane, double-click Computer Client Agent.

3. In the Computer Client Agent Properties dialog box, on the General tab, for the Network Access Account, click Set.

4. In the Windows User Account dialog box, specify an existing Windows domain user account and password, and then click OK.

5. Click OK.

More Information

Custom Error Codes for Configuration Manager 2007: http://technet.microsoft.com/en-us/library/bb632794.aspx

80040217 = CCM_ERRORCODE(0x 80040217) DATACORRUPT 2147746327
Data is corrupt

About the Network Access Account: http://technet.microsoft.com/en-us/library/bb680398.aspx

=====

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

KB2217190 - System Center Configuration Manager 2007 client may fail to load policy with error 80040217 in PolicyEvaluator.log

J.C. Hornbeck | System Center Knowledge Engineer

↧

New KB: System Center Configuration Manager 2007 Management Point install fails on Windows Server 2008 with “The error code is 800CC801”

September 21, 2010, 6:42 am

≫ Next: New KB: WDS Multicast settings in the Distribution Point properties do not seem to apply in System Center Configuration Manager 2007 R2 and R3

≪ Previous: New Solution: System Center Configuration Manager 2007 client may fail to load policy with error 80040217 in PolicyEvaluator.log

We posted this solution a while back but it's proven to be so popular that it was converted to an official Knowledge Base article. You can find our original post here but the test of the KB is below:

=====

Symptoms

When attempting to install a System Center Configuration Manager 2007 Management Point (MP) on Windows Server 2008, the setup may fail with the following errors:

MPMSI.LOG
[13:52:07] Enabling BITS
[13:52:08] @@ERR:25006
MSI (s) (DC!FC) [13:52:08:085]: Product: SMS Management Point -- Error 25006. Setup was unable to create the Internet virtual directory CCM_Incoming
The error code is 800CC801

Error 25006. Setup was unable to create the Internet virtual directory CCM_Incoming
The error code is 800CC801
CustomAction CcmCreateIISVirtualDirectories returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

MPSETUP.LOG
<08-27-2010 13:43:26> Installing E:\Program Files (x86)\Microsoft Configuration Manager\bin\i386\mp.msi CCMINSTALLDIR="E:\Program Files (x86)\SMS_CCM" CCMSERVERDATAROOT="E:\Program Files (x86)\Microsoft Configuration Manager" USESMSPORTS=TRUE SMSPORTS=80 USESMSSSLPORTS=TRUE SMSSSLPORTS=443 USESMSSSL=TRUE SMSSSLSTATE=0 CCMENABLELOGGING=TRUE CCMLOGLEVEL=1 CCMLOGMAXSIZE=1000000 CCMLOGMAXHISTORY=1
<08-27-2010 13:51:30> mp.msi exited with return code: 1603
<08-27-2010 13:51:30> Backing up E:\Program Files (x86)\Microsoft Configuration Manager\logs\mpMSI.log to E:\Program Files (x86)\Microsoft Configuration Manager\logs\mpMSI.log.LastError
<08-27-2010 13:51:30> Fatal MSI Error - mp.msi could not be installed.

Note that the failures are observed on Standard, Enterprise, x86, and x64 versions. The failures are observed in the following circumstances:

After performing a site repair of a site server running on Windows 2008 with a local MP already installed
Initial install of an MP on a machine running Windows 2008
After removing and attempting to reinstall an MP on a machine running Windows 2008

Resolution

As of right now, the easiest way to resolve this issue is to remove and reinstall the BITS component. If the ConfigMgr 2007 Management Point role was already installed then it will also be necessary to remove and reinstall that role once you've done the same with BITS.

For the latest version of the article see the link below:

KB2419559 - System Center Configuration Manager 2007 Management Point install fails on Windows Server 2008 with “The error code is 800CC801”

J.C. Hornbeck | System Center Knowledge Engineer

↧

New KB: WDS Multicast settings in the Distribution Point properties do not seem to apply in System Center Configuration Manager 2007 R2 and R3

September 22, 2010, 7:07 am

≫ Next: Fix: The ConfigMgr 2007 database grows excessively large and DPs do not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings

≪ Previous: New KB: System Center Configuration Manager 2007 Management Point install fails on Windows Server 2008 with “The error code is 800CC801”

Symptoms

When modifying Multicast settings in the properties of a Distribution Point, the values for "MultiCast address", "UDP port range", and "Transfer rate" can all be modified under the "Multicast" tab of the ConfigMgr distribution point Properties. After configuring the settings, the settings are modified and applied in the GUI of the "Multicast" tab of the ConfigMgr distribution point Properties.

However, when attempting to Multicast, the Multicast sessions do not work, or do not work based on the values sepcified in the "Multicast" tab of the ConfigMgr distribution point Properties. Performing network traces confirms that the values being seen in the network traces seem to indicate that the Multicast sessions are using the default values originally set in the "MultiCast" tab of the ConfigMgr distribution point Properties, and not the modified values. Reinspecting the values under the the "Multicast" tab of the ConfigMgr distribution point Properties shows that the settings and values in the GUI have been modified and are set to the desired values.

Other values under the "Multicast" tab of the ConfigMgr distribution point Properties window that may have been changed seem to have been applied and work correctly, such as "Specify the account to connect to the database", "Enable scheduled multicast", and "Maximum" clients. Only the "MultiCast address", "UDP port range", and "Transfer rate" settings seem to have issues.

Cause

This problem is caused by a known issue in ConfigMgr 2007 R2 and R3 where the "MultiCast address", "UDP port range", and "Transfer rate" settings specified under the "Multicast" tab of the ConfigMgr distribution point Properties may not actually set the settings correctly. Specifically, the "MultiCast address", "UDP port range", and "Transfer rate" settings are Windows Server 2008/Windows Server 2008 R2 Windows Deployment Services (WDS) settings. When these settings are configured in the ConfigMgr distribution point Properties, ConfigMgr 2007 will automatically set the WDS settings in the background. However due to the known issue, the settings are actually never set, even though they show correctly under the "Multicast" tab of the ConfigMgr distribution point Properties GUI.

Please note that the "Transfer rate" setting is a Windows Server 2008 WDS only setting. Windows Server 2008 R2 automatically detects the optimal network speeds and sets the transfer rate settings accordingly, so the setting does not apply to Windows Server 2008 R2 WDS. Setting the "Transfer rate" setting on a Multicast Distribution Point running on Windows Server 2008 R2 has no effect.

Resolution

To resolve the problem, the corresponding registry settings for "MultiCast address", "UDP port range", and "Transfer rate" need to be manually set in the registry after they have been set in the "Multicast" tab of the ConfigMgr distribution point Properties GUI window. Since the recommended practice when using ConfigMgr 2007 is to NOT configure WDS manually, the corresponding settings should not be set in the WDS console. Instead the corresponding resgistry settings should be set manually instead.

On the server hosting the Distibution Point role where multicast is being enabled, make sure that WDS is installed and that the "Deployment Server" and "Transport Server" role services are installed. Additionally, make sure that WDS has not be manually configured on the server.
In the ConfigMgr 2007 Admin console, navigate to "Site Management" --> "Site Settings" --> "Site Systems".
Under the "Site Systems" node, click on the applicable server from Step 1 where WDS is installed.
On the right hand pane, rigt click on "ConfigMgr distirbution point" and choose "Properties".
In the "ConfigMgr distribution point Properties" window, click on the "Multicast" tab.
Make sure that the option "Enable Multicast" is checked.
Set all of the appropriate settings under the "Multicast" tab as desired for the environment, even if some of them ("MultiCast address", "UDP port range", and "Transfer rate") do not seem to actually apply.
Click on the "OK" or "Apply" button to ensure that the settings are saved.
On the server from Step 1, open the Registry Editor by starting "regedit.exe".
To manually set the "MultiCast address" and "UDP port range" settings, in the Registry Editor navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Parameters
Map the appropriate settings from the "Multicast" tab of the ConfigMgr distribution point Properties GUI to the corresponding registry settings listed below, and then manually change the value of the registry setting to match the settings configured in Step 7:
- To set the option "Use IP address from the following range" under the "MultiCast address" section:
  - "IPv4 From: " field --> McStartAddr
  - "To: " field --> MCEndAddr
- To set the option "Use UDP ports from the following range:" under the "UDP port range" section:
  - "From: " --> UdpStartPort
  - "To: " --> UdpEndPort
The "Transfer Rate" setting should only be set in Windows Server 2008. It should not be set in Windows Server 2008 R2. To manually set the "Transfer Rate" setting in Windows Server 2008, in the Registry Editor navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC
Change the value of "DefaultProfile" to the desired setting (10Mbps, 100Mbps, 1Gbps, or Custom).
If using Custom, make sure to make the necessary customizations under the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC\Profiles\Custom
Do not make any customizations to any of the built in profiles (10Mbps, 100Mbps, 1Gbps). Use the Custom profile if any customizations are desired.
When the registry settings have been changed and set, restart the "Windows Deployment Services Server" service on the server from Step 1 using the Services console found under Adminsitrative Tools.

Note:
Setting the "Transfer rate" setting on a Multicast Distribution Point running on Windows Server 2008 R2 has no effect. The "Transfer rate" setting is actually only a Windows Server 2008 WDS setting. It does not apply to Windows Server 2008 R2 WDS. Windows Server 2008 R2 automatically detects the optimal network speeds and sets the transfer rate settings accordingly.

Inspecting the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WDSServer\Providers\WDSMC

on a Windows Server 2008 R2 reveals that there is no "DefaultProfile" value. This is normal and the key value should not be created. Please see the following TechNet documentation regarding this setting:

How to Manage Your Server
http://technet.microsoft.com/en-us/library/cc770637(WS.10).aspx#BKMK_1

General Tasks --> To Configure the network profile for the server
"Note that these procedures only apply to the initial release of Windows Server 2008"

IWdsTransportServicePolicy::NetworkProfile Property
http://msdn.microsoft.com/en-us/library/bb736515(VS.85).aspx

"Windows Server 2008 R2: This property is ignored and has no effect. This property is ignored and has no effect. A WDS Transport Server on Windows Server 2008 R2 automatically uses the optimal network profile."

/set-Server
http://technet.microsoft.com/en-us/library/cc816898(WS.10).aspx

Parameter --> /Transport
[/Profile: {10Mbps | 100Mbps | 1Gbps | Custom}] - Specifies the network profile to be used. This option is only supported for servers running Windows Server 2008

/set-TransportServer
http://technet.microsoft.com/en-us/library/cc794752(WS.10).aspx

Parameter
[/Profile: {10Mbps | 100Mbps | 1Gbps | Custom}]
Specifies the network profile to be used. This option is only available for servers running Windows Server 2008 or Windows Server 2003.

For the latest version of the article see the link below:

KB2419357 - WDS Multicast settings in the Distribution Point properties do not seem to apply in System Center Configuration Manager 2007 R2 and R3

J.C. Hornbeck | System Center Knowledge Engineer

↧

Fix: The ConfigMgr 2007 database grows excessively large and DPs do not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings

September 22, 2010, 10:49 am

≫ Next: P2V Migration for Software Assurance Beta 2 now available, including ConfigMgr 2007 integration!

≪ Previous: New KB: WDS Multicast settings in the Distribution Point properties do not seem to apply in System Center Configuration Manager 2007 R2 and R3

You may notice that an unusually large number of System Center Configuration Manager 2007 status messages are generated causing significant growth in database size. Further investigation also shows a large number of these entries repeating over and over again in the distmgr.log:

Compressed files for package xxx hasn't arrived from site xxx

Note: These messages can occur on a normally functioning site. It is only a cause for concern when an excessively large number are repeatedly seen.

This can be caused by the issue documented in the following Knowledge Base articles:

SP1 version: KB978875 - The Distribution Manager does not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings on SCCM 2007 SP1 site servers

SP2 and later version: KB978021 - The Distribution Manager that is in System Center Configuration Manager 2007 SP2 does not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings

To resolve this issue apply the appropriate hotfix referenced above.

Troubleshooting and verification:

You can use this script to determine that the status specific tables are largest in the ConfigMgr database:

http://www.sqlteam.com/article/finding-the-biggest-tables-in-a-database

Then you can use these queries to determine the components generating the most status messages. In this specific scenario you'll find that it is Distribution Manager.

select Component, count(*) from vStatusMessages group by Component order by count(*) desc
select MessageID, count(*) from vStatusMessages group by MessageID order by count(*) desc

ref: http://blogs.technet.com/b/configurationmgr/archive/2009/01/27/troubleshooting-database-growth-issues-in-configuration-manager-2007.aspx

You should find that the SMS_DISTRIBUTION_MANAGER thread has been generating status message ID's 2342, 2300 and 2301 or similar every 5 seconds, repeatedly.

So what's the takeaway from all this?

If you have System Center Configuration Manager 2007 SP1 or later and are doing software distribution then you need this hotfix!

Clint Koenig | Senior Support Escalation Engineer

↧

P2V Migration for Software Assurance Beta 2 now available, including ConfigMgr 2007 integration!

September 27, 2010, 2:01 pm

≫ Next: Announcing the release of the Virtual Machine Servicing Tool (VMST) 3.0

≪ Previous: Fix: The ConfigMgr 2007 database grows excessively large and DPs do not honor the "Number of retries" and "Delay before retrying (minutes)" retry settings

Hey everyone, a few weeks ago we released a beta of the new P2V tool for OS Deployment. We are really pleased to update that information with a beta refresh, Beta 2. The P2V Migration for Software Assurance can now be implemented using System Center Configuration Manager 2007 Operating System Deployment as well as native Lite Touch Installation with the Microsoft Deployment Toolkit 2010. Computer refresh, replace and restore task sequence templates for Configuration Manager are included and documented in this Beta release.

For all the details see Jeff Wettlaufer's original post here.

J.C. Hornbeck | System Center Knowledge Engineer

↧

Announcing the release of the Virtual Machine Servicing Tool (VMST) 3.0

September 28, 2010, 5:44 am

≫ Next: New KB: Users may be unable to view and execute the System Center Configuration Manager 2007 reports hosted on SQL Reporting Services

≪ Previous: P2V Migration for Software Assurance Beta 2 now available, including ConfigMgr 2007 integration!

This release of the Virtual Machine Servicing Tool (VMST) 3.0 completely replaces the Offline Virtual Machine Servicing Tool version 2.1.

VMST 3.0 helps customers reduce IT costs by making it easier to update their offline virtual machines, templates, and virtual hard disks with the latest operating system and application patches—without introducing vulnerabilities into their IT infrastructure.

Version 3.0 of the tool works with System Center Virtual Machine Manager 2008 R2, System Center Configuration Manager 2007 SP2, and Windows Server Update Services 3.0 SP2. The tool also supports updating the Windows® 7 and Windows Server® 2008 R2 operating systems.

For all the details and to download the Virtual Machine Servicing Tool (VMST) 3.0 click here.

J.C. Hornbeck | System Center Knowledge Engineer

↧

New KB: Users may be unable to view and execute the System Center Configuration Manager 2007 reports hosted on SQL Reporting Services

October 4, 2010, 9:38 am

≫ Next: Configuring and using the Courier Sender component in ConfigMgr 2007

≪ Previous: Announcing the release of the Virtual Machine Servicing Tool (VMST) 3.0

Symptoms

Users may be unable to view and execute the System Center Configuration Manager 2007 reports hosted on SQL Reporting Services.
Problem 1: Trying to access http://<SQLServerName>/reports returns blank window.
Problem 2: When trying to execute one of the reports you get the following error:

An error has occurred during report processing. (rsProcessingAborted)

Cannot create a connection to data source '{5C6358F2-4BB6-4a1b-A16E-8D96795D8602}'. (rsErrorOpeningConnection)

For more information about this error navigate to the report server on the local server machine, or enable remote errors.

Cause

This can occur due to a lack of permissions on the Reporting Server and the Database.

Resolution

The basic configuration to allow an end user to view and execute the Configuration Manager Reports hosted via Reporting Services Point are as follows:
1. Create a Global Security Group for users with Read access to the Reports.
2. Add all of the users to this group who need to access to the Reports.
3. Open the Reports website with admin privileges (e.g. http://<SQLServerName>/reports).
4. Click on the Properties Tab > Click on New Role Assignment.
5. In the Group or User name box type in the domain\<GlobalSecurityGroup> you created in step 1.
This will allow those users to view the reports but will fail to execute them. They will get the error described in Problem 2.
To resolve Problem 2 follow the below steps:
1. Add the Global Security Group in SQL using the SQL Server Management Studio Security > Logins > New Login > User Mapping.
2. Check the box for the SCCM DB and Check “db_datareader” role.

For the latest version of the article see the link below:

KB2428400 - Users may be unable to view and execute the System Center Configuration Manager 2007 reports hosted on SQL Reporting Services

J.C. Hornbeck | System Center Knowledge Engineer

↧

Configuring and using the Courier Sender component in ConfigMgr 2007

October 13, 2010, 11:59 am

≫ Next: Announcing Top Solutions RSS Feeds: Automatically connecting you with solutions

≪ Previous: New KB: Users may be unable to view and execute the System Center Configuration Manager 2007 reports hosted on SQL Reporting Services

What is a Courier Sender?

If you ask this question or if you come across this question yourself the very first thing that comes to your mind is someone who ships your packages to your desired destination at your intended time or at your convenience as quickly as possible. So are you wondering why am I talking about shipping of packages or do you have a thought of Microsoft diversifying into logistics field as a means to increase the revenues? Or maybe is Microsoft developing any application to foray into logistics field? Indeed not. It's all about the Courier Sender Component in one of our most renowned infrastructure management Software "Microsoft System Center Configuration Manager 2007".

But now you have the question "What is a Courier Sender" in SCCM 2007 ?

Before I get to this topic let me detail a scenario that is most often experienced while using ConfigMgr 2007 for deployment/distribution across geographical locations. We have come across situations where an administrator wants to deploy a OSD package to their remote site (office/premises) over a WAN link . The scenario is quite normal and usual and you might look at it as a daily task as long as you have a high speed WAN. But what about a slow WAN link? Imagine a more than 2GB package over a 512k WAN link. We have seen administrators waiting for quite a few days for the entire package to reach the remote site which ultimately leads to delays in implementation and not meeting the deadlines, increasing costs and ultimately causing frustration.

Now II know you might have an answer in the form of a faster WAN link as they're getting cheaper all the time, but getting a faster WAN link would disturb your companies IT budget to a great extent. And which company would appreciate an administrator who talks of increasing the cost even by a penny. So what's the answer to a solution that would save you good amount of money and expedite your process in very less expenditure? That's where we come to the point of a very flexible component called Courier Sender.

Senders, as most ConfigMgr 2007 administrators know, is required for Site to Site Communication. Once you install a Secondary Site you configure a Standard Sender for communication between the Primary and Secondary Site. Similarly there is one more kind of Sender known as Courier Sender in SCCM
Why is it called a "Courier" Sender?

The answer to the question lies in the above scenario and I am sure you might have an idea on what I am talking about. With this sender you have the ability to send the OSD package across sites over Physical Media, Removable disk rather than worrying about sending it over your companies slow WAN link. Great, but what does this term "Courier" imply? Well the answer is simple. If your site is too far or say in a different city it would be convenient for you to package that media or removable disk which has the OSD package (WIM file) and call up your local courier company (one of courier sender) to ship it to the desired location. Once the package has reached the location you can work with the local administrator to import the OSD package to the secondary site saving you days or even weeks of waiting over a slow WAN link.

So now you may have a question what is the procedure and how shall I do it? Please see the attached Word document below that has screen shots of the step by step procedure on configuring and using Courier Sender along with some references to a couple helpful TechNet links.

Tushar Thakkar

Courier Sender.doc

↧

Announcing Top Solutions RSS Feeds: Automatically connecting you with solutions

October 13, 2010, 12:46 pm

≫ Next: System Center Configuration Manager 2007 R3 is now available

≪ Previous: Configuring and using the Courier Sender component in ConfigMgr 2007

The Top Solutions RSS feeds pair the latest hot customer issues with the best Microsoft solution content, all delivered right to your desktop. The feeds will help keep you ahead of the curve by alerting you to potential problems and pointing you directly to the solutions. IT Pros, consumers, other Microsoft business groups and third parties are all invited to subscribe to the RSS feed and receive notices when the list is updated monthly.

For Microsoft System Center products we now have the following feeds that are now live:

System Center Configuration Manager

System Center Operations Manager

System Center Data Protection Manager

System Center Virtual Machine Manager

We'll eventually be adding more so stay tuned for all the latest.

J.C. Hornbeck | System Center Knowledge Engineer

↧

System Center Configuration Manager 2007 R3 is now available

October 14, 2010, 10:28 am

≫ Next: Query based collections in ConfigMgr 2007 may fail to refresh after being modified

≪ Previous: Announcing Top Solutions RSS Feeds: Automatically connecting you with solutions

Looks like the System Center product team just announced the release and availability of System Center Configuration Manager 2007 R3:

Organizations of all sizes use System Center Configuration Manager for better insight and control of their servers, PCs and devices across physical, virtual and distributed environments. Now, R3 brings a complete set of power management tools for more Green IT, mobile device management capabilities, as well as other enhancements.

You can get all the details including a link to download the eval version here.

J.C. Hornbeck | System Center Knowledge Engineer

↧

Query based collections in ConfigMgr 2007 may fail to refresh after being modified

October 20, 2010, 6:56 am

≫ Next: The Configuration Manager Documentation Library Update for October 2010 is now live on the web

≪ Previous: System Center Configuration Manager 2007 R3 is now available

Consider the following System Center Configuration Manager 2007 scenario:

You create a query based collection.
You update and refresh that collection and it works correctly.
You go to the properties of that collection and edit the query it uses so that it should display different machines.
You update and refresh the collection.

After doing this the machines in the collection may still reflect the original query and never be updated.

Cause

This is a known issue with the hotfix (KB982400) that can occur when CollEval is overly taxed and thus has no idle time.

The thread performing collection evaluation has a cache of collections that it has processed in the past. It turns out the cache was never used because the evaluator would build a list of collections to process at the beginning and never update the list until the entire list had been processed, at which point the cache was cleared. In the new version of the collection evaluator the list is constantly updated and sorted, meaning that if a collection is processed then put back into the list for evaluation we will now take advantage of the cache and will not read the collection details from SQL. Unfortunately this means that if the collection gets modified the new rules will not be read until the entire list gets emptied out.

Resolution

The issue will resolve itself under two scenarios:

- If the SmsExec service is restarted for any reason (service restart, reboot, etc) then we have to read in the new collection details once it starts back up and the new query will be used.

- The second scenario is that the cache will be cleared any time the collection evaluator becomes idle for any period of time. The CollEval logs the server shows that it is extremely busy, with some collections starting to evaluate 20+ minutes after they were scheduled. We hit this because there is no time between evaluations of the same collection where the service is idle and the cache is cleared.

Alternatively you can use the following method to increase the interval of the updates, giving the process more time to complete:

1. Run GetCollectionRefreshSchedules.vbs to dump the collection refresh schedule to a file.

Syntax: Cscript /nologo GetCollectionRefreshSchedules.vbs SERVER01 S01 > C:\CollSched.txt

Note: SERVER01 -< Name of the SCCM Site Server. S01 -< Site Code of the Site experiencing the problem.

2. Rename CollSched.txt to CollSched.csv.

3. Open the CollSched.csv file with Excel.

4. Select all the column headers and filter.

An example CSV filtered on Update Schedule of Every 59 Minutes looks something like this:

5. Run UpdateHourlySch.vbs (see the attached ZIP file) to increase the schedule interval.

The case I was working on had the most collections updating every 59 minutes so we tweaked the script UpdateHourlySch.vbs to update the schedule from minutes to hours. Once we decided on the most aggressive schedule we could live with we ran UpdateHourlySch.vbs using the syntax below:

Cscript /nologo UpdateHourlySch.vbs <Site Code> <Current Schedule> <New Schedule>

In our example, we used the following:

Cscript /nologo UpdateHourlySch (Mins to hrs version).vbs Site1 59 3

6. Restart the SmsExec service.

Note: This doesn't seem to affect machines added to the collection as a direct member, only query based collections.

As with all scripts we provide, these are samples given for demonstration purposes only and provided as-is with no guarantees, etc. It is your responsibility to test and determine their suitability to your environment.

ScheduleScripts.zip

Hope this helps,

Anshul Srivastava | Support Engineer – System Center Support

↧

The Configuration Manager Documentation Library Update for October 2010 is now live on the web

October 20, 2010, 1:18 pm

≫ Next: OSD: How to add a script to a ConfigMgr 2007 Boot Image

≪ Previous: Query based collections in ConfigMgr 2007 may fail to refresh after being modified

Coming from the System Center Configuration Manager documentation team is news that the Configuration Manager documentation library (http://technet.microsoft.com/en-us/library/bb680651.aspx) has been updated on the Web with updates from September and R3 content in October. Topics that were updated for September have Updated: September 1, 2010 at the top of the topic and topics that were updated or created for R3 have Updated: October 14, 2010 at the top of the topic.

There will be a new version of the help file available for download with the Help File Updater soon - stay tuned.

Although we can't promise to make the docs perfect for everybody, we are committed to continual improvement. So, keep that feedback coming, and feel free to contact us about anything related to the documentation by using our usual address of SMSDocs@Microsoft.com.

For all the details including What's New in the Configuration Manager Documentation Library for September 2010 see Announcement: Configuration Manager Documentation Library Update for October 2010.

J.C. Hornbeck | System Center Knowledge Engineer

↧

OSD: How to add a script to a ConfigMgr 2007 Boot Image

October 21, 2010, 11:27 am

≫ Next: Troubleshooting Duplicate or Missing SPNs for a ConfigMgr 2007 SQL Database

≪ Previous: The Configuration Manager Documentation Library Update for October 2010 is now live on the web

One of the components of System Center Configuration Manager 2007 (SCCM 2007) Operating System Deployment (OSD) is boot images. Boot images in SCCM are really just WinPE images and are used during the operating system deployment process to boot computers so that an operating system can be loaded.

For more information about boot images and WinPE, see the following links:

What is Windows PE?

Planning for the Boot Image

Background

Typically, the standard boot images included in SCCM will provide enough functionality needed to deploy an Operating System, (outside of possibly adding drivers). In some cases, it may be required for administrators to have a script or a command run when the boot image boots and WinPE is started. As an example, one customer, due to specific network restrictions, had to run a command when WinPE started so that a specific route could be added in order for the client to reach the server. The customer created a batch file to run the command and configured WinPE to execute it at every start time, before WinPE started the task sequencing process.

Out of the box, it is not very straightforward to add such customizations to your boot images, so the purpose of this article is to provide information on how to add a batch file or command so that it is executed when your boot image starts.

As a note, there was an article provided in TechNet which describes the process of modifying WinPE to add a script or batch file so that it would be executed when WinPE started. Unfortunately, in SCCM, when boot images are updated so that drivers can be injected or settings are modified, the update process is automated so there isn’t an opportunity to make other customizations. The article I am referring to is http://technet.microsoft.com/en-us/library/cc766521(WS.10).aspx, which provides three ways to add a command to WinPE. The first two methods, using Winpeshl.ini, or Startnet.cmd, don’t work in SCCM. The third method, creating an unattend.xml, will work fine.

This article describes how to create an unattend.xml so that specific commands or scripts can be executed every time your WinPE boot image starts.

Step One: Determine the Script or Command to be Run

The first thing you need to do is figure out if you need to run a command, batch file, or vbScript prior to WinPE executing. The unttend.xml is command based, and you can add multiple commands ordered in any way you like. If you have more than one command you want to run you can certainly add those to a batch file.

If you are going to reference a batch file create the file and copy it to the SCCM Site Server at: C:\Program Files\Windows AIK\Tools. In this example, I will name the batch file PrePE.cmd.

Step Two: Create the Unattend.xml

The easiest way to create an unattend.xml from scratch is to use System Image Manager. After you create your initial unattend.xml for use in this process, you may decide to edit the XML using notepad. Regardless, the below instructions will describe how to use Windows System Image Manager (SIM) to create an unattend.xml so that WinPE will execute a command or the PrePE.cmd file at WinPE startup.

1. Logon to your SCCM SP2 site server as the Windows System Image Manager utility will already be installed. Note: The reason it is already installed is because (SIM) is included in the WAIK which is installed with SCCM.

2. Open SIM by selecting Start – Programs - Microsoft Windows AIK – Windows System Image Manager.

3. In the SIM select File – Select Windows Image.

4. At the Select a Windows Image dialog, browse to the extracted contents of your Windows 7 DVD\Sources folder and select install_Windows 7 ULTIMATE.clg (Enterprise) and then click Open.

5. One an image catalog is selected, create a new answer file by selecting File – New Answer File.

6. Under the Windows Image section in the SIM, navigate to Components and right-click x86_Microsoft-Setup_6.1.x_neutral and in the context menu select Add Setting to Pass 1 windowsPE.

7. Now in the Answer File section of the SIM, you will see the component under windowsPE. Select x86_Microsoft-Windows-Setup_neutral and in the Properties pane, change the Enable Firewall value to True.

8. Right-click the RunSynchronous section and in the context menu, select Insert New RunSynchronousCommand.
In the Properties section, verify the following Properties are set.

Action: AddListItem
Description: Executes the PrePE.cmd
Order: 1
Path: PrePE.cmd

9. Once all the Properties are added you can delete all of the sub-components which were not edited.

10. To save the answer file select File – Save Answer File As and save the file under C:\Program Files\Windows AIK\Tools as unattend.xml.

11. If you open the XML in notepad you can make modifications.

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="windowsPE">
        <component name="Microsoft-Windows-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <RunSynchronous>
                <RunSynchronousCommand wcm:action="add">
                    <Description>Executes the PrePE.cmd</Description>
                    <Order>1</Order>
                    <Path>PrePE.cmd</Path>
                </RunSynchronousCommand>
            </RunSynchronous>
            <EnableNetwork>true</EnableNetwork>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="catalog://labcm1/osdeploy/ossource/windows7x86/sources/install_windows 7 ultimate.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

Adding the PrePE.cmd and Unattend.xml to your Boot Images

The following technique is an easy way to add files to your boot images without having to mount and unmount your boot.WIMs. For background purposes, every time you select “Update Distribution Points” for you boot images in SCCM, the boot image is mounted, files are injected, unmounted, and distribution points are updated. One of the files SCCM uses to identify files to add is the osdinjection.xml. You can edit this file to reference custom files you want included in your boot image.

1. On your SCCM site server, navigate to <SCCM Installation Folder>\bin\i386.

2. Make a backup copy of the file osdinjection.xml.

3. Edit the original osdinjection.xml in Notepad and under the following section:

<?xml version="1.0" encoding="utf-8"?>
<InjectionFiles>
<Architecture imgArch="i386">
<FileList source="WAIK">

Add the following:

<File name="unattend.xml">
<LocaleNeeded>false</LocaleNeeded>
<Source>tools</Source>
<Destination>windows\system32</Destination>
</File>
<File name="prePE.cmd">
<LocaleNeeded>false</LocaleNeeded>
<Source>tools</Source>
<Destination>windows\system32</Destination>
</File>

Here is a sample:

4. As you can see, the two files we added to C:\Program Files\Windows AIK\Tools, unattend.xml and PrePE.cmd are referenced, and will be copied to the Windows\System32 folder in WinPE.

5. So that the files are also executed in the 64-bit boot image, find the section:

Add the following:

6. Save the osdinjection.xml file.

7. In Configuration Manager 2007, navigate to Site Database / Computer Management / Operating System Deployment / Boot Images and right-click your boot image and select “Update Distribution Points”. The boot images will be recompiled and sent to distribution points.

Summary

You can test the boot image right away if you are using PXE Boot or use the Create Task Sequence Media and create boot media. The next time the boot image boots, the batch file PrePE.cmd will run prior to the Task Sequence engine kicks off.

Gerry Borger | Senior System Center Support Engineer

↧

Troubleshooting Duplicate or Missing SPNs for a ConfigMgr 2007 SQL Database

October 26, 2010, 5:49 am

≫ Next: Error “The WebDAV server extension is either not installed or not configured properly” in Configuration Manager 2007

≪ Previous: OSD: How to add a script to a ConfigMgr 2007 Boot Image

This blog post addresses a common problem customers face during the installation of System Center Configuration Manager 2007 in which the following error appears: “Setup failed to install SMS Provider.” When this error occurs, there are several possible causes, but the first thing I check is Service Principal Names or SPNs.

Background

When setting up SQL Server for System Center Configuration Manager you can configure SQL services to use the local SYSTEM account or a domain user account. In either case, a Service Principal Name needs to be registered in Active Directory, but in the case where a domain user account is used for SQL Services, manual registration is typically required. It is important that the SPN be registered prior to installing SCCM, as the installation will fail.

This article will provide the steps required to register the SPN, but before covering that check out the symptoms of a SPN problem below.

Symptoms

One of the clearest indications that there is a problem with the SPN is during the SCCM installation.

For example, if the SQL SPN is not properly registered, and you choose to install the SMS Provider on the SCCM site server, the installation will fail during the installation of the SMS Provider. See the example below:

It is possible to bypass this error by choosing to install the SMS Provider on the SQL server which in an option during the SCCM installation, but it does not resolve the SPN problem after the fact.

For example, if you install the SMS Provider on the SQL server, and you have an SPN problem you may see the following errors:

In the SCCM console navigate to Site Database <Site Name> – Tools and right-click the ConfigMgr Service Manager and select Start ConfigMgr Service Manager.

If you receive the error “Error communicating with the specified ConfigMgr Site Server” there is definitely an issue.

Another symptom you will have is that multiple errors will show up in your SQL Server Logs.

On the SQL Server open Microsoft SQL Server Management Studio and connect to the instance in which you installed SCCM.

In the SQL console, navigate to Management – SQL Server Logs and right-click the Current log and select “View SQL Server Log”.

In the SQL server log you will see multiple errors similar to this:

03/06/2009 12:09:54,Logon,Unknown,Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. [CLIENT: 192.168.1.11]

Another place to look is SMSDBMON.log file on your SCCM server. You will see errors such as:

*** [28000][18456][Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. $$<SMS_DATABASE_NOTIFICATION_MONITOR>
*** [28000][18456][Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. $$<SMS_DATABASE_NOTIFICATION_MONITOR

*** Failed to connect to the SQL Server. $$<SMS_DATABASE_NOTIFICATION_MONITOR>
CTriggerManager::Init - unable to get SQL connection $$<SMS_DATABASE_NOTIFICATION_MONITOR>

NOTE: In cases where SQL reports NT AUTHORITY\ANONYMOUS LOGON failures, it is typically due to SPN or Kerberos issues.

Discovery

To properly register a Service Principal Name for SQL you need two pieces of information:

· Which account is SQL running under?

· What port is SQL running under?

To Find which account SQL is running under:

In the case where the SQL service is configured to run as SYSTEM, it is likely that you don’t have an SPN issue, but in some cases the SCCM administrator may not know what account SQL is running under.

To check what account SQL services are running under:

1. Logon to the SQL server and open Start – All Programs – Microsoft SQL Server 20xx – Configuration Tools and select SQL Server Configuration Manager.

2. In SQL Server Configuration Manager – Select the SQL Server Services node.

3. In the Details pane, right-click the SQL Server (Instance) name and in the context menu, select Properties.

4. In the SQL Server (instance) Properties dialog, within the Log On tab, if “This account” is selected, then it is likely that a domain user account is listed. Note the domain user account listed in the Account Name field.

5. If the “Built-in account” option is selected, then typically “Local System” is selected and an SPN may already be registered.

To Find what Port SQL is Running Under:

1. Logon to the SQL server and open Start – All Programs – Microsoft SQL Server 20xx – Configuration Tools and select SQL Server Configuration Manager.

2. In SQL Server Configuration Manager – Select the SQL Server Network Configuration node and select the sub-node Protocols for <SQLInstance>

3. In the details pane, select TCP/IP and select Properties.

4. At the TCP/IP Propertied dialog, select the IP Addresses tab and scroll down to the IPAll section. The value of TCP Port is the port number SQL is running under.

Important Note:

If SQL is configured to use the default instance, the port should be statically defined as port 1433.

If using a SQL named instance, the port should be listed as “TCP Dynamic Ports” and will change every time SQL is restarted. This can pose a problem when registering an SPN as the port will change.

Verification

How to you check whether an SPN is registered? There are two tools you can use to check and list Service Principal Name.

Setpn.exe or ADSIedit.

How to Check SPNs Using SetSPN.exe:

This utility is installed natively in Windows Server 2008, but if running Server 2003 you have to install the Server 2003 SP1 Support Tools. A link to the Server 2003 SP1 Support Tools download can be found within this page.

If using the Local SYSTEM account for for SQL, you can use the following command to check SPNs against the server.

setspn –l MSSQLSvc/<SQLSERVERNAME>

If using a domain user account for SQL, you can use the following command to check SPNs against the server.

setspn –l domain\useraccount

How to Check SPNs Using ADSIEdit.msc:

This utility not installed natively in Windows Server 2008. You can install it by opening Server Manager, select and then right-click Features and click Add Features. Select Remote Server Administration Tools – Role Administration Tools – Active Directory Domain Services Tools and check Active Directory Domain Controller Tools.

Complete the Add Features Wizard.

If running Server 2003, you will need to install but if running Server 2003 you have to install the Server 2003 SP1 Support Tools. A link to the Server 2003 SP1 Support Tools download can be found within this page.

To check SPNs, open Adsiedit.msc and right-click the ADSI Edit node and select “Connect to…”

At the Connection Settings dialog, click OK.

· If using the Local SYSTEM account, navigate and select the OU which contains the SQL computer account and in the details pane, right-click the computer account and select Properties.

· If using a domain user account for SQL, navigate and select the OU which contains the domain user account and in the details pane, right-click the user account and select Properties.

In the Properties dialog, scroll down to the Service Principal Name attribute. You can select the Edit button to review the list of Service Principal Names registered against the account.

Resolution:

The following SPNs need to be registered for Configuration Manager to function:

MSSQLSvc/servername:port

MSSQLSvc/servername.domain.com:port

Where servername is the NETBIOS name of the SQL server, and servername.domain.com is the FQDN of the SQL Server. Port is the port number which SQL is using.

Example: MSSQLSvc/SQLServer.domain.com:1433

Scenarios:

If using Local System for SQL Services, just check to make sure the SPN is registered. It is unlikely you will need to change anything because the computer account usually has enough permissions to update its own SPN.

If using a Domain User Account for SQL Services, and SQL is installed using the Default instance and the port is 1433 run the following SetSPN.exe command:

setspn.exe –A MSSQLSvc/servername:1433 domain\sqlserviceaccount

setspn.exe –A MSSQLSvc/servername.domain.com:1433 domain\sqlserviceaccount

If using a Domain User Account for SQL Services, and SQL is installed using a Named instance and the port is set as Dynamic, you can use ADSIEdit to grant the user account permissions to update its own SPN. This is recommended.

To configure the domain user account to update its own SQL SPN:

1. Open ADSIEdit.msc and navigate and select the OU which contains the domain user account.

2. In the Details pane, select the domain user account and select Properties.

3. At the user account Properties dialog, select the Security tab.

4. Select the Advanced button.

5. At the Advanced Security Settings for <user> dialog, select the SELF account and select Edit.

6. At the Permission Entry for <user> properties, select the Properties tab.

7. Scroll down and verify that Allow is checked next to Read servicePrincipalName and Write servicePrincipalName is selected.

8. Click OK, OK and then OK to save the settings.

9. Restart the SQL Services, and you should be able to check the SPN against the domain user account and it should be updated.

Once the Service Principal Name is set, you may have to wait for domain synchronization to occur.

Restart the server which Configuration Manager 2007 is going to be installed on to clear Kerberos tickets.

Troubleshooting:

If the above errors still persist, and you are certain the SPN was registered successfully, you may have a duplicate record in AD. You can check for duplicates by running this command:

ldifde –f C:\SPNCheck.txt -t 3268 -d "" -l servicePrincipalName -r "(servicePrincipalName=MSSQLSvc/servername*)" -p subtree

The MSSQLSvc/servername* portion of the above command should be edited to include the server name of your SQL server.

The command will return all SPNs with the string MSSQLSvc/servername* and write the results to the text file: C:\SPNCheck.txt.

Here is an example of a duplicate SPN in the results in the SPNCheck.txt file:

dn: CN=Administrator,CN=Users,DC=gb,DC=net
changetype: add
servicePrincipalName: MSSQLSvc/servername.domain.com:1433

dn: CN=s-sqladmin,OU=Admin,DC=gb,DC=net
changetype: add
servicePrincipalName: MSSQLSvc/servername.domain.com:1433

As you can see, the same SPN is registered against the domain\Administrator and the s-sqladmin accounts.

This is a duplicate as the SPN registered against the Administrator account is no longer needed.

To delete the incorrect SPN run the command:

setspn.exe –D MSSQLSvc/servername.domain.com:1433 domain\administrator

Conclusion:

I hope that this blog entry was helpful. If there is something missing, please comment.

Here are some links to Microsoft articles which may provide some background on the subject:

Systems Management Server 2003 Advanced Security Site with Remote SQL Does Not Connect to SQL Server

Security Account Delegation

Gerry Borger | Senior System Center Support Engineer

↧

Error “The WebDAV server extension is either not installed or not configured properly” in Configuration Manager 2007

October 26, 2010, 1:19 pm

≫ Next: Information on the ConfigMgr 2007 client side process for Software Updates

≪ Previous: Troubleshooting Duplicate or Missing SPNs for a ConfigMgr 2007 SQL Database

We have seen couple of cases on this issue here in product support recently and since I didn't see the information documented on our site anywhere I thought it would be worth a mention here.

Issue:

The SMS Site Component Manager fails to install the SMS_MP_CONTROL_MANAGER component on a Windows Server 2008 based computer. The error is as follows:

The WebDAV server extension is either not installed or not configured properly.
Solution: Make sure WebDAV is installed and enabled. Make sure there is an authoring rule that allow “All users” read access to “All content”. Make sure the WebDAV settings “Allow anonymous property queries” and “Allow property queries with infinite depth” are set to “true” and “Allow Custom Properties” is set to false.

If you go to the IIS management console, connect to the local server and open the “WebDAV Authoring Rules” option you will find everything enabled but it still doesn't seem to recognize it.

Cause:

This can occur if the settings for the WebDAV Authoring Rules become out of sync with the WebDAV_schema.xml file.

Resolution:

We need to go the location of the configuration file of Webdav which is C:\Windows\System32\inetsrv\config\schema\WebDAV_schema.xml. After opening this file you may notice that the settings in this file were different from the settings that were configured in the IIS Manager. The settings were configured as:

However they should be:

After correcting these settings (remember we have to take ownership of the file to be able to change it) and restarting the World Wide Web Publishing Service and the SMS_SITE_COMPONENT_MANAGER the Management Point should install correctly. You can check if the installation is successful in the log file MPSetup.log in your SCCM\Logs directory. If successful the log should have entries similar to this:

<04-01-2010 13:15:58> ======== Completed Installion of Pre Reqs for Role SMSMP ========
<04-01-2010 13:15:58> Installing the SMSMP
<04-01-2010 13:15:58> Passed OS version check.
<04-01-2010 13:15:58> IIS Service is installed.
<04-01-2010 13:15:58> checking WebDAV configuraitons
<04-01-2010 13:15:58> WebDAV is configured
<04-01-2010 13:15:58> No versions of SMSMP are installed. Installing new SMSMP.
<04-01-2010 13:15:58> Enabling MSI logging. mp.msi will log to E:\SCCM\logs\mpMSI.log
<04-01-2010 13:15:58> Installing E:\SCCM\bin\i386\mp.msi CCMINSTALLDIR="E:\SMS_CCM" CCMSERVERDATAROOT="E:\SCCM" USESMSPORTS=TRUE SMSPORTS=80 USESMSSSLPORTS=TRUE SMSSSLPORTS=443 USESMSSSL=TRUE SMSSSLSTATE=0 CCMENABLELOGGING=TRUE CCMLOGLEVEL=1 CCMLOGMAXSIZE=1000000 CCMLOGMAXHISTORY=1
<04-01-2010 13:16:32> mp.msi exited with return code: 0
<04-01-2010 13:16:32> Verifying CCM_CLIENT virtual directory.
<04-01-2010 13:16:32> Website path is IIS://LocalHost/W3SVC/1.
<04-01-2010 13:16:32> Connecting to IIS.
<04-01-2010 13:16:32> CCM_CLIENT is currently E:\SCCM\Client.
<04-01-2010 13:16:32> Installation was successful.

Note: As you do any time you modify an XML file, please make a backup of WebDAV_schema.xml before making changes to it.

As an alternative resolution you can also run the following commands:

C:\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/" /section:system.webServer/webdav/authoring /enabled:true /commit:apphost

C:\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/" /section:system.webServer/webdav/authoringRules /allowNonMimeMapFiles:true /commit:apphost

C:\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/" /section:system.webServer/webdav/authoringRules /+[users='*',path='*',access='Read'] /commit:apphost

C:\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/" /section:system.webServer/webdav/authoring /fileSystem.allowHiddenFiles:true /properties.allowAnonymousPropfind:true /properties.allowInfinitePropfindDepth:true /properties.allowCustomProperties:false /commit:apphost

Then just restart the World Wide Web Publishing Service and the SMS_SITE_COMPONENT_MANAGER and the Management Point should install correctly.

Hope this helps!

Ankur Srivastava

↧