locked
Using a Program/Package to update SCCM Client on Workgroup systems RRS feed

  • Question

  • So I'm attempting to update the SCCM Client on Workgroup systems using a package/program method. With the following command line arguments:

    CCMSETUP.EXE /noservice SMSSITECODE=SJC DNSSUFFIX=???.???.ca FSP=?????.???.???.ca

    I've masked my MP's host name with ?????.???.???.ca.

    After the client upgrades, the LocationServices.log file on the client system is going crazy and just repeating the below information, and it does not check back in with the management point.

    -----------------------

    Successfully sent security settings refresh message. LocationServices 30/09/2015 11:45:46 AM 3352 (0x0D18)
    Successfully sent location services HTTP failure message. LocationServices 30/09/2015 11:45:46 AM 3352 (0x0D18)
    Error sending HEAD request. HTTP code 403, status 'Forbidden' LocationServices 30/09/2015 11:45:46 AM 3352 (0x0D18)
    [CCMHTTP] ERROR: URL=http://?????.??????.ca, Port=80, Options=224, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE LocationServices 30/09/2015 11:45:46 AM 3352 (0x0D18)
    Raising event:
    instance of CCM_CcmHttp_Status
    {
     ClientID = "GUID:3D1C9441-E988-467A-ACF4-1C5F1012BECA";
     DateTime = "20150930141546.463000+000";
     HostName = "??????.???.???.ca";
     HRESULT = "0x87d0027e";
     ProcessID = 4572;
     StatusCode = 403;
     ThreadID = 3352;
    };

    ------------------------------

    I'm not even sure if this method is supported for upgrading clients on Workgroup systems, but I'm not sure how else it could be done.

    Thoughts?

    Thanks,

    Bill H


    • Edited by Bill Hearn Thursday, October 1, 2015 1:48 PM
    Wednesday, September 30, 2015 6:05 PM

Answers

  • Just to follow-up, we did figure out the issue. When our security team completed a vulnerability assessment on our management point server, they requested that we disable the default IIS webpage, as it was best practice and apparently not used. Well turns out that it is used, and from reviewing the logs it appears as though Workgroup systems determine their location (ie. being over the internet or local intranet), by whether or not they can reach the MPs IIS default page. So if you don't have a certificate authority in place, then the client system will not communicate with the MP. 

    Anyways, re-enabling the default IIS webpage immediately corrected the issue.

    If anyone can provide more insight on this, then please do so, but this is my take on it.


    • Edited by Bill Hearn Wednesday, October 7, 2015 1:35 PM
    • Marked as answer by Bill Hearn Wednesday, October 7, 2015 1:35 PM
    Wednesday, October 7, 2015 1:34 PM

All replies

  • If you are pushing the entire package to the machine then just use

    ccmsetup.exe SMSSitecode=XXX  DNSSUFFIX=dir.slb.com SMSCACHESIZE=2000

    That way it doesn't have to download.  What I have done to make the repair easier on the client is to copy the files to the programdata folder and execute the install from there.  I assume it is trying to download all the files from the MP correct?

    Once you have the client installed you just need to approve it in the console. 


    http://www.sccm-tools.com http://sms-hints-tricks.blogspot.com

    Wednesday, September 30, 2015 6:38 PM
  • Yes. However when I check the "C:\Windows\ccmcache" folder it has already pulled down the package, similar to any program, before attempting to install the update.

    I tried adding the SMSCACHESIZE=2000 command as you specified, however I still have the same issue. So mine now looks like this;
    CCMSETUP.EXE /noservice SMSSITECODE=XXX DNSSUFFIX=XXX.XXX.ca SMSCACHESIZE=2000 FSP=XXXXX.XXX.XXX.ca

    I tried adding that system to the domain, and as soon as I did the problem went away, and everything was great. Removed the system from the domain, and it wouldn't communicate with SCCM again. Weird!

    Thoughts?

    Thursday, October 1, 2015 2:46 PM
  • Add in the SMSMP= and specify the FQDN of a MP.

    http://blogs.technet.com/b/configurationmgr/archive/2014/07/01/managing-workgroup-clients-in-system-center-2012-configuration-manager.aspx


    Cheers Paul | http://sccmentor.wordpress.com

    Thursday, October 1, 2015 2:53 PM
  • (REVISED)

    Thanks Paul. I previously had the SMSMP command in their and defined, and replaced it with the DNSSUFFIX command. Both commands seem to work. However, the clients don't seem to be having a problem finding the MP, just communicating with it. I've since come across this article, which has the exact same symptoms as mine, except I don't have a PKI infrastructure.

    http://blog.coretech.dk/heh/troubleshooting-workgroup-clients-with-pki-not-talking-with-mp/

    Specifically, this error in the ClientIDManagerStartup.log;

    RegTask: Failed to refresh site code. Error: 0x8000ffff

    Thoughts?


    • Edited by Bill Hearn Friday, October 2, 2015 6:17 PM
    Thursday, October 1, 2015 5:22 PM
  • Just to follow-up, we did figure out the issue. When our security team completed a vulnerability assessment on our management point server, they requested that we disable the default IIS webpage, as it was best practice and apparently not used. Well turns out that it is used, and from reviewing the logs it appears as though Workgroup systems determine their location (ie. being over the internet or local intranet), by whether or not they can reach the MPs IIS default page. So if you don't have a certificate authority in place, then the client system will not communicate with the MP. 

    Anyways, re-enabling the default IIS webpage immediately corrected the issue.

    If anyone can provide more insight on this, then please do so, but this is my take on it.


    • Edited by Bill Hearn Wednesday, October 7, 2015 1:35 PM
    • Marked as answer by Bill Hearn Wednesday, October 7, 2015 1:35 PM
    Wednesday, October 7, 2015 1:34 PM