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

 

 

 



Unable to run executable (e.g. a hotfix) - "Windows cannot access the specified device, path, or file...."

 

Issue:

When trying to manually install an executable file (e.g. a hotfix) on a server, the fololowing error pops up:

 

"Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item"

 

 
Cause:
There are various possible causes but in this case the problem was caused by the fact that the hotfix had been downloaded on another computer and then copied onto the server. As such, the server had marked the executable as being unsafe and so blocked any attempt to run it.

Solution:
Right click on the executable and select 'Properties'. From the general tab, click on the 'unblock' option which appears under the security heading.

 

 

Uninstall an application or program through SCCM or CMD line

Although there are a great many different ways to uninstall an applicaiton or program, one of the most straightforward and customisable options is to use wmic. If you need to quickly uninstall a particular applicaiton or program use the following cmd line:

wmic.exe product where "name like 'Example Program'" call uninstall

It's worth noting that you can also utilise the % if, for example you wish to uninstall all verisons of a given program, e.g.

wmic.exe product where "name like 'Adobe Reader%'" call uninstall

If you need to perform a mass uninstall, simply create an empty package and set the program to run the above command line:

SCCM - Troubleshooting - Windows Updates 0x80070BC9

When pushing out updates to your client machines via SCCM you may encounter one or more of the below issues. From having done a whole bunch of Googling around the various error codes and issues which manifested themselves i think it's fair to say that there a whole host of different things that can break Windows Updates in SCCM. The following is by no means a definitive fix but it helped us out so figured it was worth posting:

Symptoms:

A: In the windowsupdate.log file you may encounter an error with code 80070bc9

B: In the WUAHandler.log file you may receive a message saying that

 

C: In SCCM, when you switch to the Software Updates and view the month’s current updates, SCCM lists all the machine status’ as “Unknown”

Issue:

In this case, an old Group Policy which pointed all clients to a separate WSUS server was still, apparently, haunting the client machines (as shown by the 'overwritten' line in the WUAHandler log). As such the client machines weren’t sure where to look for updates and also weren’t reporting their update status to sccm correctly.

Fix:
Create a group policy which explicitly defines the location that the clients should use for Windows Update (i.e. the sccm server):

 

In theory, this shouldn’t be necessary since the CCM client should define the location of the windows update server but if, for whatever reason, this gets screwed up then manually defining the location via GPO is a good way to get the clients back on the right track.

 

Once you've applied this new GPO to your clients machines, choose a machine and run a Software Update Scan Cycle. The WUAHandler.log should look a bit less red now: 

SCCM - Troubleshooting - The installed product does not match the installation source(s) error when uninstalling a windows service

When trying to uninstall a product that has been installed with SCCM (or otherwise as the case may be) you may encounter the following error message :

"the installed product does not match the installation source(s) error when uninstalling a windows service"

The issue here is that you are trying to uninstall a program for which the original installation source has either been deleted, moved or altered. In short, although the program you're trying to remove has a PackageCode ( GUID ) X, the msi your machine is trying to use to remove the program has a PackageCode of Y.

In order to resolve this, locate an MSI which is similar to whichever program you are trying to remove, then run:

MsiExec.exe /I example.msi REINSTALLMODE=voums REINSTALL=ALL

Once this command has completed, the MSI will be effectively re-cached with PackageCode Y.

Install dot net 3.5 on Windows Server 2012/Windows 8 - 0x800F081F error

When installing dot net 3.5 from the command prompt/powershell in Windows Server 2012 (R2) or Windows 8(.1), you need to have access to a folder (specifically the SXS folder) from the original install media. Whether you extract the contents of an ISO and copy the SXS folder locally or simply mount the image, it doesn't make much difference when you point dism at the folder and then encounter this:

This is a fairly common error and one for which there seems to be a whole range of random ways to fix, depending on your situation. Personally speaking, it was the uninstall of the Updates which solved it but anecdotally speaking, a lot of these have helped various folk:

1] If present, uninstall updates KB2966826, KB2966827 and KB2966828

2] Check the syntax is correct:

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:d:\sources\sxs

In case anyone needs it, here's what the commands actually mean:

• /Online targets the operating system you're running (instead of an offline Windows image).
• /Enable-Feature /FeatureName:NetFx3 specifies that you want to enable the .NET Framework 3.5.
• /All enables all parent features of the .NET Framework 3.5.
• /LimitAccess prevents DISM from contacting Windows Update.
• /Source specifies the location of the files needed to restore the feature (in this example, the D:\sources\sxs directory).

3] Check the extracted/mounted ISO isn't corrupt - i.e. download another copy if possible

4] If the server has internet access, drop the /LimitAccess from the syntax

SCOM - Two State Monitor - Check if Files Exists

This is an example how to use a timed script two state monitor to monitor a file exists. If the file exists the monitor is healthy.

A] Under Authoring > Monitors, create a new Timed Two State Monitor. Give it a name, schedule, target and description

B] Copy this script into the 'Script Window':

Dim oAPI, oBag
Set oAPI = CreateObject("MOM.ScriptAPI")
Set oBag = oAPI.CreatePropertyBag()
Set objFSO = CreateObject("Scripting.FileSystemObject")
strFile = "C:\Test.txt"
If objFSO.FileExists(strFile) Then
Call oBag.AddValue("Status","Ok")
Call oAPI.Return(oBag)
Else
Call oBag.AddValue("Status","Error")
Call oAPI.Return(oBag)
End If

Check that the quote marks are correct - i.e. straight down ones rather than the curly sort!

C] Configure the Healthy/Unhealthy experssions as needed. Use the Parameter name:

Property[@Name='Status']

then enter the Value depenging on which way round you need things

 

 

D] Configure the alerting bit of the Monitor and you're all done

SCCM 2007 - Task Sequence Fails - Content Mismatch - 80091007

Symptom:
Task Sequence fails with 80091007 error code.

Cause:
This error indicates that the files on the DP for one of the packages referenced by your task sequence does not match the hash that was obtained when the package was imported. 

Fix:

The easiest way to see which part of your Task Sequence is causing the problem is to open the SCCM Console and go to Site Database > System Status > Advertisement Status > then find the advertisement status for the task sequence that failed.

In the details windows, right click on the Site name and choose 'Show Messages > All'.

This will show all the status messages for the Task Sequence advertisement from which you can spot what the problem is:

In the above screenshot we can see there is a content mismatch issue with the driver package.

As a result we need to get the hash values to match up. Easiest way to do this is to use the Manage Distribution Points Wizard to try refreshing the boot image package on all distribution points. Once this is done update the distribution points.

Be sure to "Refresh DPs" and then do "Update DPs". With a bit of luck this will have resolved the issue!




Sidenote:

Refresh Distribution Points: this forces the content to be redistributed to the distribution points.

Update Distribution Points: when you run this the DP will check the version number it has against the version number of the package on the site server. If they match up the DP will not perform the update

SCCM 2007 - Report - All Machines, Operatin System, Most Recent Boot Time, Last User

This SQL query will poll sccm and pull out a report which lists all machines and their OS, most recent boot time and last logged on user:

Select 
SD.Name0 'Machine Name',
Caption0 AS [Operating System],
SD.User_Name0 'Last Logged on User Name',
Convert(VarChar(10), OS.LastBootUpTime0, 101)  'Last Boot Date'
From v_R_System SD
Join v_Gs_Operating_System OS on SD.ResourceID = OS.ResourceID
Order By 'Machine Name'

SCCM 2007 - Client Actions tab

Below is a list of what tasks/roles the various options on the Client Actions tab of the Client Configuration Manager client actually do:

Branch Distribution Point Maintenance Task
verifies any prestaged packages and downloads any that do not exist on the branch distribution point. While Technet does not explicitly state it, I believe this task is useful only on branch distribution points and is ignored on normal clients.

Discovery Data Collection Cycle
causes the client to generate a new discovery data record (DDR). When the DDR is processed by the site server, Discovery Data Manager adds or updates resource information from the DDR in the site database.

File Collection Cycle
When a file is specified for collection, the Microsoft System Center Configuration Manager 2007 software inventory agent searches for that file when it runs a software inventory scan on each client in the site. If the software inventory client agent finds a file that should be collected, the file is attached to the inventory file and sent to the site server. This action differs from software inventory in that it actually sends the file to the site server, so that it can be later viewed using Resource Explorer. This is a part of SCCM inventory functionality.

Hardware Inventory Cycle
collects information such as available disk space, processor type, and operating system about each computer. This is a part of SCCM inventory functionality.

Machine Policy Retrieval & Evaluation Cycle
The client downloads its policy on a schedule. By default, this value is configured to every 60 minutes and is configured with the option Policy polling interval (minutes). However, there might be occasions when you want to initiate ad-hoc policy retrieval from the client—for example, in a troubleshooting scenario or when testing. This action initiates ad-hoc machine policy retrieval from the client outside its scheduled polling interval.

Software Inventory Cycle
collects software inventory data directly from files (such as .exe files) by inventorying the file header information. Configuration Manager 2007 can also inventory unknown files — files that do not have detailed information in their file headers. This provides a flexible, easy-to-maintain software inventory method. You can also have Configuration Manager 2007 collect copies of files that you specify. Software inventory and collected file information for a client can be viewed using Resource Explorer. This is a part of SCCM inventory functionality.

Software Metering Usage Report Cycle
collects the data that allows you to monitor and client software usage.

Software Updates Deployment Evaluation Cycle
initiates a scan for software updates compliance. Before client computers can scan for software update compliance, the software updates environment must be configured.

Software Updates Scan Cycle
Just after a software update installation completes, a scan is initiated to verify that the update is no longer required and to create a new state message that indicates the update has been installed. When the installation has finished but a restart is necessary, the state will indicate that the client computer is pending a restart.

User Policy Retrieval & Evaluation Cycle
Similar to Machine Policy Retrieval & Evaluation Cycle, but this action initiates ad-hoc user policy retrieval from the client outside its scheduled polling interval.

Windows Installer Source List Update Cycle
causes the Product Source Update Manager to complete a full update cycle. When you install an application using Windows Installer, those Windows Installer applications try to return to the path they were installed from when they need to install new components, repair the application, or update the application. This location is called the Windows Installer source location. Windows Installer Source Location Manager can automatically search Configuration Manager 2007 distribution points for the source files, even if the application was not originally installed from a distribution point.

Send an email in Powershell

Below is a very basic Powershell script which can be used to send an email. Not super difficult to figure out how this works but can be useful for adding into a scheduled task or as part of remediation script:

$email = @{
 From = look_out@dinosaurs.com
 To = staff@dinosaurs.com
 Subject = "Danger - Incoming Asteroid"
 SMTPServer = "mailserver.domainname"
 Body = "Danger! Incoming asteroid. Everyone to the escape pods"
 }

send-mailmessage @email


NB it's worth mentioning that you need to put the email addresses in quotation marks.

How the SCCM deploys/installs the CCM Client to a new client/machine

When troubleshooting a failed client install it can be useful to have a basic understanding of how the client installation process actually works. The below is a rough step through of how sccm deploys a client after it discovers a new machine. The following info was mostly cribbed from the MS website but rewritten somewhat:
 

First, SCCM goes in search of new machines......

 

1] SCCM finds a new machine and generates a CCR file (Client Configuration Request). This file contains information about the machine, including the name.

2] The Client Configuration Manager then uses the info in the CCR file to establish a connection to the Admin$ share on the newly discovered machine.

3] From there the Client Configuration Manager sets up a connection to the newly discovered machine’s registry (aka IPC$). If you open up the CCM.log file on the SCCM server you should see this IPC$ connection being established

4] The core components of the client (MobileClient.tcf and CCMsetup.exe) are copied from the \\servername\SMS_[sitecode]\bin\I386 share on the SCCM server into the %windir%\System32\ccmsetup folder on the newly discovered machine.
5] The Client Configuration Manager checks that the CCMsetup service has started and then disconnects from the client machine. The CCR file is added into the \\servername\SMS_[sitecode]\Inboxes\CCRretry.box. The Client Configuration Manager then does a second check of the newly discovered machine, if the SMS Agent Host (ccmexec) is running it deletes the CCR file.

OR

If the Client Configuration Manager establishes that the SMS Agent Host isn’t running or has encountered a problem then it ill rename the CCR file to the name of the newly discovered machine and moved into the \\servername\SMS_[sitecode]\Inboxes\CCRretry.box folder. Client Configuration Manager will check all the logs in this folder every hour for 7 days before deleting them. This info can be viewed in the ccm.log file

 

Meanwhile, bak on the newly discovered machine....

 

1] CCMsetup.exe starts up and then has a look in the MobileClient.tcf file. This file contains configuration info which tells the CCMsetup.exe where to find the Client.msi on the SCCM server. The MobileClient.tcf file also provides other info such as the SMS Site Code, the name of the Management Point and the site boundary.

2] CCMsetup.exe then downloads the client.msi file from the \\servername\SMS_[sitecode]\Client\i386 shared folder on the site server (it can also get it from the Management Point if so configured). The Client.msi installer is installed based on the settings configured in the SCCM console.

 

Once the client is installed, it needs to find itself….

 

1] If the setting has been enabled on the Client Push Installation properties, the client will automatically be assigned to a site using the property SMSSITECODE=AUTO which will prompt it to consult Active Directory for its site assignment. Assuming the AD Schema has been extended, the client will used LDAP to query AD for its site assignment and management point.

OR

 

If the AD Schema has not been extended or the property has not been specified, the client will have a look for a client locator point to ask for a site assignment and directions to the relevant management point.  

2] Once the client has found its default management point, it will kick off its initial request for policies...

WDS not starting - Error 1067: The process terminated unexpectedly

Issue:

“Error 1067: The process terminared unexpectedly” message appears whenever you try to start the Windows Deployment Service

Cause:
Most likely, the last thing you did before the issue occured was to add a new network driver to the bootimage.

Solution:

1. Remove the folder “C:\Windows\Temp\PXEBootFiles” on the SCCM Server.
2. Remove all bootimages from smspxeimages$ distribution point.
3. Remove the drivers that were added to the bootimage.
4. Redistribute the bootimage to the distribution points
5. Start the WDS Service.

 

Install Updates in Task Sequence not installing

Issue:
In spite of the fact that you have put the Install Software Updates step into your task sequence and specified that either all or only mandatory software updates be installed, the Task Sequence installs no updates but simply breezes through this section of your TS. At this point, your TS may look a bit like this:























When you first logon to your newly build machine, it won't have any updates installed on it.

Cause: 
The issue here is that while the CCM client is being installed, it isn't communicating with the SCCM server so isn't aware of what updates are available for it.

Fix:
Essentially, you need to ensure that a full UpdateScan is triggered right after the client has been installed. This will ensure the client talks to the server and sniffs out which updates are available. In order to do this you need to insert an extra step into the Task Sequence:
 

 

The text in the command line is as follows:

WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000113}" /NOINTERACTIVE

 

If, for whatever reason, you need to trigger any other client actions simpy use the one of the following cmd lines:

 

‘Hardware Inventory – 00000000-0000-0000-0000-000000000001 ‘Software Inventory – 00000000-0000-0000-0000-000000000002
‘Data Discovery – 00000000-0000-0000-0000-000000000003
‘Machine Policy Assignment Request – 00000000-0000-0000-0000-000000000021
‘Machine Policy Evaluation – 00000000-0000-0000-0000-000000000022
‘Refresh Default Management Point – 00000000-0000-0000-0000-000000000023
‘Refresh Location (AD site or Subnet) – 00000000-0000-0000-0000-000000000024
‘Software Metering Usage Reporting – 00000000-0000-0000-0000-000000000031
‘Sourcelist Update Cycle – 00000000-0000-0000-0000-000000000032
‘Refresh proxy management point – 00000000-0000-0000-0000-000000000037
‘Cleanup policy – 00000000-0000-0000-0000-000000000040
‘Validate assignments – 00000000-0000-0000-0000-000000000042
‘Certificate Maintenance – 00000000-0000-0000-0000-000000000051
‘Branch DP Scheduled Maintenance – 00000000-0000-0000-0000-000000000061
‘Branch DP Provisioning Status Reporting – 00000000-0000-0000-0000-000000000062
‘Software Update Deployment – 00000000-0000-0000-0000-000000000108
‘State Message Upload – 00000000-0000-0000-0000-000000000111
‘State Message Cache Cleanup – 00000000-0000-0000-0000-000000000112
‘Software Update Scan – 00000000-0000-0000-0000-000000000113
‘Software Update Deployment Re-eval – 00000000-0000-0000-0000-000000000114
OOBS Discovery – 00000000-0000-0000-0000-000000000120



 

 

Advertisement / Package Stuck on “Ready” - Software Distribution currently paused - SCCM 2007

Issue:

The package you have deployed hasn’t been installed on the target machine. If you open the Advertisement Status Reoprt for the package, you encounter no error messages but are instead told that

“The Program for advertisement (xxxxxx) has not been run yet……Software Distribution is currently paused on this computer and it has to be resumed before this program can begin”

 

 Using Client Centre, you can also see that’s something’s not right because the advertisement is listed as being Ready yet is not installing:

 

 

Cause:

The Software Distribution has entered a paused state on the client machine. Most likely due to ghosts in the machine...

 

Resolution:
If you happen to be using Client Centre*, you can simply connect to the client machine and then use the following Client Actions:
 

If you're not using Client Centre, open up the client machine's registry and change the following registry key:

 

x86 – HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Mobile Client\Software Distribution\State\

x64 – HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SMS\Mobile Client\Software Distribution\State\

Set the “Paused” key from 1 to 0

 

Restart ccmexec and keep you fingers crossed it resolves the issue. If it doesn’t you may wish to consider removing and reinstalling the ccm client!



*If you're not using Client Centre, an important question to ask yourself is why not? It's awesome