- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-25-2022 12:07 AM
Hi, we are trying to integrate our Microsoft Endpoint Manager (previously Intune) into Cisco ISE 3.1 Patch 3 as external MDM-server, but it always returns API version 2 instead of version 3 when testing connection. The documentation says version 3 is supported when using Microsoft Endpoint Manager. Enabling debug on the MDM-component reveals the following lines which seem to be relevant to the detection process:
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.authtoken.MdmAzureActiveDirectoryClient -::::- Access token has acquired succesfully from Microsoft Azure.
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.api.MdmServerInfoApi -::::- inside the method : callMdmServerInfoApiOnMdmServer()
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.apiimpl.MDMVerifyServer -::::- apiVersionSb : 3, mdmApiVersionSb : , tryWithV3 : false
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.apiimpl.MDMVerifyServer -::::- MDM Rest API Server Query String -> /ciscoise/mdminfo/?ise_api_version=3
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.apiimpl.MDMVerifyServer -::::- MDM Rest API Server Query PATH String -> /ciscoise/mdminfo/?ise_api_version=3
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.apiimpl.MDMVerifyServer -::::- 1. Connecting to the MDM server host fef.msub05.manage.microsoft.com using apiVersion 3
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- sendGETRequestDom: start HTTP request - connectionsUsed: 2, connectionsAvailable: 198
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- sendGETRequestDomNonComp: start HTTP request - connectionsUsed: 0, connectionsAvailable: 200
2022-08-24 15:01:05,195 DEBUG [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- ===mdmFlowInfo===null,=====serverType=====MobileDeviceManager,===serverAuthType===OAuth - Client Credentials
2022-08-24 15:01:05,195 INFO [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- GET: MDM Server URL: https://fef.msub05.manage.microsoft.com/StatelessNACService/ciscoise/mdminfo/?ise_api_version=3
2022-08-24 15:01:05,322 INFO [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- MDM Server Response Code: 200
2022-08-24 15:01:05,326 DEBUG [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- sendGETRequestDom: end HTTP request - connectionsUsed: 2, connectionsAvailable: 198
2022-08-24 15:01:05,326 DEBUG [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- sendGETRequestDomNonComp: end HTTP request - connectionsUsed: 0, connectionsAvailable: 200
2022-08-24 15:01:05,326 DEBUG [admin-http-pool55][] cisco.cpm.mdm.api.MdmServerInfoApi -::::- returning from the method : callMdmServerInfoApiOnMdmServer() -> com.cisco.cpm.mdm.api.MdmServerInfoData Object {
apiPath: /StatelessNacService/ciscodeviceinfo/mdm/api
redirectUrl: https://portal.manage.microsoft.com/networkaccesscontrol/index
queryMaxSize: 100
apiVersion: 2
vendor: Microsoft
productName: Microsoft Intune
productVersion: 5.0
COMMA: ,
errorMsg: null
errorOccurred: false
}
2022-08-24 15:01:05,893 ERROR [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Unable to load the handler impl class 'com.cisco.cpm.psqmgr.notification.PxGridNotificationHandler' com.cisco.cpm.psqmgr.notification.PxGridNotificationHandler
2022-08-24 15:01:05,893 ERROR [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Unable to get handler with name PxGridNotificationHandler
2022-08-24 15:01:05,893 WARN [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Handler with name 'PxGridNotificationHandler' is not loaded with impl class 'com.cisco.cpm.psqmgr.notification.PxGridNotificationHandler'
2022-08-24 15:01:05,894 ERROR [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Unable to load the handler impl class 'com.cisco.cpm.eps.config.ConfigChangeHandler' com.cisco.cpm.eps.config.ConfigChangeHandler
2022-08-24 15:01:05,895 ERROR [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Unable to get handler with name EPSConfigChangeHandler
2022-08-24 15:01:05,895 WARN [admin-http-pool55][] pap.api.handler.impl.HandlerInfoImpl -::::- Handler with name 'EPSConfigChangeHandler' is not loaded with impl class 'com.cisco.cpm.eps.config.ConfigChangeHandler'
2022-08-24 15:01:05,911 DEBUG [admin-http-pool55][] cisco.cpm.mdm.pip.MdmSettingsNotificationHandler -::::- add / update mdm server to the local MDM servers cache MSEndpMgmt
2022-08-24 15:01:05,912 INFO [admin-http-pool55][] cisco.cpm.mdm.util.MdmServersCache -::::- MDM server - Status : InActive, mdm server id : REMOVEDFROMLOG and mdm server name : MSEndpMgmt
Anyone else made this work with API version 3?
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2023 09:16 AM
After a month of zero updates I went into ISE again to try and troubleshoot again but to no avail.
So I searched the forum again, found this topic and after that gave bugsearch a go again.
There I found the following bug: https://bst.cisco.com/bugsearch/bug/CSCwd84055
The following is stated and including a workaround:
Symptom:
While integrating ISE 3.1 with Azure AD/Intune for MDM, ISE reports that MDM only supports Cisco ISE API Version 2.
This occurs due to ISE incorrectly assuming that in the Azure Auto Discovery JSON, ComplianceRetrievalService (V3) appears before NACAPIService(V2). If Azure result has NACAPIService appearing first, ISE picks that endpoint and ignores ComplianceRetrievalService that appears further in the output.
ISE needs first look for ComplianceRetrievalService in the entire JSON before failing over to NACAPIService
Conditions:
Integrating ISE 3.1 with Azure AD and it reports that it support Version 2 and not Version 3.
Workaround:
To workaround this issue, Auto Discovery has to be set to No and we can specify the endpoint for Version 3 manually.
Hostname: fef..manage.microsoft.com
Port: 443
Instance: TrafficGateway/TrafficRoutingService/ResourceAccess/ComplianceRetrievalService
Did you already try and test this workaround?
I've just pointed our TAC engineer to this bug as a possible workaround.
The given symptoms and clarification matches your last post at least in essence.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-25-2022 12:21 AM
- Ref : https://www.cisco.com/c/en/us/support/docs/field-notices/724/fn72427.html
>...Configure the use of MDM APIv3 Microsoft Intune integration. This includes the deployment of certificates to all Intune registered endpoints and confirmation that those certificates are used for network authentication. For further information, see the Integrate MDM and UEM Servers with Cisco ISE Configuration Guide.
Check of any of the mentioned 'arguments' can be applicable to your case.
M.
-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-25-2022 12:21 AM
@rogergh check out this Cisco video relating to configuring ISE 3.1 with Intune. https://www.youtube.com/watch?v=iAKyIHFqbgE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-25-2022 01:01 AM
@marce1000 The Azure application\registration is configured to use the Cisco ISE-certificate for authentication, and the Endpoint Manager device profiles are configured to deploy certificates from our PKI (with MS Connector for MEM\Intune) with the SAN URI as DeviceID (as per the documentation). We don't have to activate some other global MEM\Intune certificate config I assume?
@Rob Ingram The video seems very interesting, but from what I can see it doesn't seem to include configuring the External MDM-connector in ISE against MEM (Intune), only policy and endpoint-configuration after getting it up and running. Thanks anyway though, seems interesting for the post-config parts.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-25-2022 05:00 AM
- Check if there are any settings on Microsoft Endpoint Manager , where you could specify or set the api version to be used explicitly.
M.
-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? '
When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-25-2022 04:11 PM
In the logs, I see an MDM response of 200. This should mean a successful response to the APIv3 query, so it looks like that should be working.
2022-08-24 15:01:05,195 INFO [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- GET: MDM Server URL: https://fef.msub05.manage.microsoft.com/StatelessNACService/ciscoise/mdminfo/?ise_api_version=3
2022-08-24 15:01:05,322 INFO [admin-http-pool55][] cisco.cpm.mdm.util.MdmRESTClient -::::- MDM Server Response Code: 200
What have you configured for the Device Identifier in the MDM server config? Have you disabled the 'Legacy MAC Address' option for identity? If not, ISE would likely be using both APIv2 and APIv3 during the lookups.
You might want to enable the TRACE level on the external-mdm log via the Debug Wizard, test an endpoint, and see what details you can see related to the session (deviceIdentifier, GUID, etc).
Example from my Webinar:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2022 02:42 AM
Hi.
We can't adjust the settings for Device Identifier, since it only says that it supports API V2 (greyed out).
See the screenshots for our settings. I have removed client ID and Token Issuing URL in the picture only. They are correctly filled out in the settings.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2022 03:22 PM
The configuration on ISE and the API Permissions in Azure look correct.
Does your token endpoint have the following format?
https://login.microsoftonline.com/<tenantID>/oauth2/v2.0/token
Did you upload the Admin certificate from ISE to the App Registration in Azure as described from Step 7 in the guide (https://www.cisco.com/c/en/us/td/docs/security/ise/UEM-MDM-Server-Integration/b_MDM_UEM_Servers_CiscoISE/chapter.html)?
Have you installed all of the Trusted Certificates listed in Step 25?
Was this an existing External MDM in ISE that you are re-configuring to use the APIv3 or are you configuring it as a new MDM? If it was already existing using APIv2, you might try configuring it as a new MDM to see if that resolves the issue.
I configured it as a new MDM in my lab as per the guide, and my ISE 3.1p3 instance states it supports APIv3.
If all of the above are correct, you might need to open a TAC case and provide the TRACE level external-mdm logs for further investigation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-29-2022 06:11 PM - edited 08-29-2022 06:11 PM
I saw similar in a customer case, whose TAC engaged the BU escalation team as well as Microsoft Intune team. FYI.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-01-2022 05:34 AM
We have a similair problem, not resolved. MDM connections to our production tenant return API v2 but if I hookup the MDM to our my test tentant it defaults to v3.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-09-2022 06:40 AM
Thanks for the replies, guys.
I guess we will have to open a TAC case and get this investigated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-14-2022 02:00 AM - edited 12-14-2022 02:17 AM
Hi, we've the same issue currently and opened a TAC case as well. We see MDM respond with version 2 as well and TAC directs us now to the Intune Engineer to look for an option to simply enable V3 somehow.
So I'll do that. But...
How did it end for you? Was it fixed?
Thanks for sharing!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-14-2022 03:10 AM
Unfortunately the case progress has been very slow. After a lot of ISE log debugging, Cisco redirected us to Microsoft to verify that "version 3" is active and being sent, and then Intune support just redirect us to the integration guide and say that everything seems correct on their end (I'm not sure they understood what Cisco wants them to check, so I asked for a clarification from Cisco support as well, but haven't heard back yet). I can see from Microsoft documentation (https://learn.microsoft.com/en-us/mem/intune/protect/network-access-control-integrate) that they refer to their NAC-integration version as NAC 2.0, so the debug logs might actually return correct information (if it refers to Microsofts version numbering and not Cisco's, but I still need clarification from Cisco on this).
If you get any closer to a solution, let us know here as well
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-14-2022 03:20 AM
Thank you for your quick response. It's unfortunate that your case is dragging on as well. One would think Cisco and Microsoft should interact directly regarding which data is sent across and how it should be interpreted.
Thanks for sharing, I will as well for sure.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2023 09:16 AM
After a month of zero updates I went into ISE again to try and troubleshoot again but to no avail.
So I searched the forum again, found this topic and after that gave bugsearch a go again.
There I found the following bug: https://bst.cisco.com/bugsearch/bug/CSCwd84055
The following is stated and including a workaround:
Symptom:
While integrating ISE 3.1 with Azure AD/Intune for MDM, ISE reports that MDM only supports Cisco ISE API Version 2.
This occurs due to ISE incorrectly assuming that in the Azure Auto Discovery JSON, ComplianceRetrievalService (V3) appears before NACAPIService(V2). If Azure result has NACAPIService appearing first, ISE picks that endpoint and ignores ComplianceRetrievalService that appears further in the output.
ISE needs first look for ComplianceRetrievalService in the entire JSON before failing over to NACAPIService
Conditions:
Integrating ISE 3.1 with Azure AD and it reports that it support Version 2 and not Version 3.
Workaround:
To workaround this issue, Auto Discovery has to be set to No and we can specify the endpoint for Version 3 manually.
Hostname: fef..manage.microsoft.com
Port: 443
Instance: TrafficGateway/TrafficRoutingService/ResourceAccess/ComplianceRetrievalService
Did you already try and test this workaround?
I've just pointed our TAC engineer to this bug as a possible workaround.
The given symptoms and clarification matches your last post at least in essence.
