Image may be NSFW. Clik here to view. Here's a ConfigMgr 2007 issue I had recently that was caused by an known issue with IIS. I wanted to publicize this here so that it might help others who run into this problem.
Issue:
Configuration Manager 2007 clients may fail to download packages from a Server Share Distribution Point with a content hash mismatch error if using BITS/HTTP. You may see the following errors in the cas.log and contenttransfermanager.log:
CAS.Log: Download completed for content PackageGUID.X under context System 3/25/2010 12:31:21 AM 2096 (0x0830) Failed to instantiate UI Server {SOMEGUID1} with error 8000401a 3/25/2010 12:31:21 AM 2096 (0x0830) Failed to instantiate UI Server 2 {SOMEGUID2} with error 8000401a 3/25/2010 12:31:21 AM 2096 (0x0830) Failed to instantiate Updates UI Server {SOMEGUID3} with error 8000401a 3/25/2010 12:31:21 AM 2096 (0x0830) Failed to instantiate VApp UI Server {SOMEGUID4} with error 0x8000401A 3/25/2010 12:31:21 AM 2096 (0x0830) There are 0 files in the directory compared to 1 expected files 3/25/2010 12:31:21 AM 2096 (0x0830) Hash does not match expected <Content ContentId="PackageGUID" Version="X"><FileContent Name="Package Name" Hash="SomeHashValuenumber" HashAlgorithm="SHA1" Size="513400"/></Content>, actual 3/25/2010 12:31:21 AM 2096 (0x0830) Hash matching failed. 3/25/2010 12:31:21 AM 2096 (0x0830) Download failed for content PackageGUID.X under context System, error 0x80091007 3/25/2010 12:31:21 AM 2096 (0x0830)
So it thinks it downloaded, but it really did not, and the clients cache is not populated with the package ID named folder so this explains why the hash mismatch occurs.
ContentTransferManager.log: CTM job {SOMEGUID} successfully processed download completion. 3/25/2010 12:31:34 AM 3500 (0x0DAC) CTM encountered error processing reply from DTS. Code 0x80040215 3/25/2010 12:33:06 AM 3084 (0x0C0C)
So it actually showed a download complete, then it gave the error above.
Cause:
There is a known issue with IIS 6.0 WEBDAV that occurs when the Virtual Directory points to the root of the drive as the path, such as Z:\. This causes our failure above.
Resolution:
The workaround is to create a folder on the drive and share that to create the DP Server share instead.
In this case there were already many servers configured by sharing out the Z:\ drive and configured for use as a Remote Server Share DP in Configuration Manager 2007. Also, all the packages were already replicated to the Z:\SMSPKG folder on those remote servers, so all the packages multiplied by the number of servers added up to a lot of man-hours. It was going to take a long time to recreate this from scratch and redistribute all the packages again.
Instead of recreating everything, we devised a workaround that would still involve moving the SMSPKG folder from the root of Z:\ to a newly created folder Z:\packages and then deleting and recreating the packages share on the remote server so that the Z:\packages folder is shared as packages instead of the root of the Z:\ drive. We would then modify the path on the SMS_DP_packages virtual directory so that it points to the Z:\packages folder instead of the root of the Z:\, which was the configuration that was not working. So having to do this on 99 servers was still a challenge, but by our estimates would be less work than starting over from scratch, and it worked as expected.
So this allows the ConfigMgr 2007 settings to remain the same, as the actual share path that the packages are deployed to from the Primary site server remains the same (\\servername\packages\SMSPKG) and this resolves/works around the IIS 6 issue by changing the virtual directory properties to point to a folder on the drive rather than the root of the drive.
We tested this with the copying of one package to the new Z:\packages folder and sharing it as packages instead of the root of the Z:\ drive on one remote DP, and modifying the virtual directory to point to the Z:\packages folder. After doing this the client was able to successfully download the package using HTTP and it executed successfully without a hash mismatch error.
Additional Information and Resources:
I found some documentation that indicates you should use a folder rather than the root of a drive as Server Share DP this on this site:
"Administrator must manually create a shared folder before creating the new site system server share."
It mentions create a shared folder, not a shared drive, so it would seem this is documented, but it does not point out that if you use the root of a drive it will break BITS/HTTP transfers.
Here's an issue we still seem to see on a fairly regular basis here in support so I thought it might be worth a mention here in case you happen to run into it.
Issue: When attempting to deploy an operating system using OSD in System Center Configuration Manager 2007, the Task Sequence may fail with the following error:
There are no task sequences available for this computer.
If you look in the SMSTS.log you may also see the following error:
No assigned task sequence. Setting wizard error: There are no task sequences available for this computer.
The SMSTS.log may also show the SMBIOS GUID as follows:
Note: Analyzing the Advertisement and the Collection confirms that the target computer is in the proper Collection that the Advertisement is pointing to. Deleting the computer from the SCCM database and re-adding it back to the SCCM and the Collection via the Import Computer Information wizard using the MAC address or SMBIOS GUID does not resolve the problem.
Cause:The issue can be caused by there being more than one computer in the environment with the same SMBIOS GUID (aka System UUID). Similar to MAC Addresses, SMBIOS GUIDs should be unique on each computer and no two computers should have the same SMBIOS GUID. The SMBIOS GUID is stored in the computer's BIOS. Do not confuse the SMBIOS GUID with the SMS GUID. These are two separate, different, and distinct items.
The problem occurs because when the SCCM database is queried for available Task Sequences that are advertised to that PC, it does so first by using the computers SMBIOS GUID. Each record in the SCCM database records the computers SMBIOS GUID under the field System UUID. If it does not match a record with the SMBIOS GUID, it then uses the MAC Address.
However, if multiple computers exist in the environment and are in the SCCM database with the same SMBIOS GUID, it may find the record for a PC other than the one where the Task Sequence is trying to be initiated. It will then query policy for that other PC, and if that other PC does not have a Task Sequence advertised to it, it will return back that there are no task sequences available for this computer.
Resolution: To see if this problem exists in your environment, create a query or collection in SCCM based on the suspected duplicate SMBIOS GUID. If more than one computer has the same SMBIOS GUID then the problem exists in the environment and needs to be fixed at a hardware level. You will need to contact the OEM vendor for a fix.
Additional Information: The SMBIOS GUID can be found in the SMSTS.log in the line:
"Setting SMBIOS GUID = "
It can also be found by inspecting the SMSPXE.log as the PC tries to PXE boot. In addition, it can also be obtained by hitting the Pause/Break key on the keyboard on the affected PC at the PXE boot screen. The SMBIOS GUID should be displayed somewhere on that screen.
Image may be NSFW. Clik here to view. When deploying a WIM file that contains both a Windows OS image and a Data image in the WIM file, the deployment may fail when using an SCCM 2007 OSD Task Sequence with the following logged in the SMSTS.LOG file:
Opening image file C:\_SMSTaskSequence\Packages\<WIM_Image_Package_ID>\<Image>.wim ApplyOperatingSystem Image file <WIM_Image_Package_ID> version "" will be applied ApplyOperatingSystem Image does not contain OS architecture information. Unable to verify that the OS will be compatable with the target machine. ApplyOperatingSystem Starting to apply image <Image_Index> from <Image>.wim to C:\ ApplyOperatingSystem 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 Applying image to C:\ ApplyOperatingSystem Applying image <Image_Index> to volume C: ApplyOperatingSystem Successfully applied image to C:\ ApplyOperatingSystem pOs != NULL, HRESULT=80070490 (e:\nts_sms_fre\sms\framework\osdcore\offlineos.cpp,92) ApplyOperatingSystem Unable to find a Windows system root at C:\. Element not found. (Error: 80070490; Source: Windows) ApplyOperatingSystem OSD::Utility::OfflineOS::CreateInstance( this->targetVolume, true, rpNewOs), HRESULT=80070490 (e:\nts_sms_fre\sms\client\osdeployment\applyos\installimage.cpp,395) ApplyOperatingSystem this->getTargetOs(pNewOs), HRESULT=80070490 (e:\nts_sms_fre\sms\client\osdeployment\applyos\installimage.cpp,892) ApplyOperatingSystem Failed to find the system root for the applied OS. Element not found. (Error: 80070490; Source: Windows) ApplyOperatingSystem SetupNewOs(), HRESULT=80070490 (e:\nts_sms_fre\sms\client\osdeployment\applyos\installimage.cpp,1434) ApplyOperatingSystem Configure(), HRESULT=80070490 (e:\nts_sms_fre\sms\client\osdeployment\applyos\installimage.cpp,1465) ApplyOperatingSystem Installation of image 2 in package <WIM_Image_Package_ID> failed to complete.. Element not found. (Error: 80070490; Source: Windows) ApplyOperatingSystem installer.install(), HRESULT=80070490 (e:\nts_sms_fre\sms\client\osdeployment\applyos\installimage.cpp,1527) ApplyOperatingSystem Closing image file C:\_SMSTaskSequence\Packages\<WIM_Image_Package_ID>\<Image>.wim ApplyOperatingSystem Entering ReleaseSource() for C:\_SMSTaskSequence\Packages\<WIM_Image_Package_ID> ApplyOperatingSystem reference count 1 for the source C:\_SMSTaskSequence\Packages\<WIM_Image_Package_ID> before releasing ApplyOperatingSystem Released the resolved source C:\_SMSTaskSequence\Packages\<WIM_Image_Package_ID> ApplyOperatingSystem InstallImage( g_InstallPackageID, g_ImageIndex, targetVolume, ImageType_OS, g_ConfigPackageID, g_ConfigFileName, bOEMMedia ), HRESULT=80070490 (e:\nts_sms_fre\sms\client\osdeployment\applyos\applyos.cpp,373) ApplyOperatingSystem Process completed with exit code 2147943568 TSManager !--------------------------------------------------------------------------------------------! TSManager Failed to run the action: Apply Operating System. Element not found. (Error: 80070490; Source: Windows) TSManager
The execution of the group (Install Operating System) has failed and the execution has been aborted. An action failed. Operation aborted (Error: 80004004; Source: Windows) TSManager Failed to run the last action: Apply Operating System. Execution of task sequence failed. Element not found. (Error: 80070490; Source: Windows) TSManager
Cause
The problem can occur if the incorrect image is trying to be applied during the "Apply Operating System Image" task. At the "Apply Operating System Image" task, an image that contains a Windows OS needs to be selected. If a data image is selected instead, the errors will occur. To apply data images, use the "Apply Data Image" task.
The problem usually occurs because of an error in selection when setting up the Task Sequence. If the WIM file selected at the "Apply Operating System Image" task contains multiple images, including at least one Windows OS image and at least one Data image, the image index with the Windows OS needs to be selected. If the image index with the Data image is selected instead, then the error will occur.
Note that the GUI for the "Apply Operating System Image" task does not check if the appropriate image has been selected, nor does it indicate which image index is the one that contains the Windows OS. However steps can be taken to make this determination.
Resolution
1. In the SCCM 2007 Admin Console, under the "Computer Management" --> "Operating System Deployment"--> "Operating System Images"node, right click on the Windows 7 image being deployed and choose "Properties".
2. Click on the "Images" tab.
3. Under the option "Select image you want to view:", switch between the different images (i.e., "1-1" or "2-2") that are contained in the WIM file. Determine which image, i.e. 1-1 or 2-2, contains the Windows installation. The image that contains the Windows installation will have information next to the fields "OS version", "Architecture", "HAL Type", and "Description". The non-Windows data image will not have anything next to these fields.
4. Click on the "OK button.
5. In the SCCM 2007 Admin Console, under the "Computer Management" --> "Operating System Deployment"--> "Task Sequences"node, right click the affected Task Sequence and choose “Edit”.
6. Select the "Apply Operating System" task.
7. Under the "Apply operating system from a captured image" option, make sure that the "Image:" drop down menu is set to the Windows installation image as determined in Step 3 (i.e., "1-1" or "2-2").
8. Click on the "OK" button to save the changes to the Task Sequence.
Image may be NSFW. Clik here to view. On a site server that is running System Center Configuration Manager 2007 Service Pack 2 (SP2), the handle count and memory usage for the SMS_Executive service (Smsexec.exe) process keeps increasing. After a while, the available memory resources may be exhausted on the site server. When the operating system does not have sufficient memory resources, the operating system may crash, stop responding, or encounter other exceptions on the site server. This issue usually occurs when the site server performs one or more of the following operations:
Processes the software inventory files.
Processes the hardware inventory files.
The Client Push Installation feature is enabled, and one of the following conditions is true:
The user account that performs the client push installation is not a member of the Administrators group.
The user account that performs the client push installation cannot be used to access the folder where the Smsexec.exe file is located because of a configuration on the site server.
The destination computer of the client push installation crashes or is not available.
For more information and to download a hotfix for this issue see the following Knowledge Base article:
KB981797 - The handle count and memory usage of Smsexec.exe keeps increasing in System Center Configuration Manager 2007 SP2
A package cannot be updated successfully on a Branch DP (BDP) and the Peerdpagent.log shows the following:
Package ABC00001 in state 'DownloadComplete'. 6/9/2010 11:42:55 AM 3800 (0x0ED8) Raising event: [SMS_CodePage(437), SMS_LocaleID(1033)] instance of PDPHashMismatchEvent { ClientID = "GUID:00354A37-DA07-43CA-A8F3-A45203669D2D"; DateTime = "20100609184258.503000+000"; MachineName = "ComputerName"; PackageID = "ABC00001"; ProcessID = 2068; SiteCode = "ABC"; SourceVersion = 2; ThreadID = 3384; }; 6/9/2010 11:42:58 AM 3384 (0x0D38) Successfully submitted event to the Status Agent. 6/9/2010 11:42:58 AM 3384 (0x0D38) Package ABC00001 in state 'HostingIncomplete'. 6/9/2010 11:42:58 AM 3384 (0x0D38)
Every indication is that this is hash mismatch, however, testing shows that the hash matches, and the directory contents are exactly the same on the Source, DP, and BDP, the only indication of the hash mismatch is in the peerdpagent.log
Also note that the package does complete downloading, even though it shows the PDPHashMismatchEvent and HostingIncomplete status.
Cause
This can occur if there is a trailing backslash on the share name path of the package properties.
Resolution
Remove the trailing back slash on the share name path on the package properties or do not use a trailing back slash during package creation. If you are changing this after the package has already been created, update the Branch DP and this should resolve this issue. This problem seems to affect only Branch Distribution Points, not regular Distribution Points.
Clifton Hughes | Senior System Center Support Engineer
Image may be NSFW. Clik here to view.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 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.
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.
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.
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.
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…”
· 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.
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:
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.
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:
Image may be NSFW. Clik here to view.I just wanted to let everyone know that we recently updated Knowledge Base article 925282 to include System Center Configuration Manager 2007. In all honesty it always applied but before now we really didn't make that entirely clear, so if you've seen the article before the contents are largely the same it just now applies to the ConfigMgr 2007 as well. Considering how many potential client install issues this article resolves you really should have it filed away for easy reference.
Image may be NSFW. Clik here to view.Being on the support side of the business, we often get a variety of questions concerning various error codes and what they mean. After all, these codes can be invaluable when troubleshooting an issue because with a little research they'll often tell you exactly what's wrong.
So first off, how do you get the error code descriptions in System Center Configuration Manager 2007 reports? That's an easy one as we already have a Knowledge Base article that tells you exactly what to do:
KB944375 - How to obtain error code descriptions in System Center Configuration Manager 2007 reports
If you just see an error code in the description of the error then this would be a good place to start:
These two resources are invaluable when it comes to troubleshooting an issue so if you haven't already, you'll want to go ahead and book mark these now. They're an integral part of any ConfigMgr admin's toolbox.
No data returned from Data Source :SoftwareDeployment.
This can occur if the Microsoft System Center Configuration Manager 2007 Dashboard is installed on a server other than the Configuration Manager reporting server point. The machine account for the server hosting the Dashboard must have rights to query the Configuration Manager Reporting Services.
Resolution
To resolve this issue and allow the Microsoft System Center Configuration Manager 2007 Dashboard to load successfully, use the following steps:
Navigate in the Configuration Manager 2007 Console to Site Database\Computer Management\Security Rights\Users.
Right-click Users and choose Manage ConfigMgr Users
Under Add a new user: type the name of the server where the Dashboard is installed in the format <domain>\<servername>$ (for example CONTOSO\server2$
Click Next, and choose Add another right or modify an existing one on the Review The set of rights for this user screen. Click Next.
Grant the machine account at least Class: Report Read rights on the appropriate reports (usually 'All Instances'). Click Next.
Choose Add another right or modify an existing one and also grant Query rights for the appropriate reports.
Complete the wizard.
Reboot the Dashboard server.
Hope this helps,
Mark Stanfill | Senior Support Escalation Engineer
Just in case you somehow happened to miss the announcement, we made Windows 7 Service Pack 1 and Windows Server 2008 R2 SP1 available to MSDN and TechNet Subscribers as well as Volume License customers yesterday. I've been running it for a few days now here and so far I'm pretty impressed, although admittedly I'm probably a little biased. In addition to the standard hotfixes and whatnot, we added some cool virtualization specific features like Dynamic Memory and RemoteFX in Windows Server 2008 R2 SP1 so if you work with any kind of virtualization you'll definitely want to check that out.
But to get back to the real topic of this post, our own Buz Brodin wrote up some great troubleshooting steps you can use if you're experiencing OOBConsole connectivity issues after an Intel vPro enabled device has been provisioned in ConfigMgr 2007. Buz is one of our top AMT/OOB/vPro experts based out of our Charlotte, North Carolina office so if you ever had the chance to call in you very well may have spoken to him. Thanks Buz!
======
The following lists the steps needed and troubleshooting methods available for OOBConsole Connectivity AFTER an Intel vPro enabled device has been successfully provisioned in SCCM 2007.
For OOBConsole and HTTPS connectivity to work the following is required:
1. The IE registry change from article KB908209 must be set on the machine initiating the connection. For Windows XP and Windows Server 2003, the related hotfix needs to be installed first, then the registry key implemented. For newer versions of Windows or Windows XP and 2003 versions that have superseded the patch in KB908209, the registry key change STILL needs to be implemented.
For 32-bit computers
1. Click Start , click Run , type regedit , and then click OK .
2. In the left pane, locate and then click the following registry subkey:
3. On the Edit menu, point to New , and then click Key .
4. Type FEATURE_INCLUDE_PORT_IN_SPN_KB908209 , and then press ENTER.
5. On the Edit menu, point to New , and then click DWORD Value .
6. Type iexplore.exe , and then press ENTER.
7. On the Edit menu, click Modify .
8. Type 1 in the Value data box, and then click OK .
9. Exit Registry Editor.
Note: A reboot is not required.
2. Telnet must be installed on the machine initiating the OOBConsole connectivity. Telnet is installed by default in Windows XP and Windows Server 2003, however in newer versions of Windows (2008, Win7) Telnet must be manually installed.
3. The USER account initiating the OOBConsole connection must be listed with the required rights in the Component Configuration\Out of Band Management Properties\Amt Settings\Amt user accounts, SCCM Admin Console interface. More information on this can be found here:
Note that after making changes here the clients provisioning data will also need to be updated. Right click the client or control/shift click multiple clients, select Out Of Band Management and select Update Provisioning Data in Management Controller Memory. The Amtopmgr.log will log this process and it should be fairly quick.
4. (Possibly Optional): Insure the Internal Subordinate and Root CA certs are in both Trusted Root and Intermediate CA stores on the client you are connecting to and the provisioning/oobconsole machine.
Troubleshooting:
The OOBConsole.log file logs information regarding connection attempts to AMT provisioned computers using the Out Of Band Management Console accessible through the collection view. This log is located in the AdminUI logs folder on the site server and can be used to troubleshoot connectivity errors. You can enable verbose logging using the following procedure:
1. Close the Configuration Manager Console and any open Configuration Manager Windows 2. In Windows explorer, navigate to the bin folder for Admin UI, usually in c:\Program Files\Microsoft Configuration Manager\AdminUI\bin 3. Locate the file oobconsole.exe.config, open it in Notepad 4. Locate the tag "<source name="OOBConsole" switchValue="Error">" 5. Change the Value "Error" to "Verbose" 6. Save the changes
Future attempts to use the Out Of Band management Console will now log in the verbose mode. The procedure can be reversed to set logging back to the default mode. (set "Verbose" to "Error"). Some Oobconsole tasks will not function if the User Account that is connecting via Oobconsole has a Kerberos Token that is too large. This is an AMT/vPro limitation and is dependent on the version of AMT firmware the customer has in place. There is further information and a chart from Intel here:
Run with the current user logged on with the following parameters:
tokensz.exe /compute_tokensize.
Output at the bottom will show MaxToken = ####
To reduce Token Size, remove the user from some groups or use a fresh account that is not a member of so many groups. After doing this you may need to use KerbTray (from Microsoft resource kits) to flush the local Kerberos ticket cache.
Something important to note is that while Right Click/Power Control functions may work, you may find that Oobconsole functions do not. This is because Power Control uses TLS Authentication and OobConsole and the HTTPS web page uses Kerberos.
Image may be NSFW. Clik here to view.Hi everyone, Arvind Kr. Rana here. We’ve seen this issue come up a couple of times so I wanted to give it a mention here just in case you run into it. The problem is that you may notice that a System Center Configuration Manager 2007 (ConfigMgr 2007) Secondary Site Server is unable to do any type of AD discovery in another forest. The forest trust is working fine, and you may see some errors in the adsysdis.log on the secondary site server similar to the following:
ERROR: Failed to bind to 'LDAP://domainname/rootDSE' (0x8007203B) ERROR: Failed to enumerate directory objects in AD container LDAP://FQDN SMS_AD_SYSTEM_DISCOVERY_AGENT 11/16/2011 1:41:10 PM 4688 (0x1250) STATMSG: ID=5204 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_AD_SYSTEM_DISCOVERY_AGENT" SYS=machine name SITE=site name PID=2252 TID=4688 GMTDATE=Wed Nov 16 19:41:10.771 2011 ISTR0="LDAP://FQDN" ISTR1="A local error has occurred.~~" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_AD_SYSTEM_DISCOVERY_AGENT 11/16/2011 1:41:10 PM 4688 (0x1250)
Troubleshooting
We checked the trust between the two forests, we have forest trust, and found the trust to be working just fine. I was able to access the resources or the users of the either forest.
The Central site server and the Primary site server were able to do any type of AD discovery fine from any other trusted forests.
We then found the following error in the adsysdis.log which seems to point to an authentication issue:
ERROR: Failed to bind to 'LDAP://domainname/rootDSE' (0x8007203B) ERROR: Failed to enumerate directory objects in AD container LDAP://FQDN
We examined and found the DNS name resolution to be working fine on the secondary site server so we then enabled Netmon to take a network capture. After triggering adsysdis.dll by running the AD system discovery we found the following errors in the Netmon trace:
Everything seemed to be setup fine and the trust is also working fine. Also this problem did not affect all ConfigMgr 2007 site servers, but only this secondary site server.
Cause
It turns out that this issue was due to the "Selective authentication trust" between these two forests, as in the case of the Selective authentication trust the secondary site server or any other object has to be given required permissions manually in the other forests domain exclusively.
Solution
Once you manually give permissions to the secondary site server machine account in the other forest domain’s active directory, and then purge the old Kerberos tickets using the klist tool from the secondary site server or restart the secondary site server, the server gets the new ticket and the new access token which have the new permissions to enumerate the other forests Active Directory to do any type of discovery (as we know that the machine account is used for discoveries).
More Information
This problem can also manifest itself in other ways such as when the central or the primary or any other machine is not able to see or access the resources from the other forests or domains. This issue can be fixed by manually giving the permissions to that object on the desired resource. In the case of Selective authentication trust though the forest trust you can even validate it, but the trust is only for the objects that have been given permissions manually to the resource. In a case of Discovery, the adsource.dll impersonates itself as the machine account of the site server, so the machine account should have the right permissions in Active Directory.
The TechNet article below articulates the permissions required and the complete flow of all type of the discoveries in ConfigMgr 2007:
Image may be NSFW. Clik here to view.I recently came across an older, fairly common issue recently but I never see one of the potential workarounds mentioned so I thought I write it up here in case you run into it.
With this issue, the System Center Configuration Manager 2007 (ConfigMgr 2007) Remote Tools and Remote Desktop tools fail to connect to client computers that have a NetBIOS name longer than 15 characters even though regular Windows Remote Desktop works fine. When your try to start Configuration Manager 2007 Remote Tools you get following error:
Unable to contact Host
When you try to use the Configuration Manager 2007 Remote Desktop client you get this error:
Remote Desktop can’t find the computer <client name>.This might mean that <Client name> does not belong to the specified Network. Verify the computer name and domain that you trying to connect to.
When trying to ping the 15+ character NetBIOS name it works, but when we try to ping the truncated NetBIOS name it errors out with the below message:
Ping Request could not find host client <truncated NetBIOS name>
NOTE In DNS, a Host (A) record is created for the 15+ character NetBIOS name (e.g. Client-PC123456789) although in the Configuration Manager console and under Active Directory users and computers it shows the truncated name consisting of first 15 characters (e.g. Client-PC123456).
Most people assume that if you have a NetBIOS name of more than 15 character (the standard, accepted limit), the only way to fix the issue is to shorten it. While that’s definitely the preferred method, you might be able to get away by enabling "NetBIOS over TCP/IP" on the server and client. If you have a server or client with an NetBIOS name longer than 15 characters and “NetBIOS over TCP/IP” is disabled then you’ll definitely get the errors mentioned above.
To resolve this issue, ensure that both the Configuration Manager 2007 server and the client have NetBIOS over TCP/IP enabled. You can verify this by going to Network Connection -> TCP/IP properties -> Advanced -> WINS tab -> NetBIOS.
Image may be NSFW. Clik here to view.Here’s an issue we’ve seen a couple times before so I thought I’d give you a heads up here in case you happen to run across it.
Symptoms
The System Center Configuration Manager 2007 (ConfigMgr) SMS Agent Host Service (CCMExec.exe) may become unresponsive or even crash on a regular basis, sometimes as frequently as every hour. You may also see the errors below:
Application Event Log:
Event ID: 1000
Faulting application name: CcmExec.exe, version: 4.0.6487.2000, time stamp: 0x4ab33e4d
Faulting module name: ntdll.dll, version: 6.1.7601.17514, time stamp: 0x4ce7ba58
Description: The SMS Agent Host service terminated unexpectedly. It has done this 38 time(s). The following corrective action will be taken in 300000 milliseconds: Restart the service.
Application Event Log:
Event ID: 1035
Windows Installer reconfigured the product. Product Name: SMS Management Point. Product Version: 4.00.6487.2000. Product Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 0.
Event ID: 1035
Windows Installer reconfigured the product. Product Name: Configuration Manager Client. Product Version: 4.00.6487.2000. Product Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 0.
Cause
This can potentially occur in some scenarios where CAL tracking is enabled (the default) and Thread Pool Logging is enabled.
Resolution
There are two possible ways to resolve this issue:
1. Disable Thread Pool ETW tracing. To do this you’ll need to use logman.exe to stop the Data Collector Set that contains the Thread Pool provider.
a. To list all of the running Data Collector Sets use this command:
logman.exe -ets
b. One of the sets should have the words Thread Pool in the name. If not, you’ll have to query each set individually using the command below until you find the one that has the Thread Pool provider. It will be the one that has a GUID of {C861D0E2-A2C1-4D36-9F9C-970BAB943A12}.
logman query COLLECTOR_SET_NAME -ets
c. Use the following two commands to disable Thread Pool ETW tracing, substituting the Data Collector Set name you discovered above:
logman stop COLLECTOR_SET_NAME -ets
logman delete COLLECTOR_SET_NAME -ets
2. Alternatively, you can disable CAL tracking in ConfigMgr by renaming the DLL that handles that component.
On a 64-bit system this will be at C:\windows\syswow64\ccm\ccm_caltrack.dll. If the server is a Management Point, it will be at \SMS_CCM\CCM_Caltrack.dll
Stop the SMS Agent Host service, rename the DLL, and then restart the service. You will see a warning/error line in one of the client logs when the service starts but there should not be any additional errors and the client should not be affected in any other way.
You should only have to do one of the two options above.
Senthilkumar Pandurangan | System Center Support Engineer
Image may be NSFW. Clik here to view.Our colleagues over at the Configuration Manager Team Blog just posted a great article on how to troubleshoot a situation where you see a discrepancy between the completion statistics section for an error count of a deployment and the Error tab of the deployment status when you drill into the status of the deployment. If you haven’t read this article yet then you’ll definitely want to check this one out:
The Configuration Manager console has been greatly improved in System Center 2012 Configuration Manager, which enhances its usability. In addition to improvements in performance and layout, the console now supports a quicker way to monitor application deployments.
However, you might come across a situation where you see a discrepancy between the completion statistics section for an error count of a deployment and the Error tab of the deployment status when you drill into the status of the deployment. In this scenario, you see the following:
The count of assets that returned an error state when you review the completion statistics of a deployment do not match the number of assets that are listed in the Error tab of the Deployment Status.
For example, the following screenshot shows that the completion statistics for the deployment displays 3 assets that have reported an error…
Image may be NSFW. Clik here to view.Hi everyone, Arvind Kr. Rana here. We’ve seen this issue come up a couple of times here lately so I wanted to give it a mention here just in case you run into it. The issue is that if you are trying to install a System Center Configuration Manager 2007 (ConfigMgr) Branch Distribution point role on a Distributed File System (DFS) namespace share you will receive errors as this is not a supported configuration:
ERROR: Received BITS settings policy. Client is not provisioned to be a Branch DP. PeerDPAgent 5564 (0x15BC) Raising event: [SMS_CodePage(437), SMS_LocaleID(1033)] instance of PDPBITSConfigDeleted { ClientID = "GUID:34605BAD-3DD3-4979-B852-02D0618CFD72"; DateTime = "20120214155012.186000+000"; MachineName = ""; ProcessID = 5192; SiteCode = ""; ThreadID = 5564; }; PeerDPAgent 2/14/2012 10:50:12 AM 5564 (0x15BC) Not processing message (<PDPScheduledMaintenance MessageType='PDPStatusTask'/>) as agent is not acting as BDP PeerDPAgent 9408 (0x24C0) Not processing message (<PDPPkgProvisioningStatus PackageType='Pending'/>) as agent is not acting as BDP PeerDPAgent 8920 (0x22D8) Not processing message (<PDPScheduledMaintenance MessageType='PDPStatusTask'/>) as agent is not acting as BDP PeerDPAgent 9748 (0x2614) Not processing message (<PDPPkgProvisioningStatus PackageType='Pending'/>) as agent is not acting as BDP PeerDPAgent 5280 (0x14A0)
Troubleshooting:
In this case we checked and found that the customer was using a DFS share to host the Branch Distribution Share data. This was done so that the ConfigMgr packages could be updated on the BDP and then be automatically replicated across all the DFS shares in the same namespace so clients could pick it’s package from any of the DFS shares. This is not supported as it can cause issues with the DFS replication engine.
Solution:
As a workaround, you can bypass the DFS share and instead use the local share on the local machine that is mapped to the DFS namespace. A DFS share will always start with the domain name (e.g. \\contoso.com\internals) and by using the local share name instead, we can do a NET SHARE and find the location, and use this local location as the new Branch Distribution Point share path.
Image may be NSFW. Clik here to view.Hi everyone, Tyler Franke here once again with another troubleshooting tip for you. Consider the following scenario:
In an otherwise healthy and functional site you find one or more of the following.
1) SMS Site Control Manager Site status message:
SMS Site Control Manager Message ID: 2816 Message: The actual site control file %1 does not exist. Solution: The SMS server components cannot function without this file. SMS Site Control Manager will shut down SMS Executive immediately. Contact Microsoft for help in restoring the actual site control file.
2) The following error in the sitectrl.log:
The delta site control file "D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\incoming\.<site> via the SMS SDK on Mon Feb 27 17:32:41 GMT. The record was assigned the serial number 788 at site <site>. SMS_SITE_CONTROL_MANAGER 2/27/2012 11:33:06 AM 16676 (0x4124) STATMSG: ID=2807 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_SITE_CONTROL_MANAGER" SYS= SITE= PID=34520 TID=16676 GMTDATE=Mon Feb 27 17:33:06.925 2012 ISTR0="D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\incoming\" ISTR1="Microsoft.ConfigurationManagement.dll" ISTR2="AD\E143665" ISTR3="%computername%" ISTR4="" ISTR5="2012 02 1 27 17 32 41 000" ISTR6="788" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_SITE_CONTROL_MANAGER 2/27/2012 11:33:06 AM 16676 (0x4124) Wrote temporary file "D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\temp\000003D2.ct0". SMS_SITE_CONTROL_MANAGER 2/27/2012 11:33:06 AM 16676 (0x4124) Copied file "D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\sitectrl.ct0" to "D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\history\000003D1.ct0". SMS_SITE_CONTROL_MANAGER 2/27/2012 11:33:06 AM 16676 (0x4124) WARNING: Could not move file "D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\temp\000003D2.ct0" to "D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\sitectrl.ct0". The operating system reported error 32: The process cannot access the file because it is being used by another process. SMS_SITE_CONTROL_MANAGER 2/27/2012 11:33:06 AM 16676 (0x4124) Sleeping for five seconds... SMS_SITE_CONTROL_MANAGER 2/27/2012 11:33:06 AM 16676 (0x4124)
WARNING: Failed to complete processing of delta site control file "D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\incoming\g0hrz08y.CT1". SMS_SITE_CONTROL_MANAGER will try to process the file again later. SMS_SITE_CONTROL_MANAGER 2/27/2012 11:34:07 AM 16676 (0x4124) ERROR: The master site control file "D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\sitectrl.ct0" does not exist. SMS_SITE_CONTROL_MANAGER will shut down SMS_EXECUTIVE immediately. SMS_SITE_CONTROL_MANAGER 2/27/2012 11:34:07 AM 16676 (0x4124) STATMSG: ID=2816 SEV=E LEV=M SOURCE="SMS Server" COMP="SMS_SITE_CONTROL_MANAGER" SYS= SITE= PID=34520 TID=16676 GMTDATE=Mon Feb 27 17:34:07.132 2012 ISTR0="D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box\sitectrl.ct0" ISTR1="D:\Program Files\Microsoft Configuration Manager\inboxes\sitectrl.box" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=0 SMS_SITE_CONTROL_MANAGER 2/27/2012 11:34:07 AM 16676 (0x4124) SMS_EXECUTIVE is stopping... SMS_SITE_CONTROL_MANAGER 2/27/2012 11:34:07 AM 16676 (0x4124)
3) The following error in the MPControl.log:
SMS_MP_CONTROL_MANAGER 2/27/2012 12:05:33 PM 36352 (0x8E00) SMS_MP_CONTROL_MANAGER received START notification. SMS_MP_CONTROL_MANAGER 2/27/2012 12:05:33 PM 36352 (0x8E00) MPStart(): RegOpenKeyEx(MPNotify) returned 2. SMS_MP_CONTROL_MANAGER 2/27/2012 12:05:33 PM 36352 (0x8E00) SMS_MP_CONTROL_MANAGER failed to start with 0x80070002 SMS_MP_CONTROL_MANAGER 2/27/2012 12:05:33 PM 36352 (0x8E00) SMS_EXECUTIVE started SMS_MP_CONTROL_MANAGER as thread ID 37408 (0x9220). SMS_MP_CONTROL_MANAGER 2/27/2012 1:05:52 PM 39744 (0x9B40)
4) Service control manager events reporting that SMS_EXECUTIVE is terminating unexpectedly:
Log Name: System Source: Service Control Manager Date: 2/27/2012 10:12:55 PM Event ID: 7034 Task Category: None Level: Error Keywords: Classic User: N/A Computer: %computername% Description: The SMS_EXECUTIVE service terminated unexpectedly. It has done this 3 time(s).
Cause
This can potentially be caused by one of more of the following:
1) File system corruption. 2) No Anti-virus scanning exclusion for %programfiles%\Microsoft Configuration Manager\Inboxes. 3) Someone manually or improperly editing the sitectrl.ct0 file on the site.
Resolution
To resolve this issue, execute and complete a site reset on the affected site server to create a new sitectrl.ct0 file.
Image may be NSFW. Clik here to view.Hi everyone, Tyler Franke here again with one more issue I ran into recently. Consider a scenario where you have your System Center Configuration Manager 2007 (ConfigMgr) site database on a remote/dedicated SQL Server wherein a drive fails or has to be replaced. Afterward, the 'Backup ConfigMgr Site Server' site maintenance task fails to run and the following site status error messages are found under SMS Component manager thread:
SMS Site Component Manager could not create the SMS server components' installation directory "I:\SMS_site_server_name" on site system "\\My_SQL_Server" or set the correct permissions on the directory. The operating system reported error 53: The network path was not found.
Possible cause: The destination drive is full. Solution: Make more space available on that drive.
Possible cause: The site system is not exporting the default drive letter shares, such as "\\My_SQL_Server\C$", "\\My_SQL_Server\D$", and so on. Solution: You might have disabled the default drive letter shares for security purposes. SMS requires these shares. Please re-enable these shares using the Windows NT Disk Administrator.
Possible cause: The site system is turned off, not connected to the network, or not functioning properly. Solution: Verify that the site system is turned on, connected to the network, and functioning properly.
This occurs as a result of the ConfigMgr site server not being able to access the folders and files on the SQL server site system.
NOTE The last folder shown above (i.e. srvacct) is a hidden folder
Please take the following steps to resolve:
1. On the site server, click on the start menu and navigate to Microsoft System Center-> Configuration Manager 2007, then click on “ConfigMgr Setup”. 2. Once the setup wizard appears on the screen click next on the Welcome page. 3. On the available setup options page, select “Perform site maintenance or reset this Site” and click Next. 4. On the site maintenance page, select only the “Modify SQL Server Configuration” option and then click Next. 5. On the SQL Server Configuration page, verify the existing information is correct for the SQL Server instance and site database names, then click Next and wait for the process to complete.
More Information
In a situation where the drive has not failed and/or changed and only the drive-letter was changed you can most likely resolve this by simply going into the registry of the SQL Server under HKLM\System\CurrentControlSet\services\SMS_SITE_SQL_BACKUP and changing the value of the "ImagePath" string value to reflect the new and correct drive-letter.
Image may be NSFW. Clik here to view.Hi everyone, Tyler Franke here again with another troubleshooting tip for you. When you’re in the System Center Configuration Manager 2007 administrative console and trying to download software updates to an update list, it may fail with an error stating the following:
The requested header could not be found
Furthermore, if you leverage the PatchDownloader.log you will find an entry similar to the following:
A content filtering device was closing the session. Notice in the Netmon frames below that the connection is initiated by the site server with IPv4 address 192.168.1.100, however the device with IPv4 address 192.168.1.200 is where the traffic is being sent first to try to actually go out and initiate the download. You’ll notice that as part of the HTTP connection initiated by the site server we have to keep the session alive (i.e. ProxyConnection: Keep-Alive) however the device with IPv4 address 192.168.1.200 essentially deconstructs the packet and then closes the connection (i.e. ProxyConnection: close) therefore ending any chances the site server had of downloading the software updates.
The items/lines that I've bolded in the Netmon frames below are the most noteworthy and demonstrate the content filtering device closing the connection.
NOTE In this particular case the device was a Websense content filtering device but any device that performs similar functions can cause the same issue.
Resolution
To fix this, you’ll need to configure the content filtering device to allow their Configuration Manager site server access to at least the following list of websites as taken from KB885819.
Quite commonly the cache of the web filtering device will also have to be cleared or purged after making the necessary changes to allow the site server access to the required web addresses. Failure to do so can leave the cache intact and not allow for a successful connection.
You might see content mismatch warnings in System Center 2012 Configuration Manager when content validation runs and determines that there is a discrepancy between the expected list of packages in WMI on the distribution point and the packages in the...(read more)Image may be NSFW. Clik here to view.
The Configuration Manager console has been greatly improved in System Center 2012 Configuration Manager, which enhances its usability. In addition to improvements in performance and layout, the console now supports a quicker way to monitor the status...(read more)Image may be NSFW. Clik here to view.
Here's a ConfigMgr 2007 issue I had recently that was caused by an known issue with IIS. I wanted to publicize this here so that it might help others who run into this problem.
