Approve/Deny URL is not opening for SCCM application approval request since enabling CMG - HTTP ERROR 400 RRS feed

  • Question

  • this is the full message.  
    This page isn't working at the moment
    If the problem continues, contact the site owner.
    HTTP ERROR 400


    Everything else CMG appears to be working. 

    Approval emails were working prior to implementation of CMG

    the new approve/deny links appear with cmg links now


    (tenant id and URL modified)

    I have been through this page and verified everything appears to be configured as required - https://docs.microsoft.com/en-us/mem/configmgr/apps/deploy-use/app-approval

    Configure email notification for alerts. - verified configured (wouldn't get the emails if it wasn't anyway)
    Enable the optional feature Approve application requests for users per device. - verified on
    Enable Enhanced HTTP (recommended) - verfied enabled, checked "sms issuing" certificates and there is a valid one there.  

    Select the option to Allow Configuration Manager cloud management gateway traffic for administration service. - verified
    The SMS Provider requires .NET 4.5.2 or later. - our server has v4.8
    Enable Azure AD User Discovery - verified enabled
    Onboard the site to Azure services for Cloud Management - clearly done as all other CMG options work.  
    Manually configure settings in Azure AD: added redirect URI to CMG client - https://cmg.fqdn/CCM_Proxy_ServerAuth/ImplicitAuth 

    (url modified)

    it is set to public and ID tokens is ticked

    (before adding this, I was getting a different message - "Message: AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application:"

    the ms-appx-web://Microsoft.AAD.BrokerPlugin/.... URI was already there

     -- - In the Manage menu, select Manifest, In the Edit manifest pane, find the oauth2AllowImplicitFlow property, Change its value to true. - DONE

    I did notice that the application doesn't have a home page in Azure, not sure if maybe this is the issue, but I can't find anything about what this might be.  

    ********************found this page which has better information about approvals**************


    troubleshooting section has this

    Links to approve or deny request through Cloud Management Gateway do not work
    • Verify that AAD User Discovery is enabled
    • Verify that Cloud Management Gateway is set up correctly
    • Verify Redirect URI is added for the client app on Azure: https://<CMGFQDN>/CCM_Proxy_ServerAuth/ImplicitAuth and oauth2AllowImplicitFlow is set to true: ("oauth2AllowImplicitFlow": true), in Manifest of the client app on Azure.

    which I'm pretty sure I have covered above.  


    • Edited by Paul Klerkx Thursday, April 23, 2020 1:24 AM
    Thursday, April 23, 2020 12:25 AM

All replies

  • maybe if somebody could explain step by step exactly how to do the following so I can verify I haven't mucked it up


    Configure the following settings for this native app (client app) in Azure AD (should be configured manually on the Azure Portal)

    Redirect URI: https://<CMG FQDN>/CCM_Proxy_ServerAuth/ImplicitAuth. Use the fully qualified domain name (FQDN) of the cloud management gateway (CMG) service, for example, GraniteFalls.Contoso.com.


    things like

    1. (should explain exactly how I navigate to this Native app in Azure AD?
    2. where can I see the FQDN of the cmg service so I can verify that what I am using is correct?


    • Edited by Paul Klerkx Thursday, April 23, 2020 1:51 AM
    Thursday, April 23, 2020 1:35 AM
  • Hi,

    We can try to verify the clients are able to successfully communicate with your server via the SCCM Cloud Management Gateway:

    1. On a client that is connected to the internet, run a Machine Policy Retrieval & Evaluation Cycle from the Configuration Manager control panel
    2. Under the Networking tab, you should see the name of the Cloud Management Gateway service listed as the Internet-based management point(FQDN)

    Best regards,

    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, April 23, 2020 8:07 AM
  • For anyone finding this post, I identified that the issue was not CMG related.  If new edge is your default browser and you use Secure Single Sign on, this combination is what breaks the email links.  

    it is a known issue and documented on the Microsoft edge uservoice.  

    Apparently what links don't work with SSSO is variable, some work, some don't, the Software approvals emails that go to CMG Don't. (for now anyway, hopefully MS will fix in future. ) 

    current options given to my users was to copy the appropriate link to chrome or revert back to legacy edge.  then they work.  


    Wednesday, May 6, 2020 1:04 AM
  • Throwing this out there just in case:

    We were experiencing the exact same issue, but ours turned out to be that we had the Redirect URI setup on the wrong App Registration in Azure.

    Looking at the blog Application Approval Improvements in ConfigMgr (https://techcommunity.microsoft.com/t5/configuration-manager-blog/application-approval-improvements-in-configmgr-1810/ba-p/303534#Email%20notifications%20for%20application%20approval%20requests), a key piece says to ensure you setup the redirect URI on the Client App (as opposed to the Server App). The full Microsoft Doc, Approve applications in Configuration Manager - To take action from internet (https://docs.microsoft.com/en-us/mem/configmgr/apps/deploy-use/app-approval#to-take-action-from-internet) does not specific which App Registration to configure.

    In our case, at least, we had initially configured the ServerApp, which threw the error message from this thread. Once we reversed that change and applied the settings to the ClientApp, approve/deny links worked as designed over CMG (with SSO and using Edge Chromium).
    Hope this helps.

    Friday, July 24, 2020 8:23 PM
  • thankyou very much for the info, other priorities currently, but I will get to this and check as soon as possible.  


    Monday, July 27, 2020 11:06 PM
  • thanks for the information, I have checked and I have the Redirect URI in the client application.  (got lucky 😉

    I do see though; a message has appeared where the redirect URI is

    This app has implicit grant settings enabled. If you are using any of these URIs in a SPA with MSAL.js 2.0, you should migrate URIs

    My next step is to find an interpretation of that.  Does the CMG client app "use the URI in a SPA with MSAL.js 2.0"?   If it does, I guess I need to then Migrate the URI .  Clicking the link next to "Migrate URI " window, brings up what appears to be a single click type option to Migrate it, so If I can verify it needs to be migrated, then I’ll look at doing that next. 

    For our change management process though, I also need to know how to “un-migrate” if it breaks the world. 


    This is on the client app page further down - We have both Access tokens and ID Tokens ticked.  

    Implicit grant

    Allows an application to request a token directly from the authorization endpoint. Checking Access tokens and ID tokens is recommended only if the application has a single-page architecture (SPA), has no back-end components, does not use the latest version of MSAL.js with auth code flow, or it invokes a web API via JavaScript. ID Token is needed for ASP.NET Core Web Apps. Learn more about the implicit grant flow

    To enable the implicit grant flow, select the tokens you would like to be issued by the authorization endpoint:


    Friday, August 7, 2020 5:56 AM