SCCM - Component Status - SMS_MP_CONTROL_MANAGER - not responding to http requests

Issue

When you navigate to Site Database > System Status > Site Status > (site name) > Component Status the SMS_MP_CONTROL_MANAGER component has a Status of Critical. If you right click the component > Show Messages > All then you encounter the following error message:

MP Control Manager detected management point is not responding to HTTP requests.  The HTTP status code and text is 500, Internal Server Error.

Possible cause: Management point encountered an error when connecting to SQL Server. 
Solution: Verify that the SQL server is properly configured to allow Management Point access. Verify that management point computer account or the Management Point Database Connection Account is a member of SMS Management Point Role (msdbrole_MP) in the SQL Server database.

Possible cause:  The SQL Server Service Principal Names (SPNs) are not registered correctly in Active Directory
Solution:  Ensure SQL server SPNs are correctly registered.  Review Q829868.

Possible cause: Internet Information Services (IIS) isn't configured to listen on the ports over which SMS is configured to communicate. 
Solution: Verify that the designated Web Site is configured to use the same ports which SMS is configured to use.

Possible cause: The designated Web Site is disabled in IIS. 
Solution: Verify that the designated Web Site is enabled, and functioning properly.

Possible cause: The SMS ISAPI Application Identity does not have the requisite logon privileges. 
Solution: Verify that the account that the SMS ISAPI is configured to run under has not been denied batch logon rights through group policy.

For more information, refer to Microsoft Knowledge Base article 838891."

If you open up the mpcontrol.log you should see more details relating to this error.

Cause

Sort of depends on what the fix turns out to be. In my experience the root cause is usually a corrupt ccm client.

Resolution

Option A

Check to see if this kb is relevant http://support.microsoft.com/kb/2796086  

Option B

Log on to your SQL server. Navigate to SQL Server Configuration Manager > Network
Configuration > Protocols for MSSQLSERVER / TCP/IP  
Make sure this is set to "enable".

Option C

Fully uninstall the SCCM client from the server which holds the management point by using navigating to the ccmsetup directory (c:\windows\ccmsetup) and then running the following command: ccmsetup.exe /uninstall
Once this has completed, restart the SMS Exec service. Assuming no errors appear in the mpcontrol.log, warmly congratulate yourself on a job well done. If errors do appear, take a run at Option D.

Option D

Remove the Management Point. Remove the SCCM Client. Reinstall the Management Point. Reinstall the client.

Run Powershell Script in Task Scheduler

Run Powershell Script in Task Scheduler

 

If you ever find yourself in need of running a powershell script as a scheduled task, ensure the Action tab settings are set up as follows:

• Program/Script: Point this to the location of the powershell executable (this'll be  %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe)
 
• Add arguments (optional): Enter the file path to the script you want to be run

 

Other things to check should the scheduled task fail:

• Is the 'Run with highest privileges' option checked on the General tab?
• Is the task set to 'Run whether user is logged or not' on the General tab?
• If you created it in PowerGUI or some similar editing tool, did that application automatically load any modules - if so, you'll need to add a line to your script to load said modules (e.g. Add-PSSnapin Quest.ActiveRoles.ADManagement)
• Manually run your scheduled task and have a look at the last run result code in the Task Scheduler main window. Use the mighty Google to see what the result means
• Also, check the History tab and see what info has popped in there:



SCCM 2007 - Create Task Sequence to PXE boot winpe directly into a Remote Desktop Session/Terminal Server

Below are two guides;

> The first is for creating a Task Sequence in SCCM 2007 to PXE boot a machine into WinPE which will then initiate a connection to a remote desktop session host/terminal server.

> The second guide is for creating a USB/CD iso image which can be used to boot a machine into WinPE which will then initiate a connection to a remote desktop session host/terminal server

Both of these are zero client configurations and mean that you can run the boot sequence on a desktop/laptop which has no hard drive. All instructions relate to creating a 32bit boot image but i assume the same instructions would hold true for a 64 bit image.

PXE Boot into WinPE and Connect to Remote Desktop/Terminal Server

Before beginning, ensure the following ducks are lined up:

• PXE boot is working in the environment
• You are either working on a Windows 7 32bit machine or have access to an extracted iso of the aforementioned operating system

1] Get boot.wim file by extracting a Windows 7 32bit iso and then browsing to the "sources" folder. Here you will find the boot.wim. Copy this file (should be about 160/170MB in size) into c:\temp on your local machine. [In this example I have then renamed the boot.wim to boot_rdsh.wim]

2] Create folder called Mount in c:\temp on your local machine

3] Mount the boot.wim file using dism. Open elevated command prompt and type:

Dism /mount-wim /wimfile:c:\temp\boot.wim /index:1 /mountdir:c:\temp\mount

 

4] Back in windows file explorer, navigate to "C:\windows\system32" on your local machine and copy all of the below files:

D3d10.dll

D3d10_1.dll
D3d10_1core.dll
D3d10core.dll
D3d10level9.dll
D3d10warp.dll
D3d11.dll
Dxgi.dll
Msacm.dll
Msacm32.dll
Msacm32.drv
Mstsc.exe
Mstcax.dll

Then paste them into to "C:\temp\Mount\Windows\System32"

5] Next you’ll need to copy the below listed files from "C:\windows\system32\en-US" on the local machine:

Msacm32.dll.mui

Msacm32.drv.mui
Mstsc.exe.mui
Mstscax.dll.mui

Then paste them into "C:\temp\Mount\Windows\System32\en-US"

6] Next open up notepad and enter the following

[customHook]

commandline="x:\RunMSTSC.cmd"

Save the file as TSconfig.ini to c:\temp

[This is a pre-execution hook command and it's a most useful option, see http://technet.microsoft.com/en-gb/library/bb694075.aspx for more info] 

 

7] Open notepad and enter the following text

Start /wait mstsc.exe /v:RDSserver1 /f

Save the file as RunMSTSC.cmd to c:\temp
 

8] Copy both files into the root of the extracted boot_rdsh.wim which is located in c:\temp\mount

 

9] Unmount the boot.wim

dism /unmount-wim /mountdir:c:\temp\mount /commit

10] Copy the boot_rdsh.wim onto your sccm server. Import it into SCCM as a new boot image

11] Create a new custom task sequence. Open the properties of the task sequence 

 

 

 

12] Create a new Collection and place a test client machine inside

13] Right click on the new Task Sequence you create and Advertise it to the new collection

14] Boot up the test client machine, hit F12 and wait for PXE to boot into WinPE. Once the machine is in WinPE, it should kick off the executable which you configured in the TSConfig.ini command (ie the runMSTSC.cmd file). All things being well, you should be connected to the remote desktop server

Bootable WinPE USB/CD

Should you need to create a bootable winpe usb/cd, follow the steps outlined in this most excellent guide:

http://www.iammacgyver.com/2011/02/easy-rdp-60-from-winpe-30-simple-boot.html

Smart Card Fail: “The system could not log you on. You cannot use a smart card to log on because smart card logon is not supported for your user account..."

Issue

Users phone up to report that they cannot log into their smart card-based workstations. They encounter the following message:

“The system could not log you on. You cannot use a smart card to log on because smart card logon is not supported for your user account. Contact your system administrator to ensure that smart card logon is configured for you organisation”

 

 

Fix:

In my experience, the easiest way to fix this issue is to request a new

1] On DC, open an mmc.

2] Go to File > Add/Remove Snap-in > Select Certificates > Add > select Computer account.

3] Expand Certificates (Local Computer), right-click Personal, click All Tasks, then click Request New Certificate.

4] On the Request Certificates step select Domain Controller Authentication

 

5] Next through and Finish

 

Other Options:

Shoudl the above options fail, it's also worth checking the following;

> Does the Certificate Authority have a valid CRL available? Log onto the certificate authority server and check there is a valid CRL available by viewing the properties of the Revoked Certificates. Ensure the expiration date is set to a date in the future:

 [N.B. in the above example all the dates have been deliberately blanked out]

> Check that both "Smart Card Logon" and "Client Authentication" are selected in Application Policies on the "Extensions" tab on the certificate template you're enrolling the smart cards in.

> If the certification authority server is a subordinate, can it contact the parent certificate authority (assuming this is where the CA is getting it's CRL from)?

> Check on the Certification Authority server, are there any errors in the Application event log? If so, are they relevant?

> Check the disk space on the Certification Authority. Bit of a long shot, but always worth a quick look just in case.

 

SCCM 2007 - Update Logs - Basic Guide

Generally, if you're troubleshooting a problem with SCCM Software Update Deployments the logs located in %WINDIR%\System32\CCM\Logs folder or %WINDIR%\SysWOW64\CCM\Logs will be a good place to start your hunt for answers. There's a whole bunch of different logs which relate to Windows Update on the client side, these are the ones i've found to be the most useful:

WindowsUpdate.log
(this can be found in the %windir% folder)
The catch-all, one stop(ish) shop for troubleshooting windows update deployment issues. Although it won't always provide you with all the required info when troubleshooting a given issue, it should always be the first port of call when troubleshooting an update issue. It basically acts a simplified roll up of all the other Windows Update logs.

 

UpdatesStore.log

This will trundle off to SCCM and check the SUP to compare all available updates against those which it knows to already be installed on the box. It shows you what happens during the compliance scan cycle. Below you can see the cycle has found a number of updates which are already installed (green) and a number which are missing (red):

 

UpdatesHandler

Here you can watch information about software update compliance scanning and about the download and installation of software updates on the client. It mirrors the information that appears in the WUAHandler. Here is an example of what the UpdatesHandler.log records after new updates have been found. First the updates are downloaded (blue), then the update job moves from preparing to run to being ready (orange), then the updates begin to install (green)

 

 

WUAHandler

This displays all the info gleaned from the Windows Update Agent on the client. This is a good place to watch the whole progress of the download process as seen through the eyes of WUA. Below is an example of the process working to download two required updates, first the log records the start of the initial search (green), then it records the updates it has found (blue) and then it records the installaiton of the updates (blue).

 

 



 

UpdatesHandler.log vs WUAHandler.log

These log files are very similar in that they both provide a window into the download and update process. They provide different slants on very similar information but it's normally worth having both open since they provide different levels of detail/insight into the update process. In the below example, both log files are recording the installation of 5 updates:  

 



How this translates on the user side:

The UpdatesHandler.log and WUAHandler.log files are both mirrors of the more friendly progress reports which pop up in the “Software Update Installation Progress” box which pops up in the user’s task bar. Here you can see how the two logs progress reports directly translate into the SUIP dialogue box:

 

 

 

SCCM 2007 - Task Sequence Fail – error 2148077575 the Hash Value is Incorrect

Symptoms:

 

Task Sequence kicks off.....

 

Disk drive formats

Image downloads

Image Applies and then, this:



 

 

 

In the Advertisement Status log on the SCCM Server you’ll see the following:

 

Cause:

 

Difficult to tell. Easiest way to tell is to make your way through the suggested fixes and see what works - could be a corruption of the package on the DP or could be something random like the RAM.

Possible Resolutions:

·        Change the amount/type of RAM in the PC (weird but has worked on the odd occasion for us)

·        Try swapping "Download content locally when needed by running task sequence” for "Access content directly from a distribution point when needed by the running task sequence" or vice versa

·        Remove the content from the DP and redistribute it

·        Remove the image/package from SCCM, re-import the image/recreate the package and then distribute it