Dual Write troubleshooting: missing AppID 6f7d0213-62b1-43a8-b7f4-ff2bb8b7b452

Dual Write troubleshooting

Several times, at the Dynamics Community, I had seen a question with an issue where Dual Write is not working correctly, and the health check is showing an error. I tried to help, but in those days. I wasn’t aware of the possibility that an enterprise application could be missing in Entra ID until recently. In this post, you will learn how to troubleshoot an error about a missing app reported by the Dual Write health check.

Health check

When you want to start using Dual Write, it is recommended to run the health check. Periodically, you can also run this to check the health, e.g., after a change in security or when deploying an update or customizations. You can learn more about the health check on Microsoft Learn: Dual-write health check – Finance & Operations | Dynamics 365 | Microsoft Learn

One of the outcomes can be an error in the Apps in tenant check.

Troubleshooting

The first thing you can check is if two required Dynamics 365 resources related to Dual Write are actually installed.

  • Dual-write core solution
  • Dual-write Application Core Solutions

When that is the case, you can check if there are entries in the setup form for Microsoft Entra ID applications for the next two client IDs.

  • 6f7d0213-62b1-43a8-b7f4-ff2bb8b7b452
  • 2e49aa60-1bd3-43b6-8ab6-03ada3d9f08b

Note that the Name columns were filled by me to recognize these Client IDs quickly, as the name was empty,

If this is all OK, you can search for the resources via the Azure portal. You can open the Microsoft Entra ID service and search for the GUID value. In case there is no result, the Enterprise application for Dual Write is missing.

Register enterprise application

When we found out that the Enterprise application was missing, we heard that it should be possible to recreate. We reached out to Microsoft Support and got a quick reply with instructions to be executed using PowerShell.

A global administrator for Entra ID can use the next steps:

  1. Open PowerShell with Administrator elevated permissions.
  2. install-Module AzureAD (if this module is not installed yet)
  3. Connect-AzureAD (this will open a pop-up where you can log in using your global admin account)
  4. New-AzureADServicePrincipal -AppID 6f7d0213-62b1-43a8-b7f4-ff2bb8b7b452

In case you are missing another enterprise application, you can replace the GUID after the AppID variable with another value. The Dual write application will be visible after this action.

After these steps perform Dual Write health check again and check if all is sorted and working correctly.  



I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!

2 replies
  1. Marco Scotoni
    Marco Scotoni says:

    Hello!
    very useful, just one update: The AzureAD library has been replaced by GraphAPI (https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-overview).

    Create an app registration (your automation identity)
    Grant it Application permissions such as Application.ReadWrite.All (or the least privilege you can) and admin consent
    Connect app-only and create the SP.

    go to PS with elevated rights and run those commands:

    Install-Module AzureAD

    $tenantId = “”
    $clientId = “”

    $secret = ConvertTo-SecureString “” -AsPlainText -Force
    $cred = New-Object System.Management.Automation.PSCredential($clientId, $secret)

    Connect-MgGraph -TenantId $tenantId -ClientSecretCredential $cred

    New-MgServicePrincipal -AppId “6f7d0213-62b1-43a8-b7f4-ff2bb8b7b452”.

    Reply
    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi Marco,

      I wonder if your comment has a relation to the script I shared in my blog. In the article you shared, the Azure AD Graph you are referring to was stopped in August 2025. The script was provided by Microsoft Support, and we ran it in November 2025. At least running it required global admin permissions. In the script you shared, this can be bypassed after an admin’s consent on an additional app registration. As it was a one-time-only job to run the script, running it with a global admin account seems sufficient to me.

      Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.