Greetings,

This has happened a few times now over the last couple of weeks. At first I thought it was just a once-off bug, but it keeps coming back and I can't see any patterns to identify the cause or trigger.

Sometimes when I start a Deployment from the Software Center the Status gets stuck at "Installing" and never moves beyond that. It has happened for OSD task sequences as well as Package/programs. In both cases the same Deployment works on other machines, or has worked on this same machine previously. It's not always the same programs, and there seems to be no particular pattern I can find to cause it.

Restarting the SMS Agent doesn't resolve, it just comes up as "Installing" again after the agent has restarted. I've tried clearing the adverts from the client and no difference, restarting the computer also makes no difference... it just comes back as "Installing"

If I remove the computer from the deployment, it dissapears from the Software Center, and when I add the deployment back again it re-appears in Software Center as "Installing" again.

Doing a client repair (ccmrepair) doesn't fix it. Doing a client re-install (with always re-install) doesn't fix it either. I have to completely remove the existing client and reinstall to clear the problem, but that makes the client then appear as a completely new device in CM12 so that's not a very reasonable resolution.

The only log entry I can find that seems to indicate an error is in execmgr.log where an entry saying "OnContentAvailable invalid request GUID handle" appears several times. I have no idea what it means. Running the same deployment on another computer works fine.

Clients are all Windows7 SP1 32bit.

No, just Task sequences and Package/Programs are what I've had it happen on so far.

I've gone through *all* the logs, all the SMS/CCM relates registry keys and files and I can't work out where the status that locks it at "installing" is stored. Manually clearing out advert history etc makes no difference, it just stays there "Installing". As I mentioned, execmgr.log is the only place that actually shows "something" is not working, but the "OnContentAvailable invalid request GUID handle" message doesn't seem to have a lot of details to identify the problem.

I've tried the Deployment Monitoring Tool already, as well as all the other tools in the Toolkit, but none of them seem to see a problem. In fact, the DMT show nothing at all (these are all optional deployments)

This is a real pain. when it happens, no other deployments can run, they just stop at "Waiting to install" because of the one that is stuck "Installing"

I'm sure the "OnContentAvailable invalid request GUID handle" message is important, but there just doesn't seem to be any information I can find about what it means.

The Deployment Monitoring Tool doesn't show any details for Package & Program or Task Sequence deployments.  CliSpy.exe is the TShooting tool for these legacy types of deployments.

The installation of Package & Program is being interrupted in some way.  A CCMExec crash looks very similar (stuck at Installing).   The ExecMgr log is a good source of information for the issue.  

Considering that you're seeing the "OnContentAvailable invalid request GUID handle", it might be a good idea to confirm that the content for the package/program was downloaded successfully.  For Package/Program, this could either be ran from the DP or downloaded to the \Windows\CcmCache folder.  The logs related to content download are CAS.log, ContentTransferManager.log and the DataTransferService.log. 

That's why I'm stuck with this. CAS, ContentTransferManager and DataTransferService logs are all fine. It finds all the content and it's all in the CCMCache... waiting...

What I'd love to know is *what* the Software Center is reading (file, registry, WMI?) that tells it to show the status as "Installing". Considering that restarting the client doesn't reset that state at all, I'm guessing it's set somewhere by something, and just being read by SC to show that status.

Software Center is reading instances of the CCM_Program WMI class in the root\ccm\clientsdk namespace.  I'm not sure if this will help though as the UI is likely just reflecting the properties of the objects defined there.

The more relevent information is in the ExecMgr.log, which contains log entries showing the state transitions for the program execution.  Log entries like this:

Raising client SDK event for class CCM_Program, instance ..., actionType 10l, ...

Action type = 10  >> Program execute complete.  This event is what causes the Software Center UI to go from "Installing" to "Installed".

Got the same problem.
Sometimes(1in15+-) when I try to install a OSD in software center the task sequence window never show up ,but the software center shows the status "installing" ,forever!

Only solution i've found for this problem so far is to reinstall the machine...

Create a task sequence to delete the ccmcache folder contents (C:\windows\ccmcache) and see if that works.  I have noticed I have to do that when I have an item that is set to download then install instead of install from the distro point.

I was having the same issue on a task sequence I advertised to run daily on a set of machines. One machine was stuck installing in Software Center and any repair, uninstall/reinstall, etc would not fix it. After searching through WMI I was able to find that the advertisement was stuck in an evaluationstate of 14, while all my other successful deployments were in 17.

Get-WmiObject -namespace root\ccm\clientsdk -class ccm_program | select fullname,evaluationstate

I tried using .put() and a few other methods but could not change the state. I finally used Client Center for ConfigMgr to delete 'root\ccm', repair the ConfigMgr client, and this resolved it!

• Proposed as answer by DanielRatliff Tuesday, July 16, 2013 6:53 PM

I was having the same issue on a task sequence I advertised to run daily on a set of machines. One machine was stuck installing in Software Center and any repair, uninstall/reinstall, etc would not fix it. After searching through WMI I was able to find that the advertisement was stuck in an evaluationstate of 14, while all my other successful deployments were in 17.

Get-WmiObject -namespace root\ccm\clientsdk -class ccm_program | select fullname,evaluationstate

I tried using .put() and a few other methods but could not change the state. I finally used Client Center for ConfigMgr to delete 'root\ccm', repair the ConfigMgr client, and this resolved it!

• Proposed as answer by DanielRatliff Tuesday, July 16, 2013 6:53 PM

I was having the same issue on a task sequence I advertised to run daily on a set of machines. One machine was stuck installing in Software Center and any repair, uninstall/reinstall, etc would not fix it. After searching through WMI I was able to find that the advertisement was stuck in an evaluationstate of 14, while all my other successful deployments were in 17.

Get-WmiObject -namespace root\ccm\clientsdk -class ccm_program | select fullname,evaluationstate

I tried using .put() and a few other methods but could not change the state. I finally used Client Center for ConfigMgr to delete 'root\ccm', repair the ConfigMgr client, and this resolved it!

• Proposed as answer by DanielRatliff Tuesday, July 16, 2013 6:53 PM

I was having the same issue on a task sequence I advertised to run daily on a set of machines. One machine was stuck installing in Software Center and any repair, uninstall/reinstall, etc would not fix it. After searching through WMI I was able to find that the advertisement was stuck in an evaluationstate of 14, while all my other successful deployments were in 17.

Get-WmiObject -namespace root\ccm\clientsdk -class ccm_program | select fullname,evaluationstate

I tried using .put() and a few other methods but could not change the state. I finally used Client Center for ConfigMgr to delete 'root\ccm', repair the ConfigMgr client, and this resolved it!

• Proposed as answer by DanielRatliff Tuesday, July 16, 2013 6:53 PM

Did anyone find a better fix for this?  I am also seeing this on several machines and can not find the cause.  These are freshly imaged machines all with the same image and same TS deployments.  Some will work fine and others get stuck at "Installing" forever.

All of my clients are Windows 7 x64 SP1

SCCM 2012 SP1 CU2

Execmgr.log shows lots of: OnContentAvailable invalid request GUID handle execmgr 3980 (0x0F8C) and some (ContentAvailable ignoring update with no DPs for content request ID) (IMaintenanceCoordinator::RemoveTask failed with error code 0x87d00317)

• Edited by jtwaddle Monday, August 26, 2013 9:26 PM

Did anyone find a better fix for this?  I am also seeing this on several machines and can not find the cause.  These are freshly imaged machines all with the same image and same TS deployments.  Some will work fine and others get stuck at "Installing" forever.

All of my clients are Windows 7 x64 SP1

SCCM 2012 SP1 CU2

Execmgr.log shows lots of: OnContentAvailable invalid request GUID handle execmgr 3980 (0x0F8C) and some (ContentAvailable ignoring update with no DPs for content request ID) (IMaintenanceCoordinator::RemoveTask failed with error code 0x87d00317)

• Edited by jtwaddle Monday, August 26, 2013 9:26 PM

Did anyone find a better fix for this?  I am also seeing this on several machines and can not find the cause.  These are freshly imaged machines all with the same image and same TS deployments.  Some will work fine and others get stuck at "Installing" forever.

All of my clients are Windows 7 x64 SP1

SCCM 2012 SP1 CU2

Execmgr.log shows lots of: OnContentAvailable invalid request GUID handle execmgr 3980 (0x0F8C) and some (ContentAvailable ignoring update with no DPs for content request ID) (IMaintenanceCoordinator::RemoveTask failed with error code 0x87d00317)

• Edited by jtwaddle Monday, August 26, 2013 9:26 PM

Did anyone find a better fix for this?  I am also seeing this on several machines and can not find the cause.  These are freshly imaged machines all with the same image and same TS deployments.  Some will work fine and others get stuck at "Installing" forever.

All of my clients are Windows 7 x64 SP1

SCCM 2012 SP1 CU2

Execmgr.log shows lots of: OnContentAvailable invalid request GUID handle execmgr 3980 (0x0F8C) and some (ContentAvailable ignoring update with no DPs for content request ID) (IMaintenanceCoordinator::RemoveTask failed with error code 0x87d00317)

• Edited by jtwaddle Monday, August 26, 2013 9:26 PM

same issue here, win7x64sp1 - sccm2012 sp1 cu2.

i opened a ticket with MS Support today, because this is not the first time i have seen this happening, and so far all attempts to resolve this (reboots, service restarts, cache resets, ...) failed.

My issue pointed back to the good old having too many updates/TS/whatever applied to the machines.  I just had a general collection which I applied all updates.

Now I have collections separated by OS and I don't see this issue anymore, but I assume I will once there are too many updates for an OS.

In my opinion this is a huge bug, but it has been a problem for a while and it doesn't look like MS thinks it is.

thanks for this info, but that cant be the issue in our case. we already have OS seperated collections, i even went so far to split normal updates, .net updates, Office updates, lync updates. ... etc into different patch groups, ADR rules and collections.

i just uploaded the diagnostic logs to MS, let's see what happens next.

Hi,

Did anyone get a solution for this?

Since I had this problem, all new environments I've built had CM2012 SP1 installed and I've never seen it again. I don't know if SP1 "fixed" the problem, or some other change in the way I did the installs prevented it though. I've never been able to reproduce it.

The client I installed this at hasn't told me about the problem happening recently. I might send them a follow up to see if they have seen it again.

I still battle with this every now and then. We still have our 45 or so machines that have three task sequences that run daily on them for maintenance purposes.

Instead of using Client Center I now just blow away WMI and run CCMRepair.exe.

1. net stop winmgmt

2. winmgmt /resetrepository

3. Reboot

4. CCMRepair.exe

It may be overly intrusive but it helps prevent the issue alot longer than just blowing away the CCM reposirtory.

We are on SP1 CU3, so it does not appear SP1 fixed it for us.

• Proposed as answer by Office Dragon Monday, December 22, 2014 8:42 PM

I still battle with this every now and then. We still have our 45 or so machines that have three task sequences that run daily on them for maintenance purposes.

Instead of using Client Center I now just blow away WMI and run CCMRepair.exe.

1. net stop winmgmt

2. winmgmt /resetrepository

3. Reboot

4. CCMRepair.exe

It may be overly intrusive but it helps prevent the issue alot longer than just blowing away the CCM reposirtory.

We are on SP1 CU3, so it does not appear SP1 fixed it for us.

• Proposed as answer by Office Dragon Monday, December 22, 2014 8:42 PM

I still battle with this every now and then. We still have our 45 or so machines that have three task sequences that run daily on them for maintenance purposes.

Instead of using Client Center I now just blow away WMI and run CCMRepair.exe.

1. net stop winmgmt

2. winmgmt /resetrepository

3. Reboot

4. CCMRepair.exe

It may be overly intrusive but it helps prevent the issue alot longer than just blowing away the CCM reposirtory.

We are on SP1 CU3, so it does not appear SP1 fixed it for us.

• Proposed as answer by Office Dragon Monday, December 22, 2014 8:42 PM

I still battle with this every now and then. We still have our 45 or so machines that have three task sequences that run daily on them for maintenance purposes.

Instead of using Client Center I now just blow away WMI and run CCMRepair.exe.

1. net stop winmgmt

2. winmgmt /resetrepository

3. Reboot

4. CCMRepair.exe

It may be overly intrusive but it helps prevent the issue alot longer than just blowing away the CCM reposirtory.

We are on SP1 CU3, so it does not appear SP1 fixed it for us.

• Proposed as answer by Office Dragon Monday, December 22, 2014 8:42 PM

Hi,

We face these issues as well and are currently on SP1 CU3 as well.

The way to resolve these kind of issues we've found:

Open WBEMTEST

Connect to Root\ccm

Query

Select * from sms_maintenancetaskrequests

Remove/Delete all the entries that are displayed

Net stop CCMEXEC & Net start ccmexec, now you should be able to rerun your advertisements..

I find it pretty rude to recreate the whole repository

//Daniel

Has anyone found a resolution to this? I am getting this every time I install the SCCM 2012 R2 client on my Windows Server 2008 VM.  The only resolution I've found that works is CCMSETUP /uninstall, and then reinstall.  This is not an acceptable solution.

I tried a root\ccm::SMS_Client.ResetPolicy(1) and this didn't seem to help.

I haven't seen this issue reappear (or had it reported to me) since I first asked about it. The client where it was happening says it stopped after they did one of the service pack upgrades.

I wasn't able to fix it by just uninstalling the client, so you might have a *slightly* different issue. Is it just one machine you are seeing it happen on?

sorry to bump an old thread.

Did you get anywhere with the MS Ticket you raised?

We've been having this issue since using 2012 Daniell1987's WBEMTEST method generally, however for an automated deployment solution, it would be nice not to have to baby sit the Task Sequences to help them along when they get stuck!

Hi all,

Again old thread but has anyone found the root cause of this?

I have SCCM 2012 R2 environment, two domains with one sites server on each domain. This issue is happening on both environments. 

It first occurred when using a package consisting of 39 MS updates - Win7, .NET, Office 2010 and Lync 2010. This was packaged up, downloaded and deployed on both domains to test machines. I am currently still in this test phase and itching to get these patches out to the estate.

My failure rate does seem alarmingly high as i have tested on three test machines on each domain and two saw this issue. So four out of six. 

Now it seems to happen on the affected machines with a single update in a deployment.

Another issue with this is that it prevents the machines from shutting down. It hangs on the Shutting Down screen (left one overnight). Plus, it seems to impact explorer.exe as I cannot open USB devices (get the slow loading green bar in directory path field). 

I am going to try the workarounds mentioned in this post, but knowing and fixing the root cause is required.

Want to also add that I cannot see any obvious errors in log files. When I think I have found a useful error, it does not appear on the other machines, so not related to each other.

I'm also having the same issue on my test computers.

I'm in testing phase of SCCM 2012 and once I had this issue and could not recover whatever I do didn't work and stuck at installing state.

My Agent Version is 5.007958.1000

 One important note !

I found some logs like below in smsts.log

Task sequence execution failed with error code 80070002
Error setting HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\Task Sequence\Program. code 80070002]
Error - could not get package and program IDs. code 80070002

the link below mentions that  KB2965788 requires multiple restart that's why SCCM agent can not handle the second restart and hangs. It could be true because I was just installed this KB with Software update before running this TS.

http://ardamis.com/2014/06/12/microsoft-security-update-kb2965788-requires-multiple-restarts/

This is an old topic, but I haven't encountered it again since my last update so I've never resolved it. Apologies to anyone else still encountering this issue and finding this thread. I don't know if any of the posts above is an effective solution, but if anyone is aware of a solid solution I'll keep watching this topic and will mark any confirmed solution as such.

Just an update on our end. We have had a case open with Microsoft on this issue for the past couple months. We are now on ConfigMgr 2012 R2 CU1 and Microsoft believed CU3 fixed it but unfortunately it did not. Still working through the case, trying different fixes.

One item to point out, currently Application deployments via Task Sequence are not supported by Microsoft, so support is limited.

One item to point out, currently Application deployments via Task Sequence are not supported by Microsoft, so support is limi

I still battle with this every now and then. We still have our 45 or so machines that have three task sequences that run daily on them for maintenance purposes.

Instead of using Client Center I now just blow away WMI and run CCMRepair.exe.

1. net stop winmgmt

2. winmgmt /resetrepository

3. Reboot

4. CCMRepair.exe

It may be overly intrusive but it helps prevent the issue alot longer than just blowing away the CCM reposirtory.

We are on SP1 CU3, so it does not appear SP1 fixed it for us.

Not sure if this is a fix for the original condition, but I just had a stuck "Installing" OSD TS that this sorted out... however I had been mucking around with things so it's quite possible I caused it for other reasons.

Still no solid explanation for why it actually happens, or a slightly less "sledgehammer" approach to fixing it

• Edited by Scott Williams - IP1 Friday, February 20, 2015 6:44 AM

I still battle with this every now and then. We still have our 45 or so machines that have three task sequences that run daily on them for maintenance purposes.

Instead of using Client Center I now just blow away WMI and run CCMRepair.exe.

1. net stop winmgmt

2. winmgmt /resetrepository

3. Reboot

4. CCMRepair.exe

It may be overly intrusive but it helps prevent the issue alot longer than just blowing away the CCM reposirtory.

We are on SP1 CU3, so it does not appear SP1 fixed it for us.

Not sure if this is a fix for the original condition, but I just had a stuck "Installing" OSD TS that this sorted out... however I had been mucking around with things so it's quite possible I caused it for other reasons.

Still no solid explanation for why it actually happens, or a slightly less "sledgehammer" approach to fixing it

• Edited by Scott Williams - IP1 Friday, February 20, 2015 6:44 AM

I still battle with this every now and then. We still have our 45 or so machines that have three task sequences that run daily on them for maintenance purposes.

Instead of using Client Center I now just blow away WMI and run CCMRepair.exe.

1. net stop winmgmt

2. winmgmt /resetrepository

3. Reboot

4. CCMRepair.exe

It may be overly intrusive but it helps prevent the issue alot longer than just blowing away the CCM reposirtory.

We are on SP1 CU3, so it does not appear SP1 fixed it for us.

Not sure if this is a fix for the original condition, but I just had a stuck "Installing" OSD TS that this sorted out... however I had been mucking around with things so it's quite possible I caused it for other reasons.

Still no solid explanation for why it actually happens, or a slightly less "sledgehammer" approach to fixing it

• Edited by Scott Williams - IP1 Friday, February 20, 2015 6:44 AM

I still battle with this every now and then. We still have our 45 or so machines that have three task sequences that run daily on them for maintenance purposes.

Instead of using Client Center I now just blow away WMI and run CCMRepair.exe.

1. net stop winmgmt

2. winmgmt /resetrepository

3. Reboot

4. CCMRepair.exe

It may be overly intrusive but it helps prevent the issue alot longer than just blowing away the CCM reposirtory.

We are on SP1 CU3, so it does not appear SP1 fixed it for us.

Not sure if this is a fix for the original condition, but I just had a stuck "Installing" OSD TS that this sorted out... however I had been mucking around with things so it's quite possible I caused it for other reasons.

Still no solid explanation for why it actually happens, or a slightly less "sledgehammer" approach to fixing it

• Edited by Scott Williams - IP1 Friday, February 20, 2015 6:44 AM

We still have our case open with Microsoft. We have gotten alot further. They provided a beta .dll to replace in the client to allow some major debug logging. We are working directly with a developer, so hope are high. They are analyzing all the logs we gathered a few weeks ago.

I have exactly the same problem. Do you already have a fix from Microsoft?

We think we might have found the issue! So far testing on two machines has resolved it after a reboot.

Currently, to save boot/login times our CCMExec service is set to Automatic (Delayed Start), this appears to be part of the issue.

To fix:

• Change the startup type for SMS Agent Host to Automatic . 
• Add SMS Agent Host as  a dependency for ConfigMgr Task Sequence Agent.

We are confirming on some more machines, but hopes are high!

We see this in our environment as well. It is caused because some of our advertisements (TS that deploys multiple software titles is the primary culprit here) shut down the sccm agent host service and reboot the machine before the SCCM agent can finish updating all the WMI classes, but after the actual advertisement is completed. Namely, root/ccm/clientsdk:ccm_program class isn't updated before the service is stopped. It was posted earlier in this thread, but the state is left at 14 (installing) instead of 17 (installed). You can delete the instance of the policy for the deployment with powershell:

foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter "ADV_AdvertisementID='<advertID>'"){$i.delete()}

Deleting the policy related to the deployment that is stuck in that state seems to delete the instance of the ccm_program class as well. I also delete any instances of the ccm_Tsexecutionrequest class just to make sure. Then I restart the client and do a machine policy refresh. This *usually* clears out the offending entry from the ccm_program class.

I am able to recreate the problem on demand by rebooting the machine while the deployment is in the "installing" state in software center - or when the clientsdk class is in the evaluationstate=14. I will try adding the sms agent host as a dependency for TS agent, but I think in my case it is too late after the reboot.

On another note, I am very interested to find any documentation regarding this comment from DanielR:

If you are installing applications during an OSD task sequence, it is supported. If you are simply using task sequences to deploy a list of applications, that is currently not supported.

I was pretty much told this at one point in the past by a MS engineer that was on site a few years back when he saw what we were doing - "Task sequences weren't really designed to be used that way..." but I can't find anything on the web stating it isn't supported. We use a TS to deploy software and it causes so many headaches and requires a lot of administrative time.

• Edited by mdkelley 11 hours 8 minutes ago

We see this in our environment as well. It is caused because some of our advertisements (TS that deploys multiple software titles is the primary culprit here) shut down the sccm agent host service and reboot the machine before the SCCM agent can finish updating all the WMI classes, but after the actual advertisement is completed. Namely, root/ccm/clientsdk:ccm_program class isn't updated before the service is stopped. It was posted earlier in this thread, but the state is left at 14 (installing) instead of 17 (installed). You can delete the instance of the policy for the deployment with powershell:

foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter "ADV_AdvertisementID='<advertID>'"){$i.delete()}

Deleting the policy related to the deployment that is stuck in that state seems to delete the instance of the ccm_program class as well. I also delete any instances of the ccm_Tsexecutionrequest class just to make sure. Then I restart the client and do a machine policy refresh. This *usually* clears out the offending entry from the ccm_program class.

I am able to recreate the problem on demand by rebooting the machine while the deployment is in the "installing" state in software center - or when the clientsdk class is in the evaluationstate=14. I will try adding the sms agent host as a dependency for TS agent, but I think in my case it is too late after the reboot.

On another note, I am very interested to find any documentation regarding this comment from DanielR:

If you are installing applications during an OSD task sequence, it is supported. If you are simply using task sequences to deploy a list of applications, that is currently not supported.

I was pretty much told this at one point in the past by a MS engineer that was on site a few years back when he saw what we were doing - "Task sequences weren't really designed to be used that way..." but I can't find anything on the web stating it isn't supported. We use a TS to deploy software and it causes so many headaches and requires a lot of administrative time.

• Edited by mdkelley Wednesday, April 29, 2015 8:35 PM

We see this in our environment as well. It is caused because some of our advertisements (TS that deploys multiple software titles is the primary culprit here) shut down the sccm agent host service and reboot the machine before the SCCM agent can finish updating all the WMI classes, but after the actual advertisement is completed. Namely, root/ccm/clientsdk:ccm_program class isn't updated before the service is stopped. It was posted earlier in this thread, but the state is left at 14 (installing) instead of 17 (installed). You can delete the instance of the policy for the deployment with powershell:

foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter "ADV_AdvertisementID='<advertID>'"){$i.delete()}

Deleting the policy related to the deployment that is stuck in that state seems to delete the instance of the ccm_program class as well. I also delete any instances of the ccm_Tsexecutionrequest class just to make sure. Then I restart the client and do a machine policy refresh. This *usually* clears out the offending entry from the ccm_program class.

I am able to recreate the problem on demand by rebooting the machine while the deployment is in the "installing" state in software center - or when the clientsdk class is in the evaluationstate=14. I will try adding the sms agent host as a dependency for TS agent, but I think in my case it is too late after the reboot.

On another note, I am very interested to find any documentation regarding this comment from DanielR:

If you are installing applications during an OSD task sequence, it is supported. If you are simply using task sequences to deploy a list of applications, that is currently not supported.

I was pretty much told this at one point in the past by a MS engineer that was on site a few years back when he saw what we were doing - "Task sequences weren't really designed to be used that way..." but I can't find anything on the web stating it isn't supported. We use a TS to deploy software and it causes so many headaches and requires a lot of administrative time.

• Edited by mdkelley Wednesday, April 29, 2015 8:35 PM

We see this in our environment as well. It is caused because some of our advertisements (TS that deploys multiple software titles is the primary culprit here) shut down the sccm agent host service and reboot the machine before the SCCM agent can finish updating all the WMI classes, but after the actual advertisement is completed. Namely, root/ccm/clientsdk:ccm_program class isn't updated before the service is stopped. It was posted earlier in this thread, but the state is left at 14 (installing) instead of 17 (installed). You can delete the instance of the policy for the deployment with powershell:

foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter "ADV_AdvertisementID='<advertID>'"){$i.delete()}

Deleting the policy related to the deployment that is stuck in that state seems to delete the instance of the ccm_program class as well. I also delete any instances of the ccm_Tsexecutionrequest class just to make sure. Then I restart the client and do a machine policy refresh. This *usually* clears out the offending entry from the ccm_program class.

I am able to recreate the problem on demand by rebooting the machine while the deployment is in the "installing" state in software center - or when the clientsdk class is in the evaluationstate=14. I will try adding the sms agent host as a dependency for TS agent, but I think in my case it is too late after the reboot.

On another note, I am very interested to find any documentation regarding this comment from DanielR:

If you are installing applications during an OSD task sequence, it is supported. If you are simply using task sequences to deploy a list of applications, that is currently not supported.

I was pretty much told this at one point in the past by a MS engineer that was on site a few years back when he saw what we were doing - "Task sequences weren't really designed to be used that way..." but I can't find anything on the web stating it isn't supported. We use a TS to deploy software and it causes so many headaches and requires a lot of administrative time.

• Edited by mdkelley Wednesday, April 29, 2015 8:35 PM

We see this in our environment as well. It is caused because some of our advertisements (TS that deploys multiple software titles is the primary culprit here) shut down the sccm agent host service and reboot the machine before the SCCM agent can finish updating all the WMI classes, but after the actual advertisement is completed. Namely, root/ccm/clientsdk:ccm_program class isn't updated before the service is stopped. It was posted earlier in this thread, but the state is left at 14 (installing) instead of 17 (installed). You can delete the instance of the policy for the deployment with powershell:

foreach($i in gwmi -Namespace root/ccm/policy/machine/actualconfig -Class ccm_softwaredistribution -Filter "ADV_AdvertisementID='<advertID>'"){$i.delete()}

Deleting the policy related to the deployment that is stuck in that state seems to delete the instance of the ccm_program class as well. I also delete any instances of the ccm_Tsexecutionrequest class just to make sure. Then I restart the client and do a machine policy refresh. This *usually* clears out the offending entry from the ccm_program class.

I am able to recreate the problem on demand by rebooting the machine while the deployment is in the "installing" state in software center - or when the clientsdk class is in the evaluationstate=14. I will try adding the sms agent host as a dependency for TS agent, but I think in my case it is too late after the reboot.

On another note, I am very interested to find any documentation regarding this comment from DanielR:

If you are installing applications during an OSD task sequence, it is supported. If you are simply using task sequences to deploy a list of applications, that is currently not supported.

I was pretty much told this at one point in the past by a MS engineer that was on site a few years back when he saw what we were doing - "Task sequences weren't really designed to be used that way..." but I can't find anything on the web stating it isn't supported. We use a TS to deploy software and it causes so many headaches and requires a lot of administrative time.

• Edited by mdkelley Wednesday, April 29, 2015 8:35 PM

On another note, I am very interested to find any documentation regarding this comment from DanielR:

If you are installing applications during an OSD task sequence, it is supported. If you are simply using task sequences to deploy a list of applications, that is currently not supported.

I was pretty much told this at one point in the past by a MS engineer that was on site a few years back when he saw what we were doing - "Task sequences weren't really designed to be used that way..." but I can't find anything on the web stating it isn't supported. We use a TS to deploy software and it causes so many headaches and requires a lot of administrative time.

Microsoft has confirmed this is a bug! We have tested on over a dozen machines and setting the dependency of CCMexec on SMSTSMgr has fixed every single one! Basically the CCMExec service has to start before the SMSTSMgr service can.

Our SEE will be filing a bug to be fixed in a later version. Try it out everyone and see if it works for you!

I have written a simply powershell script and uploaded it.

Please let me know if there are any errors in my script.

If would be interested to know if anyone has a report allowing you to identify the problem machines.

Mike

• Edited by MikePalmer 21 hours 46 minutes ago

I have written a simply powershell script and uploaded it.

Please let me know if there are any errors in my script.

If would be interested to know if anyone has a report allowing you to identify the problem machines.

Mike

• Edited by MikePalmer Sunday, May 10, 2015 9:59 AM

I have written a simply powershell script and uploaded it.

Please let me know if there are any errors in my script.

If would be interested to know if anyone has a report allowing you to identify the problem machines.

Mike

• Edited by MikePalmer Sunday, May 10, 2015 9:59 AM

I have written a simply powershell script and uploaded it.

Please let me know if there are any errors in my script.

If would be interested to know if anyone has a report allowing you to identify the problem machines.

Mike

• Edited by MikePalmer Sunday, May 10, 2015 9:59 AM

I have written a simply powershell script and uploaded it.

Please let me know if there are any errors in my script.

If would be interested to know if anyone has a report allowing you to identify the problem machines.

Mike

• Edited by MikePalmer Sunday, May 10, 2015 9:59 AM

Hi Daniel

I had made the service dependency and checked however the status not changed so should i remove and re trigger the deployment on the machine or how did it work.

I will try reproducing on another machine and see how it goes.

Hi Daniel

I had made the service dependency and checked however the status not changed so should i remove and re trigger the deployment on the machine or how did it work.

I will try reproducing on another machine and see how it goes.

We simply had to restart the machine after setting the dependency and the status was back to Installed on boot up.

MikePalmer, that script looks good, I will put a note on my blog about it!

http://www.potentengineer.com/task-sequence-stuck-installing-in-software-center/

Hi Daniel,

Thank-you for confirming the script works and adding it to your blog.

I also have a DCM version for anyone who is interested - https://gallery.technet.microsoft.com/Add-SMSTSMGR-Service-7524d468

Hi Daniel,

Thank-you for confirming the script works and adding it to your blog.

I also have a DCM version for anyone who is interested - https://gallery.technet.microsoft.com/Add-SMSTSMGR-Service-7524d468

• Marked as answer by Scott Williams - IP1 9 hours 37 minutes ago

Hi Daniel,

Thank-you for confirming the script works and adding it to your blog.

I also have a DCM version for anyone who is interested - https://gallery.technet.microsoft.com/Add-SMSTSMGR-Service-7524d468

• Marked as answer by Scott Williams - IP1 Thursday, July 02, 2015 10:10 PM

Hi Daniel,

Thank-you for confirming the script works and adding it to your blog.

I also have a DCM version for anyone who is interested - https://gallery.technet.microsoft.com/Add-SMSTSMGR-Service-7524d468

• Marked as answer by Scott Williams - IP1 Thursday, July 02, 2015 10:10 PM

Hi Daniel,

Thank-you for confirming the script works and adding it to your blog.

I also have a DCM version for anyone who is interested - https://gallery.technet.microsoft.com/Add-SMSTSMGR-Service-7524d468

• Marked as answer by Scott Williams - IP1 Thursday, July 02, 2015 10:10 PM

was just looking at the script and it appears to set smstsmgr as a dependency of ccmexec.  From what I read from Daniel, shouldn't it be ccmexec is set as a dependency on smstsmgr instead?

I think you are right! Just looked at the post and it is backwards.

MikePalmer, can you switch it? CCMExec has to start first, not SMSTSMgr.

Hi,

I have modified the code but I have not been able to test it as I'm away with family for the weekend.

@Daniel - Would you be able to validate it for me?

# Get Service Details 
$service = get-service smstsmgr

# Check ServiceDependedOn Array 
if (($service.ServicesDependedOn).name -notcontains "ccmexec") 
{ 
 write-host "Not present...Configuring Service" 
 start-process sc.exe -ArgumentList "config smstsmgr depend= ccmexec" -wait 
} 
else 
{ 
 write-host "Present..Taking no action" 
} 

Mike

Looks mostly correct, except you left out the winmgmt dependency.

Think it should be:

"config smstsmgr depend= winmgmt/ccmexec"

Just tested looks good.

jkbd80 is correct though. The SMSTSMgr service already has a dependency on WinMgmt, your script is removing it. Will definitely need both.

interestingly enough the customer I am at at now had this happen on a server being built on a 2012R2 hierarchy. This is the only time they've seen it happen after building several hundred thousand computers.

We tried the suggested WMI and service dependant suggestions but that didn't help at all, so perhaps there was some other issue showing the same symptoms. In the end we just rebuilt the machine.

I'll mark yours as the answer though given it seems to be a solution in at least some instances, and if something more permanent is released by Microsoft we can update the the answer.

Thanks Scott, if you run into it again, you might be able to verify by checking WMI for the EvaluationState. 

Get-wmiobject namespace root\ccm\clientsdk class ccm_program | select packageid,fullname,evaluationstate | where {$_.evaluationstate ne 1}

During testing scenario we have found following:

Start an available task sequence (TS) in software center (SC) and reboot the PC during the TS (cold reboot so power off/power on).

In some cases, after reboot, I saw the status of the TS was failed in SC. But there was no center reporting of that failure AND C:\_SMSTaskSequence\TSenv.dat still existed. So, failed TS but existing TSenv.dat. 

I other cases, you get an error (central log) but after reboot the TS starts again, it fails but
than the status becomes "Installing" in SC.  So, failed TS but it's still 'installing' in SC.

When I read this forum it is metnioned here this is bug. Does anybody know when it will be fixed? Because we are at the beginning of the migration and would like to avoid this.

Working bypass for us is quite heavy  (delete 'root\ccm' & repair the ConfigMgr client).

Thank you for update