Deerstalker
-
Posts
4 -
Joined
-
Last visited
Posts posted by Deerstalker
-
-
The user that you have setup in sccm 2012 an administrator on the client?
Not sure what you mean: I am the logged in user on the client, and I am an administrator. But that shouldn't matter: I thought SCCM apps install using the SYSTEM user.
When it is installing (as a required application) check the task manager processes and see if the ccmexec.exe is running. If its not, then we know more if it is a client/server/package issue.
Also, is your advertisement for the required application setup to "run program from distribution point" or "download content from distribution point and run locally?" (Advertisement - Properties - Distribution Point tab)
Yep, ccmexec.exe is running.
As far as I can tell, SCCM 2012 does not give you the option of where to run from. What you're descibing is where it was in 2007, and I can't find a similar option in 2012.
-
Thanks for the response, yes, I've run it manually:
I have a script that installs just fine manuallyAlso note that it also installs without a hitch when made available. It only hangs when the deployment is made required.
-
I have a script that installs just fine manually, or if I set it up as an available application. But if I make it a required application, the client tries to install it (status in Software Center changes to "Installing"), and then fails after it times out. There are no error messages in the Event Viewer, and the only errors I've found in any SCCM logs just state that the application timed out.
It seems to me that the script is waiting for a response, but I can't see how, since it works when it is an available application. I'm at a loss for how to troubleshoot. Any suggestions?
TS failed 0x80004005 - while retrieving policy
in Configuration Manager 2012
Posted
For future researchers: I ran into this problem yesterday, with these errors in smsts.log:
reply has no message header marker TSPxe 7/13/2016 11:34:08 AM 1644 (0x066C)
DoRequest (sReply, false), HRESULT=80004005 (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,7299) TSPxe 7/13/2016 11:34:08 AM 1644 (0x066C)
SendReport (L"mp:[http]MP_DdrEndpoint", L"MP_DdrEndpoint", L"{00000000-0000-0000-0000-000000000003}", 0, true, sReportBody.c_str()), HRESULT=80004005 (e:\nts_sccm_release\sms\framework\osdmessaging\libsmsmessaging.cpp,7704) TSPxe 7/13/2016 11:34:08 AM 1644 (0x066C)
oClientDDR.SendDDR(), HRESULT=80004005 (e:\nts_sccm_release\sms\framework\tscore\tspolicy.cpp,568) TSPxe 7/13/2016 11:34:08 AM 1644 (0x066C)
Failed to send DDR (0x80004005) TSPxe 7/13/2016 11:34:08 AM 1644 (0x066C)
SendDDR (&m_oHttpTransport, m_sSiteCode.c_str(), sMediaGuid.c_str(), m_sClientIdentity), HRESULT=80004005 (e:\nts_sccm_release\sms\framework\tscore\tspolicy.cpp,952) TSPxe 7/13/2016 11:34:08 AM 1644 (0x066C)
failed to send the DDR (0x80004005) TSPxe 7/13/2016 11:34:08 AM 1644 (0x066C)
In our case, it had nothing to do with the time or certs. The database was out of disk space! Expanded the disk and all is well this morning. Too bad the error isn't a little more helpful about the problem...