Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Saturday, February 15, 2020 1:11 AM
I have configured a client auth cert issued by our CA on all of our PXE servers. I have enabled HTTPS on the MP and on the DP. I have even created a webserver cert and bound ssl on the PXE DP with the same CA generated cert. I have reinstalled the PXE on a DP, redistributed the boot image. still getting the same errors.
<code>
MACADDRESS, DD097655-B3BB-11E6-A2D4-3BB2E60260BB: Not serviced. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
============> Received from client: SMSPXE 2/14/2020 5:05:54 PM 6292 (0x1894)
Operation: BootRequest (1) Addr type: 1 Addr Len: 6 Hop Count: 0 ID: 10C2D1FF
Sec Since Boot: 0 Client IP: 266.266.266.266 Your IP: 000.000.000.000 Server IP: 000.000.000.000 Relay Agent IP: 000.000.000.000
Addr: c8:d3:ff:d1:c2:10:
Magic Cookie: 63538263
Options:
Type=53 Msg Type: 3=Request
Type=60 ClassId: PXEClient
Type=97 UUID: 00557609ddbbb3e611a2d43bb2e60260bb
Type=93 Client Arch: Intel x86PC
Type=250 0c01010d0208000e010001020006ff
Type=55 Param Request List: 03013c8081828384858687 SMSPXE 2/14/2020 5:05:54 PM 6292 (0x1894)
Using values from 'AllowedMPs' key. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Prioritizing local MP contosoSCDP01.contoso.com. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Not in SSL SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
RequestMPKeyInformation: Send() failed. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Unsuccessful in getting MP key information. 80004005. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
PXE::MP_InitializeTransport failed; 0x80004005 SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Not in SSL SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
RequestMPKeyInformation: Send() failed. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Unsuccessful in getting MP key information. 80004005. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
PXE::MP_InitializeTransport failed; 0x80004005 SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
PXE::MP_LookupDevice failed; 0x80070490 SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Using values from 'AllowedMPs' key. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Prioritizing local MP contosoSCDP01.contoso.com. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Not in SSL SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
RequestMPKeyInformation: Send() failed. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Unsuccessful in getting MP key information. 80004005. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
PXE::MP_InitializeTransport failed; 0x80004005 SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Not in SSL SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
RequestMPKeyInformation: Send() failed. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
Unsuccessful in getting MP key information. 80004005. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
PXE::MP_InitializeTransport failed; 0x80004005 SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
PXE::MP_ReportStatus failed; 0x80070490 SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
PXE Provider failed to process message.
Element not found. (Error: 80070490; Source: Windows) SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
C8:D3:FF:D1:C2:10, DD097655-B3BB-11E6-A2D4-3BB2E60260BB: Not serviced. SMSPXE 2/14/2020 5:05:54 PM 3692 (0x0E6C)
</code>
All replies (29)
Tuesday, February 18, 2020 2:04 AM ✅Answered | 1 vote
So it looks like someone hardcoded the DPs to use a specific MP which was not configured to handle the SSL traffic.
Note that co-management doesn't specifically require HTTPS though. All you need is Azure AD domain joined or hybrid domain joined systems which is a requirement for co-management anyway.
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, February 18, 2020 11:20 PM ✅Answered
So it looks like someone hardcoded the DPs to use a specific MP which was not configured to handle the SSL traffic.
Note that co-management doesn't specifically require HTTPS though. All you need is Azure AD domain joined or hybrid domain joined systems which is a requirement for co-management anyway.
Jason | https://home.configmgrftw.com | @jasonsandys
So, I removed the policy that was setting it, as I believe part of it was that it was also adding an empty line, thus confusing the system. I only have 1 MP for internal clients, so setting this is unnecessary. I also needed to add a web cert for each DP IIS server. Once I did of these I was able to get PXE to function properly.
As for the CMG/Co-Management, I will try to look for more current documentation, but everywhere I have seen so far indicates that I need an on-premise MP to allow the CMG traffic, in addition to changing the Default Client settings to be allowed to use Cloud services, and the only way I can check the box for allow MP to use CMG was to be on HTTPS.
Thanks again for your help on this matter.
Saturday, February 15, 2020 2:00 PM
Did you configure a PKI-issued, client auth cert on the properties of the PXE-enabled DP in the ConfigMgr console?
Have you issues unique client auth certs to all of your clients?
Jason | https://home.configmgrftw.com | @jasonsandys
Sunday, February 16, 2020 5:54 AM
Did you configure a PKI-issued, client auth cert on the properties of the PXE-enabled DP in the ConfigMgr console?
Have you issues unique client auth certs to all of your clients?
Jason | https://home.configmgrftw.com | @jasonsandys
Yes. I exported the client auth cert with key, imported in the properties of each DP properties. PKI auth is working on the clients. This is pxe clients that are “unknown” no OS on them.
Monday, February 17, 2020 3:37 AM
There's a basic issue here with the DP's communication to the MP. Did you bind an SSL cert to the IIS website on the system hosting the MP?
Did you add the root CA to the site's properties?
Is the CRL for the PKI available to all systems?
Do all systems trust the PKI?
Jason | https://home.configmgrftw.com | @jasonsandys
Monday, February 17, 2020 4:28 AM
Yes binding on ssl on iis is set with ca issued cert. I looked at the primary site settings and the root ca is specified and in there. It is trusted by all the sites. Where is the CRL spot you are referring to?
Monday, February 17, 2020 8:55 AM
Hi,
Thanks for posting in TechNet.
Please help check the settings about enabling Configuration manager in HTTPS. Here are some guides for your reference:
How can I configure System Center Configuration Manager in HTTPS mode (PKI) - Part 1
Deploy PKI Certificates For SCCM 2012 R2 Step By Step Guide
Deploying The Client Certificate For Distribution Points
Please note: The links are not from Microsoft, just for your reference. Thanks for your time.
Thanks for your time.
Best regards,
Simon
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Monday, February 17, 2020 4:07 PM
The CRL is specific to your PKI and is not not in ConfigMgr. You can examine the CRL's location (called a CRL Distribution Point or CDP) by examining the certificates as this is a hard-coded value.
Jason | https://home.configmgrftw.com | @jasonsandys
Monday, February 17, 2020 5:59 PM
The CRL is specific to your PKI and is not not in ConfigMgr. You can examine the CRL's location (called a CRL Distribution Point or CDP) by examining the certificates as this is a hard-coded value.
Jason | https://home.configmgrftw.com | @jasonsandys
Yes, all systems have access to the CRL, and they all trust the PKI. PKI is working everywhere except PXE. One thing I did notice is the "issue to" field is blank when I look at all the certificates that I created for each DP. Not sure if that plays into anything.
Monday, February 17, 2020 7:21 PM
So the subject name is blank on the client auth certs?
If so, that's not valid and needs to be corrected.
Jason | https://home.configmgrftw.com | @jasonsandys
Monday, February 17, 2020 7:53 PM
I read that you can use the same certificate for multiple DP's, so that shouldn't be an issue. Also I looked at all the template guides, and no where does it specificy that you need to enable the subject name...If I look at the cert itself it does show the servername in the subject alternate name field.
I did find this error just now on the MP mpcontrol.log:
>>> Selected Certificate [Thumbprint 2747a383f301cf58f6e30f9ac517cc2f7227334d] issued to 'fqdn.com' for HTTPS Client Authentication
Call to HttpSendRequestSync failed for port 443 with status code 500, text: Internal Server Error SMS_MP_CONTROL_MANAGER 2/17/2020 11:24:22 AM 13176 (0x3378)
Where should I be looking for that?
Monday, February 17, 2020 9:18 PM
I read that you can use the same certificate for multiple DP's, so that shouldn't be an issue. Also I looked at all the template guides, and no where does it specificy that you need to enable the subject name...If I look at the cert itself it does show the servername in the subject alternate name field.
I did find this error just now on the MP mpcontrol.log:
>>> Selected Certificate [Thumbprint 2747a383f301cf58f6e30f9ac517cc2f7227334d] issued to 'fqdn.com' for HTTPS Client Authentication Call to HttpSendRequestSync failed for port 443 with status code 500, text: Internal Server Error SMS_MP_CONTROL_MANAGER 2/17/2020 11:24:22 AM 13176 (0x3378)Where should I be looking for that?
I think that is a red herring, as 20 minutes later I see the same cert being validated and it comes back with 200 OK.
Begin validation of Certificate [Thumbprint 2747a383f301cf58f6e30f9ac517cc2f7227334d] issued to 'fqdn.com' SMS_MP_CONTROL_MANAGER 2/17/2020 11:58:21 AM 13176 (0x3378)
Certificate has "SSL Client Authentication" capability. SMS_MP_CONTROL_MANAGER 2/17/2020 11:58:21 AM 13176 (0x3378)
Completed validation of Certificate [Thumbprint 2747a383f301cf58f6e30f9ac517cc2f7227334d] issued to 'fqdn.com' SMS_MP_CONTROL_MANAGER 2/17/2020 11:58:21 AM 13176 (0x3378)
>>> Selected Certificate [Thumbprint 2747a383f301cf58f6e30f9ac517cc2f7227334d] issued to 'fqdn.com' for HTTPS Client Authentication SMS_MP_CONTROL_MANAGER 2/17/2020 11:58:21 AM 13176 (0x3378)
Call to HttpSendRequestSync succeeded for port 443 with status code 200, text: OK SMS_MP_CONTROL_MANAGER 2/17/2020 11:58:21 AM 13176 (0x3378)
Monday, February 17, 2020 10:58 PM
Yes, you can use the same cert technically although its best if you don't. Also, the subject name requirement is definitely in the PKI requirements documentation.
"There are no specific requirements for the certificate Subject or Subject Alternative Name (SAN). You can use the same certificate for multiple distribution points. However, it's a good idea to use a different certificate for each distribution point."
The first line may seem line it says you don't need one, but that's not what it says. It says you need one, it just doesn't matter what it is.
Jason | https://home.configmgrftw.com | @jasonsandys
Monday, February 17, 2020 10:58 PM
This is MP cert selection and has nothing to do with the cert configured in the DP role.
Jason | https://home.configmgrftw.com | @jasonsandys
Monday, February 17, 2020 11:32 PM
So the subject name is blank on the client auth certs?
If so, that's not valid and needs to be corrected.
Jason | https://home.configmgrftw.com | @jasonsandys
I created the certificate template as described the same was as this howto: https://www.windows-noob.com/forums/topic/16300-how-can-i-configure-system-center-configuration-manager-in-https-mode-pki-part-1 which is the same way I saw it in several different articles. When I did that, I got the certificate in the local server's certificate console, and exported it. When I imported it into Config Manager it asked for the password, and imported it. When I look at the certificate tab in config manager, that's where I am seeing blanks on "issued to" and there are a few of them that are blank.
When I look at the DP's smspxe.log I see the following:
Begin validation of Certificate [Thumbprint 96D37A81B293179D9F52CBDD9D3D4E84F2AA7919] issued to 'DP.FQDN.com' SMSPXE 2/17/2020 3:18:04 PM 7500 (0x1D4C)
Completed validation of Certificate [Thumbprint 96D37A81B293179D9F52CBDD9D3D4E84F2AA7919] issued to 'DP.FQDN.com' SMSPXE 2/17/2020 3:18:04 PM 7500 (0x1D4C)
Wouldn't it error there if the cert wasn't correct? I feel like the issue isn't with the certificate on the DP, as it is using the Client Authentication template, exported propery, and imported into ConfigMgr.
Why does it say "Not in SSL" Should that say In SSL?What other logs can I look at that can help troubleshoot this issue?Thanks for all your feed back thus far.
Tuesday, February 18, 2020 12:25 AM
Sorry not following. The log snippet you posted above clearly shows an issued to value. So which is it?
Also, where are you pulling "Not in SSL" from?
The smspxe.log above clearly shows the issue that PXE is not servicing the request. There are no more logs at this point.
Looking at that log again though, it has this line: "Using values from 'AllowedMPs' key." Is there a reason you are setting this value in registry?
Is the DP named "contosoSCDP01.contoso.com" correctly configured for SSL and does it have a client auth cert assigned to it in the console?
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, February 18, 2020 12:45 AM
I did not initially set this site up, I am trying to modify it and enable co-management hence the force to https. When I look at the registry, it does have AllowedMPs in it...I can delete this. I got the not in SSL from the start of the log on the DP smspxe.log.
I can't post pictures for whatever reason in technet still. Maybe I can post links:
https://i.imgur.com/LIihMFP.png
https://i.imgur.com/or4X64z.png
https://i.imgur.com/sF2wRAd.png
https://i.imgur.com/qWSeHgj.png
PKI itself is working for the client. All my clients once they are on the domain get a cert issued by the CA through GPO.
Tuesday, February 18, 2020 12:57 AM
Sorry not following. The log snippet you posted above clearly shows an issued to value. So which is it?
Also, where are you pulling "Not in SSL" from?
The smspxe.log above clearly shows the issue that PXE is not servicing the request. There are no more logs at this point.
Looking at that log again though, it has this line: "Using values from 'AllowedMPs' key." Is there a reason you are setting this value in registry?
Is the DP named "contosoSCDP01.contoso.com" correctly configured for SSL and does it have a client auth cert assigned to it in the console?
Jason | https://home.configmgrftw.com | @jasonsandys
Crossing my fingers...after removing that registry entry, which had the MP and the DP itself listed (which is not an MP or a backup), I restarted WDS and restarted a PXE boot, and it appears to be working. I just need to repeat this with about 15 other DP's to verify.
Tuesday, February 18, 2020 5:45 PM
So it looks like someone hardcoded the DPs to use a specific MP which was not configured to handle the SSL traffic.
Note that co-management doesn't specifically require HTTPS though. All you need is Azure AD domain joined or hybrid domain joined systems which is a requirement for co-management anyway.
Jason | https://home.configmgrftw.com | @jasonsandys
Ok so, it's not being hard coded manually, something is setting it. When I remove this key, restart WDS, the MP works, and this works on a couple different DPs, but then it gets reset at some point. I will have to search the logs to see if I can see what is setting the MP in the registry.
Also - while co-management may not require https, it needs CMG, which does require https, and I plan on replacing my DMZ IBCM with CMG at some point, which is why I needed to get https working in the first place. :)
Tuesday, February 18, 2020 6:08 PM
> it needs CMG, which does require https,
No. This is not correct. The same requirement exists for CMG (because the co-management requirement is really the CMG requirement) which is either HTTPS *or* Azure AD domain join (or hybrid Azure AD domain join).
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, February 18, 2020 6:12 PM
> it needs CMG, which does require https,
No. This is not correct. The same requirement exists for CMG (because the co-management requirement is really the CMG requirement) which is either HTTPS *or* Azure AD domain join (or hybrid Azure AD domain join).
Jason | https://home.configmgrftw.com | @jasonsandys
From all the tutorials I have read, you need to enable the management points to "allow configuration manage cloud management gateway traffic" option to be checked, which is only available if you are using HTTPS...
If I don't need to enable https for CMG and Co-Management to work, then I don't see any point in continuing this and I will turn everything back to http.
Tuesday, February 18, 2020 6:35 PM
So it looks like someone hardcoded the DPs to use a specific MP which was not configured to handle the SSL traffic.
Note that co-management doesn't specifically require HTTPS though. All you need is Azure AD domain joined or hybrid domain joined systems which is a requirement for co-management anyway.
Jason | https://home.configmgrftw.com | @jasonsandys
I only have 1 management point for intranet, and it is set to handle the ssl traffic. What I am finding is that if I delete the key, and restart WDS on the DP, it allows the system to boot to PXE< but then it gets reset in the registry and it seems like it is setting 2 lines and the second line is blank. I dont' have any configuration items setting this. It must be coming from the configuration.
Tuesday, February 18, 2020 7:26 PM
> From all the tutorials I have read, you need to enable the management points to "allow configuration manage cloud management gateway traffic" option to be checked, which is only available if you are using HTTPS...
Your reading old or misguided material then. There are two options:
1. Created an HTTPS-only MP just for CMG traffic
2. Enable Enhanced HTTP: https://docs.microsoft.com/en-us/configmgr/core/plan-design/hierarchy/enhanced-http
> If I don't need to enable https for CMG and Co-Management to work, then I don't see any point in continuing this and I will turn everything back to http.
Correct, assuming that you will be enabling Azure AD Domain Join or Hybrid Azure AD Domain join for the managed systems.
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, February 18, 2020 7:29 PM
> It must be coming from the configuration.
Not in ConfigMgr. This was created as a stop gap for the lack of dynamic MP affinity and also served to choose the MP for PXE booting when this needed to be done. It is a registry value that must be set outside of ConfigMgr though.
Perhaps a group policy/group policy preference?
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, February 18, 2020 8:33 PM
> It must be coming from the configuration.
Not in ConfigMgr. This was created as a stop gap for the lack of dynamic MP affinity and also served to choose the MP for PXE booting when this needed to be done. It is a registry value that must be set outside of ConfigMgr though.
Perhaps a group policy/group policy preference?
Jason | https://home.configmgrftw.com | @jasonsandys
Yup, found it in GP. Deleting this object and going to try again.
Wednesday, February 19, 2020 2:31 AM
Hi, Thanks very much for your sharing and feedback. It may help others who have similar issue. Here's a short summary for the problem. Problem/Symptom:
Enabling HTTPS on MP and DP breaks PXE.
Solution:
1.Removing the group policy object that specify a specific MP which was not configured to handle the SSL traffic.
- It's not enough to import the ConfigMgr Client Distribution Point Certificate onto the "Communication" tab of the DP properties, we also need to assign that certificate as a web server certificate in the IIS console of the particular DP.
It's appreciated if you could mark your reply as answer, that will help other users to search for useful information more quickly. Thank you!
Best regards,
Simon
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, February 19, 2020 3:17 AM
If you aren't looking at the official documentation first, the you are doing it wrong. The link I posted above tells you about Enhanced HTTP as noted.
Perhaps you are on an older version of ConfigMgr as well in which case you definitely need to upgrade ASAP as Enhanced HTTP was introduced in 1810 or 1902.
Jason | https://home.configmgrftw.com | @jasonsandys
Wednesday, February 19, 2020 8:09 PM
If you aren't looking at the official documentation first, the you are doing it wrong. The link I posted above tells you about Enhanced HTTP as noted.
Perhaps you are on an older version of ConfigMgr as well in which case you definitely need to upgrade ASAP as Enhanced HTTP was introduced in 1810 or 1902.
Jason | https://home.configmgrftw.com | @jasonsandys
well, that's probably the route I will want to as I spoke too soon. PXE booting is working however now normal communication isn't working. Getting error 403 forbidden errors on the MP trying to even just install the client...I know its certificate issue, because once I switch back to http, it works...seems like it may be less headache (and renewing of certs later) to look at the enhanced http route. I am already on 1902 and plan on moving to 1910 very soon anyway.
[CCMHTTP] ERROR: URL=http://sccm01.contoso.com/ccm_system/request, Port=80, Options=448, Code=0, Text=CCM_E_BAD_HTTP_STATUS_CODE ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
[CCMHTTP] ERROR INFO: StatusCode=403 StatusText=Forbidden ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
Failed (0x87d0027e) to send location request to 'fqdnsccm01.contoso.com'. StatusCode 403, StatusText 'Forbidden' ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
Failed to send location message to 'fqdnsccm01.contoso.com'. Status text 'Forbidden' ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
GetDPLocations failed with error 0x87d0027e ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
Failed to get DP locations as the expected version from MP 'fqdnsccm01.contoso.com'. Error 0x87d0027e ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
Updating MDM_ConfigSetting.ClientDeploymentErrorCode with value 0 ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
Failed to get client version for sending state messages. Error 0x8004100e ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
[] Params to send '5.0.8790.1008 Deployment Error: 0x0, ' ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
Sending Fallback Status Point message to 'FALLBACKSCDP01.contoso.com', STATEID='101'. ccmsetup 2/19/2020 2:05:36 PM 6336 (0x18C0)
Wednesday, February 19, 2020 8:21 PM
HTTP 403 has a lot of sub-codes that will give better insight to the issue; however, these are only visible by examining the IIS log on the MP and finding the corresponding traffic (by time and client IP).
Jason | https://home.configmgrftw.com | @jasonsandys