none
Manual install of SCCM on different domain workstation failing RRS feed

  • Question

  • edited: Sept 9, 2019 was able to do manual install via usage of /NoCRLCheck parameter, but problems persisted. Leaving thread title the same.

    Hello,

    We've had an SCCM server currently on 1902 that has the roles of MP, DP, and FSP for our forest/domain for several years now. A new customer in another department, is on a different subnet and we're for the first time needing to research extending SCCM to their subnet and forest/domain. I know that SCCM doesn't need to be on the same domain or forest, but we're having a devil of a time trying to figure out why this is failing

    • Firewalls: We use palo alto on both subnets for the building-level firewalls, we've opened up all port 80 and 443 between their subnet and server sccm1.site1.domain.edu in both directions. I've also opened up all traffic from the customer's subnet, to server sccm1 with Windows Firewall as an incoming rule.
    • Boundaries: I made a new boundary, and boundary group, for the IP address range of the new customer, and told it to use the same site server as my current clients.
    • PKI: we use HTTPS native mode and so as a test, I used these instructions to make a certificate for "client authentication" that is signed by our intermediate and root certificates. I put the client cert, uwsc-booth05.site2.domain.edu, into the computer's MY store, and put the intermediate and root certs for site1's PKI infrastructure into the booth05 machine's relevant stores.
    • CRL: I made sure that our CRL at cert.site1.domain.edu was accessible and could be downloaded from booth05 using internet explorer
    • Client installer: I just grabbed the entire \\sccm1\sms_dom\client folder from the server, and copied it to booth05. SMB is not yet open between our subnets.

    Here is the ccmsetup.log:

    9/6/2019 10:44:09 AM	CCMSETUP bootstrap from Internet: 0 
    9/6/2019 10:44:09 AM	Current AD forest name is site2.domain.edu, domain name is site2.domain.edu
    9/6/2019 10:44:09 AM	Domain joined client is in Intranet
    9/6/2019 10:44:09 AM	Current AD site of machine is US-TN-NASH
    9/6/2019 10:44:09 AM	DHCP entry points already initialized.
    9/6/2019 10:44:09 AM	Begin checking Alternate Network Configuration
    9/6/2019 10:44:09 AM	Finished checking Alternate Network Configuration
    9/6/2019 10:44:09 AM	Sending message body '<ContentLocationRequest SchemaVersion="1.00"  BGRVersion="1">
      <AssignedSite SiteCode="SSC"/>
      <ClientPackage RequestForLatest="0" DeploymentFlags="4098"/>
      <ClientLocationInfo LocationType="SMSPACKAGE" DistributeOnDemand="0" UseProtected="0" AllowCaching="0" BranchDPFlags="0" AllowHTTP="1" AllowSMB="0" AllowMulticast="0" UseAzure="1" DPTokenAuth="1" UseInternetDP="0">
        <ADSite Name="US-TN-NASH"/>
        <Forest Name="site2.domain.edu"/>
        <Domain Name="site2.domain.edu"/>
        <IPAddresses>
    <IPAddress SubnetAddress="192.168.1.0" Address="192.168.1.105"/>
        </IPAddresses>
      </ClientLocationInfo>
    </ContentLocationRequest>
    '
    9/6/2019 10:44:09 AM	Sending location request to 'sccm1.site1.domain.edu' with payload '<ContentLocationRequest SchemaVersion="1.00"  BGRVersion="1">
      <AssignedSite SiteCode="SSC"/>
      <ClientPackage RequestForLatest="0" DeploymentFlags="4098"/>
      <ClientLocationInfo LocationType="SMSPACKAGE" DistributeOnDemand="0" UseProtected="0" AllowCaching="0" BranchDPFlags="0" AllowHTTP="1" AllowSMB="0" AllowMulticast="0" UseAzure="1" DPTokenAuth="1" UseInternetDP="0">
        <ADSite Name="US-TN-NASH"/>
        <Forest Name="site2.domain.edu"/>
        <Domain Name="site2.domain.edu"/>
        <IPAddresses>
    <IPAddress SubnetAddress="192.168.1.0" Address="192.168.1.105"/>
        </IPAddresses>
      </ClientLocationInfo>
    </ContentLocationRequest>
    '
    9/6/2019 10:44:09 AM	IsSslClientAuthEnabled - Determining provisioning mode state failed with 80070002. Defaulting to state of 480.
    9/6/2019 10:44:09 AM	MapNLMCostDataToCCMCost() returning Cost 0x1
    9/6/2019 10:44:09 AM	Failed to connect to machine policy namespace. 0x8004100e
    9/6/2019 10:44:09 AM	Client is on internet
    9/6/2019 10:44:09 AM	Client is set to use webproxy if available.
    9/6/2019 10:44:09 AM	IsSslClientAuthEnabled - Determining provisioning mode state failed with 80070002. Defaulting to state of 480.
    9/6/2019 10:44:09 AM	Using the certificate [Thumbprint 06659D1130C600FE09556FA4D2C38AF184376611] issued to 'uwsc-booth05.site2.domain.edu'.
    9/6/2019 10:44:09 AM	ccmsetup: Host=sccm1.site1.domain.edu, Path=/ccm_system/request, Port=443, Protocol=https, CcmTokenAuth=0, Flags=0x4100, Options=0x1e0
    9/6/2019 10:44:09 AM	Created connection on port 443
    9/6/2019 10:44:09 AM	Enabled SSL revocation check.
    9/6/2019 10:44:09 AM	Trying without proxy.
    9/6/2019 10:44:24 AM	[CCMHTTP] AsyncCallback(): -----------------------------------------------------------------
    9/6/2019 10:44:24 AM	[CCMHTTP] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered
    9/6/2019 10:44:24 AM	[CCMHTTP]                : dwStatusInformationLength is 4
    
    9/6/2019 10:44:24 AM	[CCMHTTP]                : *lpvStatusInformation is 0x1
    
    9/6/2019 10:44:24 AM	[CCMHTTP]            : WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED is set
    
    9/6/2019 10:44:24 AM	[CCMHTTP] AsyncCallback(): -----------------------------------------------------------------
    9/6/2019 10:44:24 AM	Failed in WinHttpSendRequest API, ErrorCode = 0x2f8f
    9/6/2019 10:44:24 AM	[CCMHTTP] ERROR: URL=https://sccm1.site1.domain.edu/ccm_system/request, Port=443, Options=480, Code=12175, Text=ERROR_WINHTTP_SECURE_FAILURE
    9/6/2019 10:44:24 AM	[CCMHTTP] ERROR INFO: StatusCode=200 StatusText=
    9/6/2019 10:44:24 AM	Failed (0x80072f8f) to send location request to 'sccm1.site1.domain.edu'. StatusCode 200, StatusText ''
    9/6/2019 10:44:24 AM	Failed to send location message to 'https://sccm1.site1.domain.edu'. Status text ''
    9/6/2019 10:44:24 AM	GetDPLocations failed with error 0x80072f8f
    9/6/2019 10:44:24 AM	Failed to get DP locations as the expected version from MP 'https://sccm1.site1.domain.edu'. Error 0x80072f8f
    9/6/2019 10:44:24 AM	Failed to find DP locations from MP 'https://sccm1.site1.domain.edu' with error 0x80072f8f, status code 200. Check next MP.
    9/6/2019 10:44:24 AM	Only one MP https://sccm1.site1.domain.edu is specified. Use it.
    9/6/2019 10:44:24 AM	Have already tried all MPs. Couldn't find DP locations.
    9/6/2019 10:44:24 AM	Client is not installed yet. Ignore all upgrade exclusion flags.
    9/6/2019 10:44:24 AM	Downloading 'https://sccm1.site1.domain.edu/CCM_Client/ccmsetup.cab' to 'C:\Windows\ccmsetup\\ccmsetup.cab'
    9/6/2019 10:44:24 AM	IsSslClientAuthEnabled - Determining provisioning mode state failed with 80070002. Defaulting to state of 480.
    9/6/2019 10:44:24 AM	MapNLMCostDataToCCMCost() returning Cost 0x1
    9/6/2019 10:44:24 AM	Failed to connect to machine policy namespace. 0x8004100e
    9/6/2019 10:44:24 AM	Client is on internet
    9/6/2019 10:44:24 AM	Client is set to use webproxy if available.
    9/6/2019 10:44:24 AM	IsSslClientAuthEnabled - Determining provisioning mode state failed with 80070002. Defaulting to state of 480.
    9/6/2019 10:44:24 AM	Using the certificate [Thumbprint 06659D1130C600FE09556FA4D2C38AF184376611] issued to 'uwsc-booth05.site2.domain.edu'.
    9/6/2019 10:44:24 AM	ccmsetup: Host=sccm1.site1.domain.edu, Path=/CCM_Client/ccmsetup.cab, Port=443, Protocol=https, CcmTokenAuth=0, Flags=0x4100, Options=0x1e0
    9/6/2019 10:44:24 AM	Created connection on port 443
    9/6/2019 10:44:24 AM	Enabled SSL revocation check.
    9/6/2019 10:44:24 AM	Trying without proxy.
    9/6/2019 10:44:24 AM	[CCMHTTP] AsyncCallback(): -----------------------------------------------------------------
    9/6/2019 10:44:24 AM	[CCMHTTP] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered
    9/6/2019 10:44:24 AM	[CCMHTTP]                : dwStatusInformationLength is 4
    
    9/6/2019 10:44:24 AM	[CCMHTTP]                : *lpvStatusInformation is 0x1
    
    9/6/2019 10:44:24 AM	[CCMHTTP]            : WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED is set
    
    9/6/2019 10:44:24 AM	[CCMHTTP] AsyncCallback(): -----------------------------------------------------------------
    9/6/2019 10:44:24 AM	Failed in WinHttpSendRequest API, ErrorCode = 0x2f8f
    9/6/2019 10:44:24 AM	[CCMHTTP] ERROR: URL=https://sccm1.site1.domain.edu/CCM_Client/ccmsetup.cab, Port=443, Options=480, Code=12175, Text=ERROR_WINHTTP_SECURE_FAILURE
    9/6/2019 10:44:24 AM	[CCMHTTP] ERROR INFO: StatusCode=<unknown> StatusText=
    9/6/2019 10:44:24 AM	DownloadFileByWinHTTP failed with a non-recoverable failure, 0x80072f8f
    9/6/2019 10:44:24 AM	DownloadFileByWinHTTP failed with error 0x80072f8f
    9/6/2019 10:44:24 AM	Updating MDM_ConfigSetting.ClientDeploymentErrorCode with value 2147954575
    9/6/2019 10:44:24 AM	Failed to get client version for sending state messages. Error 0x8004100e
    9/6/2019 10:44:24 AM	[] Params to send '5.0.8790.1008 Deployment Error 0x80072f8f. Url https://sccm1.site1.domain.edu/CCM_Client/ccmsetup.cab'
    9/6/2019 10:44:24 AM	Sending Fallback Status Point message to 'sccm1.site1.domain.edu', STATEID='308'.
    9/6/2019 10:44:24 AM	<ClientDeploymentMessage ErrorCode="-2147012721"><Client Baseline="1" BaselineCookie="" Platform="2" Langs=""/></ClientDeploymentMessage>
    9/6/2019 10:44:24 AM	State message with TopicType 800 and TopicId {58BBEBB1-4EAE-4261-9FB5-7ADFC17C9465} has been sent to the FSP
    9/6/2019 10:44:24 AM	Deleting Comanagement reg keys...
    9/6/2019 10:44:24 AM	Deleting ConfigInfo and EnrollmentInfo...
    9/6/2019 10:44:24 AM	Could not open Wmi_Bridge_Server kegistry key.
    9/6/2019 10:44:24 AM	Failed to connect to policy namespace. Error 0x8004100e
    9/6/2019 10:44:24 AM	Failed to revoke client upgrade local policy. Error 0x8004100e
    9/6/2019 10:44:24 AM	Updating MDM_ConfigSetting.ClientDeploymentErrorCode with value 2147954575
    9/6/2019 10:44:24 AM	'Configuration Manager Client Retry Task' is scheduled to run at 09/06/2019 03:44:24 PM (local) 09/06/2019 08:44:24 PM (UTC) time with arguments '  "/UsePKICert" "/forceinstall" "/mp:https://sccm1.site1.domain.edu" "/skipprereq:silverlight.exe" "/source:\\galahad.site2.domain.edu\share1\dom-SCCM" FSP="sccm1.site1.domain.edu" SMSCACHESIZE="15000" SMSMP="sccm1.site1.domain.edu" SMSSITECODE="SCM" /RetryWinTask:1'.
    9/6/2019 10:44:24 AM	Folder 'Microsoft\Microsoft\Configuration Manager' not found. Task does not exist.
    9/6/2019 10:44:24 AM	Successfully created task 'Configuration Manager Client Retry Task'
    9/6/2019 10:44:24 AM	CcmSetup failed with error code 0x80072f8f

    I know those ASYNC errors are usually related to the CRL not being available, which definitely caught me the first time until I remembered I needed to unblock cert.site1.domain.edu on the workstation. But even after doing that, the ASYNC error didn't change.

    And I don't know how important those "Failed to connect to machine policy namespace. 0x8004100e" errors are, except they don't happen in ccmsetup on computers in our domain, only site2.

    The install is being run from an elevated command prompt in the context of a test account site2 gave us that is in the local administrators group, since our domains aren't connected at all.

    My thought is: something having to do with SCCM's IIS? I haven't made any changes to that yet.

    Also, on both a client in our domain in site1, and on booth05 in site2, http://sccm1.site1.domain.edu/SMS_MP/.sms_aut?mplist gives a 403 access denied error. So I'm not sure if it's supposed to do that, but at least it's doing the same thing on both domains?




    • Edited by MD5Hash Monday, September 9, 2019 9:02 PM initial install issue fixed
    Friday, September 6, 2019 7:17 PM

Answers

  • OK, so if ccmexec is running, that means the client agent is successfully installed and you need to move on to troubleshooting the client itself and not ccmsetup. /nocrlcheck is for ccmsetup and not the client. If you think the CRL is still the issue here, then you need to disable client CRL checking on the site itself.

    You can also review the client side logs including locationservices.log, clientlocation.log, clientidmanagerstartup.log, and ccmmessaging.log.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by MD5Hash Tuesday, September 17, 2019 8:04 PM
    Monday, September 9, 2019 8:00 PM
  • Okay, I got the initial install figured out via /NoCRLCheck (thanks for the suggestion again Jason) and then got the subsequent lack of action from the newly installed client, resolved by fixing PKI from our Sub CA, as it was saying it was issuing delta CRL's but actually wasn't.

    I'll have more questions for sure, but I think now that the client is now on shaky but functional ground, this case is resolved.

    • Marked as answer by MD5Hash Tuesday, September 17, 2019 8:05 PM
    Tuesday, September 17, 2019 8:04 PM

All replies

  • This is definitely a cert related issue but the client doesn't have all of the details why the certificate is not being accepted. You need to review the IIS log on the MP for a more detailed 403 error code to narrow down the exact reason.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, September 6, 2019 8:42 PM
  • Hello, Jason. Thank you for replying.

    When I filter the IIS log file on sccm1.site1.domain.edu for only the 192.168.1.105 IP address, there are very few 403's. Mostly 200's like this

    2019-09-06 20:44:29 10.0.0.254 POST /SMS_FSP/.sms_fsp - 80 - 192.168.1.105 SMS+FSP - 200 0 0 168 4

    I have some 403's but I think they're from when I tried to visit that mplist site from a browser on the booth05 client:

    2019-09-06 15:47:16 10.0.0.254 GET /sms_mp/.sms_aut mplist 443 - 192.168.1.105 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 403 7 0 1493 19


    • Edited by MD5Hash Friday, September 6, 2019 9:07 PM wrong line in IIS log
    Friday, September 6, 2019 8:59 PM
  • First, note that IIS logs are delayed and not real-time. Thus, you will always have to wait a short-period of time (I don't remember how long off hand, but nothing extremely excessive) to show the traffic from the client.

    Next, neither of the log lines you posted correspond to the traffic having issues as listed in ccmsetup.log. The first is for the FSP and the second is for an MPList lookup. The URLs that ccmsetup is trying to access when it had an issue are /ccm_system/request and /CCM_Client/ccmsetup.cab.

    If you don't see requests in IIS for these two URLs from the client's IP, then something else is blocking the traffic.

    How are you running ccmsetup? Manually? If so, then you can try adding the /nocrlcheck parameter to bypass the CRL check. If that succeeds, then you know that the CRL check is your issue.

    Also, note that just because you can access the CRL using IE doesn't necessarily mean that the local system account can. It's possible that there is something, like a proxy, that requires authentication and thus does pass your traffic but not the traffic from the local System account.

    Finally, the "Failed to connect to machine policy namespace. 0x8004100e" lines always occur on systems without the client agent installed because the policy namespace doesn't exist until the client agent creates it.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Friday, September 6, 2019 9:45 PM
  • How are you running ccmsetup? Manually? If so, then you can try adding the /nocrlcheck parameter to bypass the CRL check. If that succeeds, then you know that the CRL check is your issue.

    Also, note that just because you can access the CRL using IE doesn't necessarily mean that the local system account can. It's possible that there is something, like a proxy, that requires authentication and thus does pass your traffic but not the traffic from the local System account.

    Thanks Jason! That /NoCRLCheck did the trick to actually get the client installed (running it via a bat file while RDP'd into the test machine is how we're doing it right now, to answer your question) - while site2 is pretty locked down, they're using the Palo Alto firewall to just block all network traffic to the booth machines, then our firewall admin opened up 443 and 80 to this booth05 test system. I don't think any proxies are involved, but I'm only basing that on the windows network settings.

    Do you think those 2 ports are enough to do everything? I saw from here that 10123 is used for client to MP connections too, but also that it will fall back to 443, which is open. The local firewall log on booth05 shows all connections to sccm1 are being allowed, no drops (the admin at site2 already turned on showing both allow and drop in local workstation firewall logs, which is nice).

    I've made a note that figuring out why the CRL check is blocked is on the to-do list now too. Maybe I can convince the site2 admin to open up more than 443 and 80, but going off of that list of required ports, our firewall admin and myself thought that would be enough.

    As you might guess though, the fact that I needed the nocrlcheck just to get the client installed means that more problems immediately followed. The client is unable to find the site; when I check the applet in control panel and try to manually assign the SCM site code, it immediately fails with "did not find a site to manage this client"

    CCMMessaging.log now reports the following error every 5 minutes:

    [CCMHTTP] ERROR: URL=http://sccm1.site1.domain.edu/ccm_system/request, Port=80, Options=448, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE	CcmMessaging	9/9/2019 10:11:38 AM	9376 (0x24A0)
    [CCMHTTP] ERROR INFO: StatusCode=503 StatusText=Service Unavailable	CcmMessaging	9/9/2019 10:11:38 AM	9376 (0x24A0)
    Raising event:
    instance of CCM_CcmHttp_Status
    {
    	DateTime = "20190909151138.413000+000";
    	HostName = "sccm1.site1.domain.edu";
    	HRESULT = "0x87d0027e";
    	ProcessID = 956;
    	StatusCode = 503;
    	ThreadID = 9376;
    };
    	CcmMessaging	9/9/2019 10:11:38 AM	9376 (0x24A0)
    Status Agent hasn't been initialized yet. Attempting to create pending event.	CcmMessaging	9/9/2019 10:11:38 AM	9376 (0x24A0)
    Raising pending event:
    instance of CCM_CcmHttp_Status
    {
    	DateTime = "20190909151138.413000+000";
    	HostName = "sccm1.site1.domain.edu";
    	HRESULT = "0x87d0027e";
    	ProcessID = 956;
    	StatusCode = 503;
    	ThreadID = 9376;
    };
    	CcmMessaging	9/9/2019 10:11:38 AM	9376 (0x24A0)
    Successfully queued event on HTTP/HTTPS failure for server 'sccm1.site1.domain.edu'.	CcmMessaging	9/9/2019 10:11:38 AM	9376 (0x24A0)
    Post to http://sccm1.site1.domain.edu/ccm_system/request failed with 0x87d00231.	CcmMessaging	9/9/2019 10:11:38 AM	9376 (0x24A0)
    

    It's been several hours now (like you pointed out, IIS logs definitely don't seem to be real time) since I did the install. Setup seemed to go fine, but just now about 10 minutes ago, after allowing more types of 443/80 traffic through Palo Alto (darn packet aware filtering) we are now seeing 403 errors for ccmhttp, which still feels like IIS blocking to me, because IIS on sscm1 wouldn't have been set up to allow traffic outside our subnet when initially configured.

    2019-09-09 14:22:33 10.0.0.254 CCM_POST /ccm_system/request - 443 - 192.168.1.105 ccmsetup - 200 0 0 5861 69 2019-09-09 14:22:34 10.0.0.254 CCM_POST /ccm_system/request - 443 - 192.168.1.105 ccmsetup - 200 0 0 6101 410 2019-09-09 14:22:34 10.0.0.254 GET /SMS_MP/.sms_aut SMSTRC 443 - 192.168.1.105 SMS+CCM+5.0 - 200 0 0 2661 28 2019-09-09 14:22:34 10.0.0.254 PROPFIND /SMS_DP_SMSPKG$/SSC00001 - 443 - 192.168.1.105 ccmsetup - 207 0 0 18394 65 2019-09-09 14:22:34 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/ccmsetup.cab - 443 - 192.168.1.105 ccmsetup - 200 0 0 19157 39 2019-09-09 14:22:34 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/ccmsetup.cab - 443 - 192.168.1.105 ccmsetup - 200 0 0 19157 3 2019-09-09 14:22:35 10.0.0.254 PROPFIND /SMS_DP_SMSPKG$/SSC00001 - 443 - 192.168.1.105 ccmsetup - 200 0 0 18394 30 2019-09-09 14:22:35 10.0.0.254 PROPFIND /SMS_DP_SMSPKG$/SSC00001 - 443 - 192.168.1.105 ccmsetup - 200 0 0 18394 29 2019-09-09 14:22:35 10.0.0.254 PROPFIND /SMS_DP_SMSPKG$/SSC00001 - 443 - 192.168.1.105 ccmsetup - 200 0 0 18394 28 2019-09-09 14:22:35 10.0.0.254 PROPFIND /SMS_DP_SMSPKG$/SSC00001 - 443 - 192.168.1.105 ccmsetup - 200 0 0 18394 31 2019-09-09 14:22:35 10.0.0.254 HEAD /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 500 0 64 0 10 2019-09-09 14:22:35 10.0.0.254 HEAD /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 200 0 0 357 25 2019-09-09 14:22:35 10.0.0.254 HEAD /SMS_DP_SMSPKG$/SSC00001/x64/vcredist_x64.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 200 0 0 357 6 2019-09-09 14:22:35 10.0.0.254 HEAD /SMS_DP_SMSPKG$/SSC00001/x64/MicrosoftPolicyPlatformSetup.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 200 0 0 357 6 2019-09-09 14:22:35 10.0.0.254 HEAD /SMS_DP_SMSPKG$/SSC00001/x64/WindowsFirewallConfigurationProvider.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 200 0 0 357 6 2019-09-09 14:22:35 10.0.0.254 HEAD /SMS_DP_SMSPKG$/SSC00001/x64/client.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 200 0 0 357 36 2019-09-09 14:22:35 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 1449 8 2019-09-09 14:22:38 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 2544 4 2019-09-09 14:22:39 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 5101 1 2019-09-09 14:22:40 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 10754 2 2019-09-09 14:22:41 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 18878 2 2019-09-09 14:22:42 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 45109 4 2019-09-09 14:22:43 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 89923 4 2019-09-09 14:22:44 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 115189 18 2019-09-09 14:22:45 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 236450 8 2019-09-09 14:22:46 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 473913 47 2019-09-09 14:22:47 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 1451941 149 2019-09-09 14:22:48 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 1863106 154 2019-09-09 14:22:49 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/i386/vcredist_x86.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 2229088 186 2019-09-09 14:22:51 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/vcredist_x64.exe - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 200 0 0 7238032 641 2019-09-09 14:22:52 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/MicrosoftPolicyPlatformSetup.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 200 0 0 2577033 225 2019-09-09 14:22:53 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/WindowsFirewallConfigurationProvider.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 200 0 0 605873 52 2019-09-09 14:22:54 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/client.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 9791271 964 2019-09-09 14:22:54 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/client.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 5833271 528 2019-09-09 14:22:56 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/client.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 9389103 878 2019-09-09 14:22:57 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/client.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 9371850 903 2019-09-09 14:22:58 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/client.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 9025137 875 2019-09-09 14:22:58 10.0.0.254 GET /SMS_DP_SMSPKG$/SSC00001/x64/client.msi - 443 - 192.168.1.105 Microsoft+BITS/7.8 - 206 0 0 5101222 487
    2019-09-09 16:51:40 10.0.0.254 CCM_POST /ccm_system/request - 80 - 192.168.1.105 ccmhttp - 403 4 5 1393 194
    2019-09-09 16:56:37 10.0.0.254 CCM_POST /ccm_system/request - 80 - 192.168.1.105 ccmhttp - 403 4 5 1393 57
    2019-09-09 17:00:11 10.0.0.254 CCM_POST /ccm_system/request - 80 - 192.168.1.105 ccmhttp - 403 4 5 1393 56
    2019-09-09 17:01:38 10.0.0.254 CCM_POST /ccm_system/request - 80 - 192.168.1.105 ccmhttp - 403 4 5 1393 55

    Thank you for the reassurance on the policy namespace line. Wasn't sure how important that was but I'll cross that off "the list of errors" I'm keeping. I guess it's part of how the installer checks whether or not the client is already installed on a system, isn't it - makes sense.
    Monday, September 9, 2019 5:14 PM
  • > Do you think those 2 ports are enough to do everything?

    If you are using HTTPS client communication, then only 443 is ever needed (and 8531 for WSUS assuming you've left the default WSUS ports). It will fallback to 443 from 10123 for client notification as well.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, September 9, 2019 5:46 PM
  • Yes, we're definitely native mode, HTTPS only on the Site Server settings. It does seem like the IIS logs though, are using port 80 for /ccm_system/request. Which is allowed by our firewall rules anyway, just to be safe.

    I confirmed in IIS on sccm1 that ccm_system (and indeed all of the Default Site) authentication is set to 'anonymous authentication' being turned on, using IUSR, with no other forms of authentication set to enabled. I believe that's the SCCM default, but unfortunately, I didn't set up our SCCM site nor the sccm1 server.

    Monday, September 9, 2019 7:04 PM
  • There is nothing ever to configure or change in IIS; ConfigMgr takes care of what's needed automatically.

    What command-line exactly are you specifying for ccmsetup?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, September 9, 2019 7:11 PM
  • The one that worked successfully (to do the install, at least), as of this morning, was

    ccmsetup.exe /mp:https://sccm1.site1.domain.edu /UsePKICert /NoCRLCheck /forceinstall SMSSITECODE=SSC SMSCACHESIZE=15000 SMSMP=sccm1.site1.domain.edu FSP=https://sccm1.site1.domain.edu/skipprereq:silverlight.exe

    At this point, ccmexec.exe is running on booth05, but on the main screen of the applet i only showing client certificate=none (probably more CRL related issues), connection type "currently intranet" and the 1902 version of the Client software. None of the other entries are in place.

    I'm guessing that the /NoCRLCheck allowed me to bypass the problem earlier, but now that I'm past the installation aspect, something along the same lines is preventing the sccm client from actually doing its work.

    cert.site1.domain.edu which is our CDP, is whitelisted on Palo Alto, and as mentioned, I can download the CRL in the user session's browser on booth05, but I'm not sure how to test whether or not SCCM and local system can pull the CRL, beyond running netsh winhttp show proxy as an administrator (which I did, and it shows direct access).

    Monday, September 9, 2019 7:48 PM
  • OK, so if ccmexec is running, that means the client agent is successfully installed and you need to move on to troubleshooting the client itself and not ccmsetup. /nocrlcheck is for ccmsetup and not the client. If you think the CRL is still the issue here, then you need to disable client CRL checking on the site itself.

    You can also review the client side logs including locationservices.log, clientlocation.log, clientidmanagerstartup.log, and ccmmessaging.log.


    Jason | https://home.configmgrftw.com | @jasonsandys

    • Marked as answer by MD5Hash Tuesday, September 17, 2019 8:04 PM
    Monday, September 9, 2019 8:00 PM
  • Yes, sorry if I wasn't clear on that from my first posting today - thanks to /NoCRLCheck you suggested, the client installed, but fails to do anything except report its failure to connect to the sccm site server.

    I checked from powershell (administrator) certutil -URL cert.site1.domain.edu/cdp/domainCA.crl and it opened up the executable outside of powershell, downloaded and accessed the CRL without a problem.

    I've disabled the CRL check from the SCCM console and waited 15 minutes (the ccmmessaging.log updates every 5) but the same errors persist with CRL checking turned off. I don't know why it's being sent over port 80 when HTTPS only is selected. Maybe that's just for the initial communication.

    Here's LocationServices.log (repeats the same errors every 5 minutes), cmtrace red highlights in bold

    Won't send client assignment fallback status point message because last assignment message was sent too recently.	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Processing pending site assignment.	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Assigning to site 'SSC'	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    LSIsSiteCompatible : Verifying Site Compatibility for <SSC>	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Retrieved MP [sccm1.site1.domain.edu] from Registry	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Attempting to retrieve lookup MP(s) from AD	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    No lookup MP(s) from AD	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Attempting to retrieve lookup MP(s) from DNS	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Using default DNS suffix site2.domain.edu	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Attempting to retrieve default management points from DNS	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Failed to retrieve DNS service record using _mssms_mp_ssc._tcp.site2.domain.edu lookup. DNS returned error 9003	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    No lookup MP(s) from DNS	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Policy prevents failover to WINS for lookup	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Attempting to retrieve site information from lookup MP(s)	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    LSGetSiteVersionFromAD : Failed to retrieve version for the site 'SSC' (0x80004005)	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Retrieved MP [sccm1.site1.domain.edu] from Registry	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Attempting to retrieve lookup MP(s) from AD	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    No lookup MP(s) from AD	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Attempting to retrieve lookup MP(s) from DNS	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Using default DNS suffix site2.domain.edu	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Attempting to retrieve default management points from DNS	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Failed to retrieve DNS service record using _mssms_mp_ssc._tcp.site2.domain.edu lookup. DNS returned error 9003	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    No lookup MP(s) from DNS	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Policy prevents failover to WINS for lookup	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Attempting to retrieve site information from lookup MP(s)	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Failed to send site information Location Request Message to sccm1.site1.domain.edu	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    LSIsSiteCompatible : Failed to get Site Version from all directories	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Won't send a client assignment fallback status point message because the last assignment error matches this one.	LocationServices	9/9/2019 12:36:38 PM	9376 (0x24A0)
    Failed to execute task 'LSSiteRoleCycleTask'. Error 0x80004005	LocationServices	9/9/2019 12:36:38 PM	2500 (0x09C4)
    CSiteRoleCycleTask::Execute failed (0x80004005).	LocationServices	9/9/2019 12:36:38 PM	2500 (0x09C4)

    And ClientLocation.log (the last two lines just repeat every 5 minutes)

    Getting Assigned Site	ClientLocation	9/9/2019 12:00:07 PM	968 (0x03C8)
    Autodiscover Site	ClientLocation	9/9/2019 12:00:11 PM	968 (0x03C8)
    Client is set to use HTTPS when available. The current state is 448.	ClientLocation	9/9/2019 12:00:11 PM	968 (0x03C8)
    Current AD forest name is site2.domain.edu, domain name is site2.domain.edu	ClientLocation	9/9/2019 12:01:38 PM	9376 (0x24A0)
    Domain joined client is in Intranet	ClientLocation	9/9/2019 12:01:38 PM	9376 (0x24A0)

    The end of the ClientIDManagerStartup.log (last two lines have random second interval, then repeats constantly all day)

    >>> Client selected the PKI Certificate [Thumbprint 06659D1130C600FE09556FA4D2C38AF184376611] issued to 'uwsc-booth05.site2.domain.edu'	ClientIDManagerStartup	9/9/2019 9:26:24 AM	10440 (0x28C8)
    Raising pending event:
    instance of CCM_ServiceHost_CertRetrieval_Status
    {
    	DateTime = "20190909142624.148000+000";
    	HRESULT = "0x00000000";
    	ProcessID = 956;
    	ThreadID = 10440;
    };
    	ClientIDManagerStartup	9/9/2019 9:26:24 AM	10440 (0x28C8)
    Client PKI cert is available.	ClientIDManagerStartup	9/9/2019 9:26:24 AM	10440 (0x28C8)
    Registered AAD join event listener.	ClientIDManagerStartup	9/9/2019 9:26:36 AM	9376 (0x24A0)
    Registered for AAD on-boarding notifications.	ClientIDManagerStartup	9/9/2019 9:26:36 AM	9376 (0x24A0)
    Initializing registration renewal for potential PKI issued certificate changes.	ClientIDManagerStartup	9/9/2019 9:26:36 AM	9376 (0x24A0)
    Succesfully intialized registration renewal.	ClientIDManagerStartup	9/9/2019 9:26:36 AM	9376 (0x24A0)
    [RegTask] - Executing registration task synchronously.	ClientIDManagerStartup	9/9/2019 9:26:36 AM	9376 (0x24A0)
    Evaluated SMBIOS (encoded): 320056004B004700520050003200	ClientIDManagerStartup	9/9/2019 9:26:36 AM	9376 (0x24A0)
    SMBIOS unchanged	ClientIDManagerStartup	9/9/2019 9:26:36 AM	9376 (0x24A0)
    SID unchanged	ClientIDManagerStartup	9/9/2019 9:26:36 AM	9376 (0x24A0)
    HWID unchanged	ClientIDManagerStartup	9/9/2019 9:26:37 AM	9376 (0x24A0)
    RegTask: Failed to refresh site code. Error: 0x8000ffff	ClientIDManagerStartup	9/9/2019 9:26:42 AM	9376 (0x24A0)
    Sleeping for 293 seconds before refreshing location services.	ClientIDManagerStartup	9/9/2019 9:26:44 AM	9376 (0x24A0)

    CCMMessaging.log is what I've already provided in earlier posts, same errors every 5 minutes.

    As always, we SCCM noobs thank you for your advice. I'm trying to be as descriptive as possible here because I know it might help you, help me!

    Monday, September 9, 2019 8:58 PM
  • Update: based on Jason's post here about the SMSMP property, I made a small edit to my command line install - changing SMSMP=sccm1.site1.domain.edu to SMSMP=https://sccm1.site1.domain.edu.

    Then I uninstalled my first attempt at the SCCM client on booth05, and tried again.

    New entries in the client applet in the control panel! unlike last time, this time the site code box is properly filled. Also the management point lists itself on the main page of the applet, neither of which happened last time.

    However, now ccmmessaging.log gives the following new error every 5 minutes:

    9/10/2019 2:14:30 PM	[CCMHTTP] AsyncCallback(): -----------------------------------------------------------------
    9/10/2019 2:14:30 PM	[CCMHTTP] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered
    9/10/2019 2:14:30 PM	[CCMHTTP]                : dwStatusInformationLength is 4
    
    9/10/2019 2:14:30 PM	[CCMHTTP]                : *lpvStatusInformation is 0x1
    
    9/10/2019 2:14:30 PM	[CCMHTTP]            : WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED is set
    
    9/10/2019 2:14:30 PM	[CCMHTTP] AsyncCallback(): -----------------------------------------------------------------
    9/10/2019 2:14:30 PM	Raising event:
    instance of CCM_CcmHttp_Status
    {
    	DateTime = "20190910191430.208000+000";
    	HostName = "sccm1.site1.domain.edu";
    	HRESULT = "0x80072f8f";
    	ProcessID = 7448;
    	StatusCode = 1;
    	ThreadID = 1916;
    };
    
    9/10/2019 2:14:30 PM	Status Agent hasn't been initialized yet. Attempting to create pending event.
    9/10/2019 2:14:30 PM	Raising pending event:
    instance of CCM_CcmHttp_Status
    {
    	DateTime = "20190910191430.208000+000";
    	HostName = "sccm1.site1.domain.edu";
    	HRESULT = "0x80072f8f";
    	ProcessID = 7448;
    	StatusCode = 1;
    	ThreadID = 1916;
    };
    
    9/10/2019 2:14:30 PM	Failed in WinHttpSendRequest API, ErrorCode = 0x2f8f
    9/10/2019 2:14:30 PM	[CCMHTTP] ERROR: URL=https://sccm1.site1.domain.edu/ccm_system/request, Port=443, Options=63, Code=12175, Text=ERROR_WINHTTP_SECURE_FAILURE
    9/10/2019 2:14:30 PM	[CCMHTTP] ERROR INFO: StatusCode=<unknown> StatusText=
    9/10/2019 2:14:30 PM	Successfully queued event on HTTP/HTTPS failure for server 'sccm1.site1.domain.edu'.
    9/10/2019 2:14:30 PM	Post to https://sccm1.site1.domain.edu/ccm_system/request failed with 0x87d00231.
    9/10/2019 2:14:30 PM	[CCMHTTP] AsyncCallback(): -----------------------------------------------------------------
    9/10/2019 2:14:30 PM	[CCMHTTP] AsyncCallback(): WINHTTP_CALLBACK_STATUS_SECURE_FAILURE Encountered
    9/10/2019 2:14:30 PM	[CCMHTTP]                : dwStatusInformationLength is 4
    
    9/10/2019 2:14:30 PM	[CCMHTTP]                : *lpvStatusInformation is 0x1
    
    9/10/2019 2:14:30 PM	[CCMHTTP]            : WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED is set
    
    9/10/2019 2:14:30 PM	[CCMHTTP] AsyncCallback(): -----------------------------------------------------------------
    9/10/2019 2:14:30 PM	Raising event:
    instance of CCM_CcmHttp_Status
    {
    	DateTime = "20190910191430.286000+000";
    	HostName = "sccm1.site1.domain.edu";
    	HRESULT = "0x80072f8f";
    	ProcessID = 7448;
    	StatusCode = 1;
    	ThreadID = 1916;
    };
    
    9/10/2019 2:14:30 PM	Status Agent hasn't been initialized yet. Attempting to create pending event.
    9/10/2019 2:14:30 PM	Raising pending event:
    instance of CCM_CcmHttp_Status
    {
    	DateTime = "20190910191430.286000+000";
    	HostName = "sccm1.site1.domain.edu";
    	HRESULT = "0x80072f8f";
    	ProcessID = 7448;
    	StatusCode = 1;
    	ThreadID = 1916;
    };
    
    9/10/2019 2:14:30 PM	Failed in WinHttpSendRequest API, ErrorCode = 0x2f8f
    9/10/2019 2:14:30 PM	[CCMHTTP] ERROR: URL=https://sccm1.site1.domain.edu/ccm_system/request, Port=443, Options=63, Code=12175, Text=ERROR_WINHTTP_SECURE_FAILURE
    9/10/2019 2:14:30 PM	[CCMHTTP] ERROR INFO: StatusCode=<unknown> StatusText=
    9/10/2019 2:14:30 PM	Successfully queued event on HTTP/HTTPS failure for server 'sccm1.site1.domain.edu'.
    9/10/2019 2:14:30 PM	Post to https://sccm1.site1.domain.edu/ccm_system/request failed with 0x87d00231.

    Once again, WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED seems to be my enemy. So I disabled CRL checks in the SCCM console, thinking that would be a (temporary) way to confirm if that was the issue, but yet the same error comes back 5 minutes later, no change.

    IIS logs on sccm1 shows no connections at all from booth05 since doing this new client install, whereas yesterday on port 80, it was showing 403.4 errors every few minutes.

    Tuesday, September 10, 2019 7:33 PM
  • Okay, I got the initial install figured out via /NoCRLCheck (thanks for the suggestion again Jason) and then got the subsequent lack of action from the newly installed client, resolved by fixing PKI from our Sub CA, as it was saying it was issuing delta CRL's but actually wasn't.

    I'll have more questions for sure, but I think now that the client is now on shaky but functional ground, this case is resolved.

    • Marked as answer by MD5Hash Tuesday, September 17, 2019 8:05 PM
    Tuesday, September 17, 2019 8:04 PM
  • Glad to hear.

    On a side-note, not that you can really change it now or even have control to, but delta-CRLs in an internal PKI are rarely ever required or a good idea even.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, September 17, 2019 8:21 PM