Dynamics Community Forum Thread Details

Environment

Product: Microsoft Dynamics 365 Finance & Operations
Deployment Type: Cloud Hosted Environment (CHE) / One Box Dev VM
Version: 10.0.x

Background

We have two Cloud Hosted Dev VMs:

VM-A – Previous developer's machine (source of the database)
VM-B – New developer's machine (target where DB was restored)

To provide the new developer with test data and organization data for testing, the VM-A database (AxDB) was restored onto VM-B. After the restore, the new developer completed all code merge work and started testing — but immediately hit an encryption error on every page load.

Error

Encryption error occurred with exception:
Microsoft.Dynamics.Ax.Xpp.Security.CryptoEncryptionException: Encryption error occurred with exception:
Microsoft.Dynamics.AX.Configuration.CertificateHandler.NoCertificateFoundException:
No certificate found for id 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'.
   at Microsoft.Dynamics.AX.Configuration.CertificateHandler.CertificateHandlerBase.GetCertificateFromLocalStore(X509FindType findType, String findValue)
   at Microsoft.Dynamics.AX.Configuration.CertificateHandler.CertificateHandlerBase.GetFirstCertificateForId(String id)
   at Microsoft.Dynamics.Ax.Xpp.Security.CryptoEncryptionEngine.GetCryptoServiceProviderByThumbprintBuffer(String idList, String thumbprint)

Investigation Done

1. Checked SYSENCRYPTIONKEY table in AxDB on both machines

The table is empty on both VM-A and VM-B
Confirmed the thumbprint is not stored in the database — it is sourced from the web.config

2. Compared web.config on both machines

VM-A web.config (source of the restored DB):

DataAccess.DataEncryptionCertificateThumbprint = <VM-A Encryption Thumbprint>
DataAccess.DataSigningCertificateThumbprint   = <VM-A Signing Thumbprint>

VM-B web.config (target machine where DB was restored):

DataAccess.DataEncryptionCertificateThumbprint = <VM-B Encryption Thumbprint>  ← Completely different
DataAccess.DataSigningCertificateThumbprint   = <VM-B Signing Thumbprint>

Both thumbprints are completely different across the two machines.

3. Checked certificate store (certlm.msc) on both machines

VM-A's DataEncryption certificate thumbprint is NOT present on either machine
VM-B has its own DataEncryption and DataSigning certificates present in Local Machine > Personal store
The thumbprints of VM-B's certificates correctly match VM-B's web.config

4. Tried LCS Certificate Rotation

Recycled the SSL certs from LCS for the VM-B environment
Re-verified the certificate store and web.config after rotation — both are correctly aligned on VM-B
Error still persists — the LCS cert rotation did not resolve the issue

5. Ran SQL query to find old thumbprint in AxDB

Ran a query searching for VM-A's old thumbprint across all string columns in AxDB
Query ran for over 2.5 hours without completing due to the size of the database

Root Cause (Confirmed)

When the VM-A database was restored onto VM-B, all its encrypted data came along with it — encrypted using VM-A's DataEncryption certificate.

VM-B has a completely different DataEncryption certificate and VM-A's original certificate no longer exists on any machine. So when D365 tries to decrypt the data from the restored database, it cannot find the certificate and throws the error.

The web.config and certificates on VM-B are correctly configured — this is purely a database encryption mismatch caused by the cross-machine database restore.

Question

What is the correct way to resolve this encryption mismatch after a database restore across two different Cloud Hosted Dev VMs in D365 F&O?

Specifically:

Is there a standard Microsoft post-database-copy re-encryption script that can be run to re-encrypt the DB data using the target machine's own certificate?
Is the Data Encryption toggle in D365 (System Administration > Setup > Data Encryption — disable then re-enable) the correct approach for this scenario?
Is there any other recommended approach to handle this situation cleanly?

Any guidance from the community or Microsoft team would be greatly appreciated.

Categories:

Dynamics 365 Finance

The thumbprint in that error isn’t coming from web.config. The stack shows GetCryptoServiceProviderByThumbprintBuffer pulling the thumbprint out of the encrypted value itself — written on VM‑A. That’s why the LCS certificate rotation didn’t help and why your web.config diff looked clean.

There’s no Microsoft “post‑copy re‑encryption” script for this scenario. Once the source VM’s private key is gone, anything it encrypted is permanently unreadable. You can’t re‑encrypt data you can’t decrypt, so the fix is simply removing the environment‑specific encrypted rows that came over with the database copy and are causing the AOS to fail when it tries to read them.

The Data Encryption toggle won’t resolve this. It can rotate keys, but it can’t recover ciphertext tied to a certificate that no longer exists.

The clean approach — and the one Microsoft support uses — is to delete the environment‑specific records that shouldn’t exist on the target VM: server configuration, server sessions, dual‑write connection settings, network printers, client sessions, etc. Back up the DB, run the cleanup, then IIS reset and reboot. This stops the AOS from trying to decrypt values from the old machine.

Long‑term, avoid restoring full AxDB backups between dev VMs. You inherit certificates, dual‑write config, batch jobs, and other machine‑specific settings. Use DMF exports for the data you actually need instead.