locked
Does anyone use Config Manager 2012 R2 in a HTTPS Only configuration? RRS feed

  • Question

  • After Setting up a CCM site for HTTPS only:

    Site System Settings\Client Computer Configuration\HTTPS only
    Management Point Properties\General\Client Connections\HTTPS
    Distribution Point Properties\General\HTTPS

    We seem to keep finding issues, First was setting up Pull DPs, that can’t be done via the console but MS can provide a script that has to be used.

    Now we’ve found that 'Windows Installer Source Update Management' that updates the source location for repair of MSI based applications does not work.<o:p></o:p>

    SrcUpdateMgr.log is trying to use HTTP paths even though everything is configured only for HTTPS:

    The number of discovered DPs(including Branch DP and Multicast) is <Number>
    Calling back with the following distribution points
    Distribution Point='http://<server>/NOCERT_SMS_DP_SMSPKG$/Content_<ContentID>.1, Locality='LOCAL'
    Distribution Point='http://<server>/SMS_DP_SMSPKG$/Content_<Content ID>.1',Locality='LOCAL'
    <more DPs here>
    UpdateURLWithTransportSettings(): OLD URL -
    http://<server>/nocert_sms_dp_smspkg$/content_<ContentID>.1
    UpdateURLWithTransportSettings(): HTTP requested but client settings prohibit it.
    Failed source list update for product {<MSI Product ID>}, error 87d00226
    Failed to update sourcelist for product, source list update task will retryafter 3600 seconds to update this product Source list

    After raising a call to Microsoft the answer appears to be it doesn’t work, They are not going to fix it, Their only suggestion is to change the sites Client Computer Configuration to "HTTPS or HTTP" and some of the Distribution points to HTTP.

    So I can only assume no one uses HTTPS only?



    • Edited by Tony.Rayner Tuesday, June 17, 2014 11:52 AM removing HTML tags
    Tuesday, June 17, 2014 11:50 AM

All replies

  • HTTPS reporting in.

    Quoting from the SCCM's Client Computer Communication properties:

    Select the client computer communication method (HTTP or HTTPS) for the site systems that use IIS. To use HTTPS, the servers must have a valid PKI web server certificate (server authentication capability).
    Tuesday, June 17, 2014 12:00 PM
  • The IIS servers are correctly set up for HTTPS with Server Authentication/SSL certs. The clients all have Client Authentication certs. and are reporting in to the MPs. I can deploy applications to them, the DataTransferService.log shows that they are downloading using HTTPS from the DPs.

    The only thing that does not work is the Windows Installer Source Update Management.

    If I change the HTTP paths its trying to use to HTTPS and manually add that HTTPS path to the 'Source List' registry keys for Windows Installer a repair works fine until the Windows Installer Source Update Management next runs and removed the paths.

    We could turn off the 'Windows Installer Source Update Management' and write our own routine to do it, But we really should not have to do that to just because we want to use the built in 'HTTPS only' option.

    The fact the issue does not appear to be documented anywhere seems strange.

    Tuesday, June 17, 2014 1:29 PM
  • Do most folks use https only? No, why would they?

    As for your exact issue, that's truly a Windows issue and not directly related to ConfigMgr. It is also something very few folks ever worry about so yes, ultimately you are doing things few others are doing and are not on the frequently (if ever) tested scenarios path.


    Jason | http://blog.configmgrftw.com

    Tuesday, June 17, 2014 3:18 PM
  • For security, Microsoft say about using 'HTTPS only' (formally 'native mode') in 2012 for improved security.

    If you do the 'Windows Installer Source Update Management' / 'Windows installer source list update cycle' that's a built in feature of the Configuration Manager client does not work and tries to use HTTP paths.

    With packages Microsoft suggest the workaround of choosing to 'copy the contents of the package to the distribution share' and it will add the UNC of that to the 'source list', but that's not an option with Applications

    I don't know if it was an issue with 2007.

    Wednesday, June 18, 2014 9:14 PM
  • For security, Microsoft say about using 'HTTPS only' (formally 'native mode') in 2012 for improved security.

    Security of what? Does it use encrypted traffic for most client communication? Yes. Does that make ConfigMgr secure? No not really. Security is about managing risks. What risk are you managing by enabling it? I'm not saying you should or shouldn't use it, just don't operate under any false pre-tenses.

    As for the Source Update Management, it's Windows that is the consumer of the path, not ConfigMgr. ConfigMgr, to my knowledge is properly updating the source path in the Windows Installer DB. Because you are using HTTPS though, that path is also HTTPS and that's where Windows chokes when it tries to use that path.

    In 2007, everything was automatically available via a UNC so it probably was not an issue.

    Issues are issues though and pain is pain. There's no magic wand here unfortunately though and as mentioned, they're simply not the part of the common route for ConfigMgr deployment and so most folks either don't have the issue or just are ignorant of it.

    For Windows Installer based applications, how often are you seeing issues? I'm curious because starting with Windows 7 (maybe even Vista) the entire MSI (including any contained CAB files) is actually cached on the local machine so unless you have a lot of applications using external CABs, it shouldn't be an issue. I don't know your application base though so I was just curious on this one.


    Jason | http://blog.configmgrftw.com

    Wednesday, June 18, 2014 9:46 PM
  • Jason: Actually, it's a requirement in some countries to have management traffic (like ConfigMgr client-server is) to be encrypted. For example: http://www.defmin.fi/files/1871/KATAKRI_eng_version.pdf page 78.

    Sorry for the offtopic.

    Thursday, June 19, 2014 3:46 AM
  • Interesting, although I don't see anything in there that explicitly states the traffic should be encrypted. But, I'm not actually arguing that it should or shouldn't be done, just that not many (percentage wise compared to the entire install base) are actually using HTTPS exclusively and thus there are potentially still hidden issues (or even issue not considered a priority for fixing).

    Jason | http://blog.configmgrftw.com

    Thursday, June 19, 2014 3:58 PM
  • I concur with Jason. I have properly seen around a hundred different ConfigMgr environments in different companies and only two of those were running Native Mode (ConfigMgr 2007).

    One of the companies actually had no clue that they were running in native mode because it was setup by some consultant that forgot to tell them about it.

    They found out when the certificates began to expire and I was called in.

    Thursday, June 19, 2014 6:19 PM
  • Interesting, although I don't see anything in there that explicitly states the traffic should be encrypted. But, I'm not actually arguing that it should or shouldn't be done, just that not many (percentage wise compared to the entire install base) are actually using HTTPS exclusively and thus there are potentially still hidden issues (or even issue not considered a priority for fixing).

    Jason | http://blog.configmgrftw.com

    Again, sorry for the offtopic:

    I404.0:

    1) The management traffic of the
    networks and information systems
    (incl. servers, workstations, network
    devices and equivalent) is separated
    and/or encrypted.

    Friday, June 20, 2014 2:41 AM
  • Signing and encryption can also be done without PKI. Just bring up the properties of your site, "Signing and Encryütion" tab.

    Torsten Meringer | http://www.mssccmfaq.de

    Friday, June 20, 2014 7:25 AM
  • For security, Microsoft say about using 'HTTPS only' (formally 'native mode') in 2012 for improved security.

    If you do the 'Windows Installer Source Update Management' / 'Windows installer source list update cycle' that's a built in feature of the Configuration Manager client does not work and tries to use HTTP paths.

    With packages Microsoft suggest the workaround of choosing to 'copy the contents of the package to the distribution share' and it will add the UNC of that to the 'source list', but that's not an option with Applications

    I don't know if it was an issue with 2007.

    Did you get anywhere with this?  We are https only on our DPs and have the same problem with the installer source being set to http.  Would be a useful feature as some Adobe apps need the original MSI when you go to apply MSPs for example.
    Thursday, May 12, 2016 1:10 PM