Hy all,

i have a problem with certificate profiles deployment via SCCM 2012 R2.

My Testlab:
Server 2012 R2 - DC
Server 2012 R2 - CA
Server 2012 R2 - SCCM 2012 R2, Intune Subscription ...
Server 2012 R2 - NDES, SCCM Site System with Certificate Registration Point, Policy Module

NDES Service Account (SPN for NDES Server)

CA:
Administrative Rights for NDES Service Account

CEP Encryption (Read&Enroll for NDES Service)
Exchange Enrollment Agent (Offline request) (Read&Enroll for NDES Service Account)
Webserver Certificate for NDES, SCCM Server (Dublicatet Webserver Template)
Client Authentication Certificate for NDES, SCCM Server (Dublicatet Template for Client Authentication)
"Custom IPSec V2" Template, (Dublicatet Template of IPSec (offline request), Read&Enroll for NDES Service Account)

Policy Module on NDES Server
In the Wizard i selected the Client Authentication Certificate

NDES Server
Installed "Network Device Enrollment Service" Role Service
SCCM Site System, SCEP Role

Location: HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters
Value: MaxFieldLength
Type DWORD
Data: 65534 (decimal)

Location: HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters  
Value: MaxRequestBytes
Type DWORD
Data: 65534 (decimal)

SSL settings to Require SSL , Ignore client certificates.

NDES Service Account member of IIS_IUSRS

IIS - Webserver Certificate for :443 Binding

HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP
EncryptionTemplate, GeneralPurposeTemplate, SignatureTemplate
i set it to "CustomIPSecV2"

SCCM:
Installed Certificate Registration Point on NDES Server
Certificate Registration Point Properties - URL for the Network Device Enrollment Service ...
I set it to: https://externalfqdn/certsrv/mscep/mscep.dll
Certificate Root CA Profile
Certificate Profile for "CustomIPSecV2" Certificate

Now i have following error for the deployment of the "CustomIPSecV2" Certificate: 0X87D1FDE8 Remediation failed

I can not find any error in the logs (SCCM, crp.log, NDESPlugin.log, crpctrl.log)
In the IIS log there are following entries:

2014-08-02 18:57:41 fe80::10b7:f62:ec3c:605d%12 POST /CMCertificateRegistration/certificate/generatechallenge - 443 - fe80::10b7:f62:ec3c:605d%12 SMS_CERTIFICATE_REGISTRATION_POINT - 201 0 0 3502
2014-08-02 14:07:40 172.16.0.8 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 144.11.115.119 - - 200 0 0 68

What can i do?

Thanks in Advance ..

Hi Christoph, I'm in the same situation. Did you find a solution?

Kind regards

Denis

Hello,

i have the same problem, pushing the certificate to Windows 8.1 Devices works, but to iOS won't work. Same Error 0X87D1FDE8 Remediation failed. Any news on this one?

I am also in exactly same state? Did you find any resolution?

Hi,

have you checked that the Certificate Profile properties are set according to iOS requirements?

Quote from http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2014/04/25/part-2-scep-certificate-enrolling-using-configmgr-2012-crp-ndes-and-windows-intune.aspx:

At this point, be-aware that:

• iOS doesnt support fully distinguished name as the subject name format or including e-mail address in subject name.
• You configure the settings according to what you have specified in the template (e.g. SHA-1/SHA-2/SHA-3 and the key-length).
• If the template name contains non-ASCII characters the cert will not be deployed

This is extremely important! If it works for WP8 but not for iOS then most likely you simply have to uncheck the box "Include email..." and it will start working!

By the way: iOS8 is not yet supported. For the time being, it will only work with iOS7 and lower

Cheers,

Alex

Hey,

any news on this? We have the same error with windows phone 8.1.

best regards

Philipp

• Edited by Philipp_R Wednesday, October 01, 2014 7:42 AM

Hey,

any news on this? We have the same error with windows phone 8.1.

best regards

Philipp

• Edited by Philipp_R Wednesday, October 01, 2014 7:42 AM

Hi, I have the exact same (almost) lab environment. I have been showing my head against the wall for a couple of days. But I've found out that if I set the settings like this. The service is generating user certs for iOS8 and Android 4.4 and of course my Windows devices. 

Philipp,

did you get this solved with Windows Phone 8.1 devices?

I still get 0X87D1FDE8 Remediation failed, also with the settings from Bjrn Bjrkman

Thanks

regards,

ckuever

Hey,

we reinstalled the NDES und SCEP Sub PKI Servers and now it is working. No idea what the error was. The most useful logs are on the NDES Server (C:\windows\mscep.log or C:\NDESUser\mscep.log --> you have to enable logging first http://social.technet.microsoft.com/Forums/windowsserver/en-US/1771361a-d498-4840-9b1e-aed4bb5b8ead/trouble-enabling-ndes-logging) and C:\Program Files\Config Manager\ndesplugin.log

best regards

Philipp

Hi Philipp,

thanks, i will do a reinstall as well if we can't fix it.

Can you provide a screenshot of your working certificate properties (like Bjrn Bjrkman did)

Thanks.

best regards,

ckuever

Hey..

yes but i think the certificate propetries must exactly match with the templates properties.
You should use the Browse option to select it. Also do not forget to deploy the "root" certificate of the SCEP intermediate CA

best regards

Philipp

Hello!

I still have the same problem - Remediation failed - 0X87D1FDE8

Is this only a problem of the certificate template?

I also reinstalled NDES Server and CRP Role on Primary Site

Has anyone an idea?

CRPSetup, crpctrl, CRPMSI all ok.

IISLog:

#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2014-10-13 13:09:35
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2014-10-13 13:09:35 172.16.0.6 GET /certsrv/mscep/mscep.dll - 80 - 172.16.0.5 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+.NET4.0E;+.NET4.0C) - 200 0 0 1179
2014-10-13 13:09:37 172.16.0.6 GET /favicon.ico - 80 - 172.16.0.5 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+.NET4.0E;+.NET4.0C) - 404 0 2 1384
2014-10-13 13:14:01 172.16.0.6 GET / - 80 - 172.16.0.4 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 1
2014-10-13 13:14:01 172.16.0.6 GET /iis-85.png - 80 - 172.16.0.4 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko http://server.external.fqdn 200 0 0 6
2014-10-13 13:14:03 172.16.0.6 GET /favicon.ico - 80 - 172.16.0.4 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 404 0 2 1
#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2014-10-13 13:15:24
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2014-10-13 13:15:24 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 172.16.0.4 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 2
2014-10-13 13:15:24 172.16.0.6 GET /favicon.ico - 443 - 172.16.0.4 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 404 0 2 4
2014-10-13 13:15:40 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 47
2014-10-13 13:15:40 172.16.0.6 GET /favicon.ico - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 404 0 2 47
2014-10-13 13:20:08 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 49
2014-10-13 13:20:08 172.16.0.6 GET /favicon.ico - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 404 0 2 47
2014-10-13 13:25:32 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 48
2014-10-13 13:25:32 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 50
2014-10-13 13:25:33 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 49
2014-10-13 13:35:17 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 49
#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2014-10-13 13:43:25
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2014-10-13 13:43:25 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 150
2014-10-13 13:43:32 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 104.45.8.80 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 6
2014-10-13 13:43:42 172.16.0.6 GET /certsrv/mscep/mscep.dll - 443 - 172.16.0.4 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 1
2014-10-13 13:47:25 172.16.0.6 GET /certsrv/mscep operation=GetCACert&message=MyDeviceID 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 301 0 0 47
2014-10-13 13:47:25 172.16.0.6 GET /certsrv/mscep/ operation=GetCACert&message=MyDeviceID 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 50
#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2014-10-13 13:52:22
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2014-10-13 13:52:22 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 233
2014-10-13 13:52:22 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 46
2014-10-13 13:57:00 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 56
2014-10-13 13:57:00 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 41
2014-10-13 14:03:26 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 62
2014-10-13 14:03:26 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 46
#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2014-10-13 14:19:25
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2014-10-13 14:19:25 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 1278
2014-10-13 14:19:25 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 52
2014-10-13 14:19:31 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 104
2014-10-13 14:19:31 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 74
2014-10-13 14:21:07 172.16.0.6 GET /certsrv/mscep/ operation=GetCACert&message=MyDeviceID 443 - 193.83.183.27 Mozilla/5.0+(Windows+NT+6.3;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - 200 0 0 62
#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2014-10-13 14:26:01
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2014-10-13 14:26:01 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 294
2014-10-13 14:26:01 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 46
2014-10-13 14:26:07 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 56
2014-10-13 14:26:07 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 52
#Software: Microsoft Internet Information Services 8.5
#Version: 1.0
#Date: 2014-10-13 14:46:41
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2014-10-13 14:46:41 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 601
2014-10-13 14:46:41 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 47
2014-10-13 14:46:51 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 99
2014-10-13 14:46:51 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 78
2014-10-13 14:50:40 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 46
2014-10-13 14:50:40 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 66
2014-10-13 14:51:53 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=MDM 443 - 193.83.183.27 - - 200 0 0 46
2014-10-13 14:51:53 172.16.0.6 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACaps&message=MDM 443 - 193.83.183.27 - - 200 0 0 62

Hey Christoph,

i just read your first post. Are you sure NDES and CRP can be installed on the same Server? I installed the CRP Role on our Config Mgr Server and just the Plugin on the NDES Server. Here the guide we used.. http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2014/04/25/part-2-scep-certificate-enrolling-using-configmgr-2012-crp-ndes-and-windows-intune.aspx

What about your MSCEP.log? https://social.technet.microsoft.com/Forums/windowsserver/en-US/1771361a-d498-4840-9b1e-aed4bb5b8ead/trouble-enabling-ndes-logging

regards

Philipp

Hy Phillip, thx for reply!

same issue when the CRP is installed on Primary Site Server.

MSCEP.log - strange issue but i have no mscep.log. IIS is configured on NDED, SPN, Profile loaded...

best regards

So, now i have a mscep.log but i have no idea was the error means.

402.534.948: Begin: 10/13/2014 5:59 PM 58.467s
402.539.0: w3wp.exe
402.543.0: GMT + 2.00
2906.611.0:<2014/10/13, 17:59:58>: 0x0 (WIN32: 0): Calling INDESPolicy::Initialize
2901.1042.0:<2014/10/13, 17:59:58>: 0x80004005 (-2147467259 E_FAIL)
2905.902.0:<2014/10/13, 17:59:58>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): ACF5137B 14E2E90B C828BB8D 7414D94E 63138959
2905.902.0:<2014/10/13, 17:59:58>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 72540F2E 5E9981B5 07E21ADB E5445668 FBF69C03
2905.902.0:<2014/10/13, 17:59:58>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 0E9E00BE 35BBF08C 5975A14E EAB7E224 DA13C163
2906.674.0:<2014/10/13, 19:06:25>: 0x0 (WIN32: 0): Calling INDESPolicy::Uninitialize
402.379.949: End: 10/13/2014 7:06 PM 25.984s
========================================================================
402.534.948: Begin: 10/13/2014 7:13 PM 14.149s
402.539.0: w3wp.exe
402.543.0: GMT + 2.00
2906.611.0:<2014/10/13, 19:13:14>: 0x0 (WIN32: 0): Calling INDESPolicy::Initialize
2901.1042.0:<2014/10/13, 19:13:14>: 0x80004005 (-2147467259 E_FAIL)
2905.902.0:<2014/10/13, 19:13:14>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): ACF5137B 14E2E90B C828BB8D 7414D94E 63138959
2905.902.0:<2014/10/13, 19:13:14>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 72540F2E 5E9981B5 07E21ADB E5445668 FBF69C03
2905.902.0:<2014/10/13, 19:13:14>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 0E9E00BE 35BBF08C 5975A14E EAB7E224 DA13C163
2906.1502.0:<2014/10/13, 19:27:9>: 0x8000ffff (-2147418113 E_UNEXPECTED)
2906.1948.0:<2014/10/13, 19:27:9>: 0x8000ffff (-2147418113 E_UNEXPECTED): 403 Forbidden (0x8000ffff)
2906.1502.0:<2014/10/13, 19:27:21>: 0x8000ffff (-2147418113 E_UNEXPECTED)
2906.1948.0:<2014/10/13, 19:27:21>: 0x8000ffff (-2147418113 E_UNEXPECTED): 403 Forbidden (0x8000ffff)
2906.1502.0:<2014/10/13, 21:34:42>: 0x8000ffff (-2147418113 E_UNEXPECTED)
2906.1948.0:<2014/10/13, 21:34:42>: 0x8000ffff (-2147418113 E_UNEXPECTED): 403 Forbidden (0x8000ffff)
2906.1502.0:<2014/10/13, 21:34:46>: 0x8000ffff (-2147418113 E_UNEXPECTED)
2906.1948.0:<2014/10/13, 21:34:46>: 0x8000ffff (-2147418113 E_UNEXPECTED): 403 Forbidden (0x8000ffff)
2906.1502.0:<2014/10/13, 21:40:4>: 0x8000ffff (-2147418113 E_UNEXPECTED)
2906.1948.0:<2014/10/13, 21:40:4>: 0x8000ffff (-2147418113 E_UNEXPECTED): 403 Forbidden (0x8000ffff)
2906.1502.0:<2014/10/13, 21:44:11>: 0x8000ffff (-2147418113 E_UNEXPECTED)
2906.1948.0:<2014/10/13, 21:44:11>: 0x8000ffff (-2147418113 E_UNEXPECTED): 403 Forbidden (0x8000ffff)
2906.674.0:<2014/10/14, 10:21:33>: 0x0 (WIN32: 0): Calling INDESPolicy::Uninitialize
402.379.949: End: 10/14/2014 10:21 AM 33.391s
========================================================================
402.534.948: Begin: 10/14/2014 10:36 AM 17.048s
402.539.0: w3wp.exe
402.543.0: GMT + 2.00
2901.1042.0:<2014/10/14, 10:36:17>: 0x80004005 (-2147467259 E_FAIL)
2905.902.0:<2014/10/14, 10:36:17>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): ACF5137B 14E2E90B C828BB8D 7414D94E 63138959
2905.902.0:<2014/10/14, 10:36:17>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 72540F2E 5E9981B5 07E21ADB E5445668 FBF69C03
2905.902.0:<2014/10/14, 10:36:17>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 0E9E00BE 35BBF08C 5975A14E EAB7E224 DA13C163
2906.2268.0:<2014/10/14, 10:36:17>: 0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER)
2906.1556.0:<2014/10/14, 10:36:17>: 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)
2906.192.0:<2014/10/14, 10:36:17>: 0x80073afc (WIN32: 15100 ERROR_MUI_FILE_NOT_FOUND)
2906.328.0:<2014/10/14, 10:36:17>: 0x80073afc (WIN32: 15100 ERROR_MUI_FILE_NOT_FOUND)
402.379.949: End: 10/14/2014 11:10 AM 42.546s
========================================================================
402.534.948: Begin: 10/14/2014 11:13 AM 39.951s
402.539.0: w3wp.exe
402.543.0: GMT + 2.00
2906.611.0:<2014/10/14, 11:13:39>: 0x0 (WIN32: 0): Calling INDESPolicy::Initialize
2901.1042.0:<2014/10/14, 11:13:39>: 0x80004005 (-2147467259 E_FAIL)
2905.902.0:<2014/10/14, 11:13:39>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): ACF5137B 14E2E90B C828BB8D 7414D94E 63138959
2905.902.0:<2014/10/14, 11:13:40>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 72540F2E 5E9981B5 07E21ADB E5445668 FBF69C03
2905.902.0:<2014/10/14, 11:13:40>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 0E9E00BE 35BBF08C 5975A14E EAB7E224 DA13C163
2906.1502.0:<2014/10/14, 11:13:40>: 0x8000ffff (-2147418113 E_UNEXPECTED)
2906.1948.0:<2014/10/14, 11:13:40>: 0x8000ffff (-2147418113 E_UNEXPECTED): 403 Forbidden (0x8000ffff)
2906.674.0:<2014/10/14, 12:56:44>: 0x0 (WIN32: 0): Calling INDESPolicy::Uninitialize
402.379.949: End: 10/14/2014 12:56 PM 44.396s
========================================================================
402.534.948: Begin: 10/14/2014 12:59 PM 54.820s
402.539.0: w3wp.exe
402.543.0: GMT + 2.00
2906.611.0:<2014/10/14, 12:59:54>: 0x0 (WIN32: 0): Calling INDESPolicy::Initialize
2901.1042.0:<2014/10/14, 12:59:54>: 0x80004005 (-2147467259 E_FAIL)
2905.902.0:<2014/10/14, 12:59:54>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): ACF5137B 14E2E90B C828BB8D 7414D94E 63138959
2905.902.0:<2014/10/14, 12:59:54>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 72540F2E 5E9981B5 07E21ADB E5445668 FBF69C03
2905.902.0:<2014/10/14, 12:59:54>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 0E9E00BE 35BBF08C 5975A14E EAB7E224 DA13C163
2906.1502.0:<2014/10/14, 12:59:54>: 0x8000ffff (-2147418113 E_UNEXPECTED)
2906.1948.0:<2014/10/14, 12:59:54>: 0x8000ffff (-2147418113 E_UNEXPECTED): 403 Forbidden (0x8000ffff)
2906.674.0:<2014/10/14, 13:31:10>: 0x0 (WIN32: 0): Calling INDESPolicy::Uninitialize
402.379.949: End: 10/14/2014 1:31 PM 10.578s
========================================================================
402.534.948: Begin: 10/14/2014 1:38 PM 51.987s
402.539.0: w3wp.exe
402.543.0: GMT + 2.00
2906.611.0:<2014/10/14, 13:38:52>: 0x0 (WIN32: 0): Calling INDESPolicy::Initialize
2901.1042.0:<2014/10/14, 13:38:52>: 0x80004005 (-2147467259 E_FAIL)
2905.902.0:<2014/10/14, 13:38:52>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): ACF5137B 14E2E90B C828BB8D 7414D94E 63138959
2905.902.0:<2014/10/14, 13:38:52>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 72540F2E 5E9981B5 07E21ADB E5445668 FBF69C03
2905.902.0:<2014/10/14, 13:38:52>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 0E9E00BE 35BBF08C 5975A14E EAB7E224 DA13C163

Hi, from my experience iOS has problems with "Include Email Address in subject name". It worked at my customers without the setting.

cheers, Daniel

Hi,

I had kind of the same issue with iOS devices and SCEP certificates. Enrollment works fine on my WP8.1 devices. For me the solution was to modify the NDES Device General usage certificate template. In Extensions I unchecked "Signature is proof of origin".

After that you need to make a change to the SCEP profile in ConfigMgr and re-import the certificate. making the change was required otherwise it wouldn't update the xml file. My iOS devices started enrolling SCEP certs shortly after making the change.

Hy,

thanks for the reply!

Can you provide me the complete configuration of your certificate template and de SCCM certificate profile for windows phones?

I still have the problem with the cert enrollment

Many gre

Hi Christoph,

i had the same Problem in a customer Environment, the fix was easy:

The customer forgot (they did the csr themselves) to include the public name in the certificate on the NDES Server (for example: ndes.contoso.com)

Here is a screenshot of my working template for WP 8.1:

In Addition please check the following:

• Signature is proof of origin unchecked
• SCCM and NDES have valid Client authentication certificates
• required ports are open (don't forget Windows Firewall)
• SCCM 2012 R2 CU3 installed

BR,

Christian

• Edited by Christian Küver Thursday, November 20, 2014 2:32 PM

Hi Christoph,

i had the same Problem in a customer Environment, the fix was easy:

The customer forgot (they did the csr themselves) to include the public name in the certificate on the NDES Server (for example: ndes.contoso.com)

Here is a screenshot of my working template for WP 8.1:

In Addition please check the following:

• Signature is proof of origin unchecked
• SCCM and NDES have valid Client authentication certificates
• required ports are open (don't forget Windows Firewall)
• SCCM 2012 R2 CU3 installed

BR,

Christian

• Edited by Christian Küver Thursday, November 20, 2014 2:32 PM

Hi Christoph,

I know this is an old post, but I might have the same Problem, and the question here is not resolved. I also got no success for my Windows Phone 8.1 Deployment.

I have followed those Guides:
http://blogs.technet.com/b/tune_in_to_windows_intune/archive/2014/04/25/part-2-scep-certificate-enrolling-using-configmgr-2012-crp-ndes-and-windows-intune.aspx

http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx

SPN is set.

Certificate is Setup as in Blog from Pieter Wiegleven and  as suggested from Kent Agerlund in this Thread.

As mentioned in Pieters Blog, whe I open my URL (https://ndes.externalfqdn.com/certsrv/mscep?operation=GetCACert&message=MyDeviceID ) I'm getting the Donwload of a File.

The only Thing I can find is the Error in mscep.log:

402.534.948: Begin: 18.01.2015 21:59 21.685s
402.539.0: w3wp.exe
402.543.0: GMT + 1.00
2906.611.0:<2015/1/18, 21:59:21>: 0x0 (WIN32: 0): Calling INDESPolicy::Initialize
2901.1042.0:<2015/1/18, 21:59:21>: 0x80004005 (-2147467259 E_FAIL)
2905.902.0:<2015/1/18, 21:59:21>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): F7BB603E AE983172 55BEAB50 594BB3C9 455B13B3
2905.902.0:<2015/1/18, 21:59:21>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): E95F2957 5EB3C5C2 E6517815 EF00579F B711234F
2905.902.0:<2015/1/18, 21:59:24>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 6CD712F5 15F187CB EECE4D1D 15A472C8 7F596377
2905.902.0:<2015/1/18, 21:59:24>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 5370290C A2339F0E 42C84AF4 907AC6DD 2D121863

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

So far, I know there has to be a Problem with the Certificate. The Hashes are from Certificates in the local Certificate Store. But I checked the certificates, and they seem to be ok.

Could you solve your Pr

It was my last attempt, and it worked.

So as written above, everthing should be in place, that it would have to work.

Finally, I needed to uninstall and install the SCCM Policy Module with the latest *.cer from the certmgr.box.

I don0t know when this is cerated newly, but this was my error: I didn't update the Policy Module with the latest Certificate from SCCM.

Hi Kent

Only for asking ... I'm fighting with the same error but on WM81 Phone and Surfaces. Does this error 0x87d1fde8 figure out to a mistake of the template ? In the MDM Reg Hive of the HKCU I have the error code  0x4000500 what is I assumed Access denied. (URI etc are all available).

Last question is it possible to enrrol as Computer certs to the device (and not the user). The reason is that so with a NPAS Server is possible to grant Access for the devices which have the required Company cert.

Thx and Cheers,

+mat

We've tried every suggestion in these posts and been over the NDES infra many times to validate it against Microsoft documentation but we are seeing same error after enabling mscep.log which we found in c:\windows\mscep.log not c:\users\%ndes_svc_account%\mscep.log. Once we find it will post back.

==============================
402.534.948: Begin: 17/04/2015 9:46 a.m. 36.617s
402.539.0: w3wp.exe
402.543.0: GMT + 12.00
2906.611.0:<2015/4/17, 9:46:36>: 0x0 (WIN32: 0): Calling INDESPolicy::Initialize
2901.1042.0:<2015/4/17, 9:46:36>: 0x80004005 (-2147467259 E_FAIL)
2905.902.0:<2015/4/17, 9:46:36>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): C056BBA4 5D85BD9C 05BFEF2B 5F64CFFF F2E7EDBF
2905.902.0:<2015/4/17, 9:46:51>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 2A17EF2F 28FF04BA D447C7D1 F6495C54 FEE94F1E
2905.902.0:<2015/4/17, 9:46:51>: 0x80090349 (-2146892983 SEC_E_CERT_WRONG_USAGE): 03B4ED06 C4C640AF 5EC9AC42 DF537D56 34DFAD29
2906.674.0:<2015/4/17, 10:15:17>: 0x0 (WIN32: 0): Calling INDESPolicy::Uninitialize
402.379.949: End: 17/04/2015 10:15 a.m. 17.816s
==============================

Hi Matt

See here how I fixed. https://social.technet.microsoft.com/Forums/en-US/43cbcc5f-6588-4caa-bcf3-8968fc1950b8/ndes-certificate-enrollment-on-surface-fails?forum=configmanagermdm

Unfortunately the mscep.log is more confusing than helping. I assume these errors are raised by an improperly API from the policy module and the NDES Service, because in my lab these errors are persisent (with each reboot they are listed) but the NDES runs well like a charme.

The main issue in my lab was, that the REG KEY for the large URL are not set correctly on the NDES Server (copy/past error and dec/hex values), the december update is missing on the WAP, and the most important thing was that the NDES Cert Template cannot not have a longer expiration time than the issueing CA.  Following Pieters Blog the Computer template for ndes is used which has the same life time as an oob subordinated issueing CA (Installing an issueing CA there is no wizard how long the issueing CAs' certificate is valid. The root CA can be configured. So it is nessery before enrolling NDES Templates to change this lifetime of the issueing CA using certutil on the root CA and re-enroll the Issueing CA Cert ... and later start enrolling NES Templates and verify that they have a short life time. In my lab 6 months only).

I detected this mistake on the issueing CA which has a lot of failed requests with the parameter "Wrong life time" and in the crp.log the request for enrolling the cert was visible (file copy process to the site Server inbox).

Once uploaded of the Setting to the Intune MP (every 5 minutes .. consult the dmpuploader.log) within a policy refresh on a Surface this is applied in a couple of minutes.

Hope this helps

+mat

• Edited by Matthias GysinMicrosoft employee 4 hours 28 minutes ago

Hi Matt

See here how I fixed. https://social.technet.microsoft.com/Forums/en-US/43cbcc5f-6588-4caa-bcf3-8968fc1950b8/ndes-certificate-enrollment-on-surface-fails?forum=configmanagermdm

Unfortunately the mscep.log is more confusing than helping. I assume these errors are raised by an improperly API from the policy module and the NDES Service, because in my lab these errors are persisent (with each reboot they are listed) but the NDES runs well like a charme.

The main issue in my lab was, that the REG KEY for the large URL are not set correctly on the NDES Server (copy/past error and dec/hex values), the december update is missing on the WAP, and the most important thing was that the NDES Cert Template cannot not have a longer expiration time than the issueing CA.  Following Pieters Blog the Computer template for ndes is used which has the same life time as an oob subordinated issueing CA (Installing an issueing CA there is no wizard how long the issueing CAs' certificate is valid. The root CA can be configured. So it is nessery before enrolling NDES Templates to change this lifetime of the issueing CA using certutil on the root CA and re-enroll the Issueing CA Cert ... and later start enrolling NES Templates and verify that they have a short life time. In my lab 6 months only).

I detected this mistake on the issueing CA which has a lot of failed requests with the parameter "Wrong life time" and in the crp.log the request for enrolling the cert was visible (file copy process to the site Server inbox).

Once uploaded of the Setting to the Intune MP (every 5 minutes .. consult the dmpuploader.log) within a policy refresh on a Surface this is applied in a couple of minutes.

Hope this helps

+mat

• Edited by Matthias GysinMicrosoft employee Friday, April 17, 2015 3:19 AM

Hi Matt

See here how I fixed. https://social.technet.microsoft.com/Forums/en-US/43cbcc5f-6588-4caa-bcf3-8968fc1950b8/ndes-certificate-enrollment-on-surface-fails?forum=configmanagermdm

Unfortunately the mscep.log is more confusing than helping. I assume these errors are raised by an improperly API from the policy module and the NDES Service, because in my lab these errors are persisent (with each reboot they are listed) but the NDES runs well like a charme.

The main issue in my lab was, that the REG KEY for the large URL are not set correctly on the NDES Server (copy/past error and dec/hex values), the december update is missing on the WAP, and the most important thing was that the NDES Cert Template cannot not have a longer expiration time than the issueing CA.  Following Pieters Blog the Computer template for ndes is used which has the same life time as an oob subordinated issueing CA (Installing an issueing CA there is no wizard how long the issueing CAs' certificate is valid. The root CA can be configured. So it is nessery before enrolling NDES Templates to change this lifetime of the issueing CA using certutil on the root CA and re-enroll the Issueing CA Cert ... and later start enrolling NES Templates and verify that they have a short life time. In my lab 6 months only).

I detected this mistake on the issueing CA which has a lot of failed requests with the parameter "Wrong life time" and in the crp.log the request for enrolling the cert was visible (file copy process to the site Server inbox).

Once uploaded of the Setting to the Intune MP (every 5 minutes .. consult the dmpuploader.log) within a policy refresh on a Surface this is applied in a couple of minutes.

Hope this helps

+mat

• Edited by Matthias GysinMicrosoft employee Friday, April 17, 2015 3:19 AM

Thanks for your feedback @Matthias Gysin, we installed the following hotfix (KB3011135) but it didn't have any change in behavior for us and we've double checked the other items you mentioned which we had previously met as well,

We did get one step further though and the cause was the reverse proxy policy on the Axway appliance between the public internet and our WAP server. After fixing this we are now seeing MSCEP responses.

However one more hurdle to work through, new error in the MSCEP.log, will post once we resolve, 

2905.5884.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.2461.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.1973.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.5884.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.2461.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.1973.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)

MD

• Edited by Matt Duguid 14 minutes ago update

Thanks for your feedback @Matthias Gysin, we installed the following hotfix (KB3011135) but it didn't have any change in behavior for us and we've double checked the other items you mentioned which we had previously met as well,

We did get one step further though and the cause was the reverse proxy policy on the Axway appliance between the public internet and our WAP server. After fixing this we are now seeing MSCEP responses.

However one more hurdle to work through, new error in the MSCEP.log, will post once we resolve, 

2905.5884.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.2461.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.1973.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.5884.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.2461.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.1973.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)

MD

• Edited by Matt Duguid 11 minutes ago update

For me this looks like a an ASN Error that the request from the device was "cuttet".

Are there any Errors in the Log File regarding SSL ? Is sure that the Axway is able to handle URL's with 64k Size ? The decrypting Password (which is part of the URL Request) is very long. such long that not configured WebServers cannot handle them.

Is there a chance to test it connecting the WAP directly to the WWW. (In my is a Cisco PIX between the Internet and the WAP Server. WAP Server is Workgroup with 2 NICS).

The best log file for Troubleshooting the CRP.log. Here is visible if a request was done (communication with the Site Server) and the CA with the failed requests.

Hope this helps

+mat

Thanks for your feedback @Matthias Gysin, we installed the following hotfix (KB3011135) but it didn't have any change in behavior for us and we've double checked the other items you mentioned which we had previously met as well,

We did get one step further though and the cause was the reverse proxy policy on the Axway appliance between the public internet and our WAP server. After fixing this we are now seeing MSCEP responses.

However one more hurdle to work through, new error in the MSCEP.log, will post once we resolve, 

2905.5884.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.2461.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.1973.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.5884.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.2461.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.1973.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)

MD

• Edited by Matt Duguid Tuesday, April 21, 2015 7:33 AM update

Thanks for your feedback @Matthias Gysin, we installed the following hotfix (KB3011135) but it didn't have any change in behavior for us and we've double checked the other items you mentioned which we had previously met as well,

We did get one step further though and the cause was the reverse proxy policy on the Axway appliance between the public internet and our WAP server. After fixing this we are now seeing MSCEP responses.

However one more hurdle to work through, new error in the MSCEP.log, will post once we resolve, 

2905.5884.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.2461.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.1973.0:<2015/4/21, 18:18:46>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.5884.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.2461.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)
2905.1973.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)

MD

• Edited by Matt Duguid Tuesday, April 21, 2015 7:33 AM update

For me this looks like a an ASN Error that the request from the device was "cuttet".

Are there any Errors in the Log File regarding SSL ? Is sure that the Axway is able to handle URL's with 64k Size ? The decrypting Password (which is part of the URL Request) is very long. such long that not configured WebServers cannot handle them.

Is there a chance to test it connecting the WAP directly to the WWW. (In my is a Cisco PIX between the Internet and the WAP Server. WAP Server is Workgroup with 2 NICS).

The best log file for Troubleshooting the CRP.log. Here is visible if a request was done (communication with the Site Server) and the CA with the failed requests.

Hope this helps

+mat

Sorry I forgot: Is the root certificate already applied you can check this opening the URI to the NDES Server https://myndes.com and you don't receive a certificate warning ... NDES works only if the Access to the URI is not blocked. It is the  better way to configure the Root Certs in the Client Settings (Administration) or in Remediation Settings.

• Edited by Matthias GysinMicrosoft employee 4 hours 30 minutes ago

For me this looks like a an ASN Error that the request from the device was "cuttet".

Are there any Errors in the Log File regarding SSL ? Is sure that the Axway is able to handle URL's with 64k Size ? The decrypting Password (which is part of the URL Request) is very long. such long that not configured WebServers cannot handle them.

Is there a chance to test it connecting the WAP directly to the WWW. (In my is a Cisco PIX between the Internet and the WAP Server. WAP Server is Workgroup with 2 NICS).

The best log file for Troubleshooting the CRP.log. Here is visible if a request was done (communication with the Site Server) and the CA with the failed requests.

Hope this helps

+mat

Sorry I forgot: Is the root certificate already applied you can check this opening the URI to the NDES Server https://myndes.com and you don't receive a certificate warning ... NDES works only if the Access to the URI is not blocked. It is the  better way to configure the Root Certs in the Client Settings (Administration) or in Remediation Settings.

• Edited by Matthias GysinMicrosoft employee Wednesday, April 22, 2015 3:16 AM

Seeing the iDevice perform the following request against the NDES, 

../operation=GetCACert&message=SCEP%20Authority

The response can be saved as a .P7B file which when loaded contains certificates for our root/sub CA's, and two MSCEP-RA certs (one for CEP encryption, one for Exchange Enrolment Agent).

What we arent seeing is the iDevice ever make the following request against the NDES,

../operation=PKIOperation&message=%base64_encoded_message%

We finally found the cause of what "2905.1973.0:<2015/4/21, 18:27:21>: 0x8009310b (ASN: 267 CRYPT_E_ASN1_BADTAG)" meant for us. Might be a bug in SCCM. In the "Certificate Profiles" in SCCM for our "Root CA" the GUI showed the thumbprint but when we viewed the XML it actually had the incorrect certificate thumbprint of one of our "Sub CA" certificates in 2 seperate places. To fix, we deleted the problem policy and recreated from scratch. Our servers are on CU4 for SCCM 2012 R2 when we experienced this.

• Edited by Matt Duguid 3 hours 18 minutes ago clarification

Thank you Matt for the update

And yes this is necessary that if you change the certificate template then you have to re-create the setting policy because the XML file is outdated.

Sorry that I didn't share this earlier :-(

Cheers

+mat

This wasn't a change of the NDES certificate template at the ADCS (we do refresh in SCCM when making any changes to that) this particular issue was a change of the "Trusted CA Certificate" profile at SCCM. The thumbprint in the GUI here didnt match the thumbprint in the XML definition and should have. 

Thanks for the clarification. Good to known if I run in a similar issue.