Share
Report
8Hi all, hoping someone here has been through this before and can point me in the right direction.
I am working on deploying an ISV license to a Tier-2 UAT sandbox (D365FO 10.0.47) for the first time. The whole process seemed to go smoothly. I generated the license file using axutil genlicense, confirmed the tenant ID and tenant name against what is shown under Settings > Help & Support > About > Licenses tab, placed the .txt file in the correct folder structure inside the deployable package zip, and deployed through LCS without any errors reported. On the surface, everything looked fine.
I then only seemed to encounter the issue after logging in. The ISV does not appear anywhere under License Configuration, and trying to navigate to the ISV module throws this error:
I then decided to download the DBSync logs from the deployment on LCS and found that the license import step did run; however, displayed the following:
My current understanding is that the certificate used when generating the license is self-signed, and because the Tier-2 environment is Microsoft-managed, it does not have that certificate in its trusted root store. The deployment reports success because the package itself applied without issue - the license then just gets rejected during the import step because the signature cannot be validated.
There are a few things I would really appreciate the community's input on. First, is a commercially issued code signing certificate from a trusted CA genuinely the correct and expected approach for Tier-2 environments, or is there a supported workaround for getting a self-signed certificate trusted in a Microsoft-managed sandbox? Second, has anyone gone through the process of raising a Microsoft support specifically to get a certificate installed in the trusted root store of a sandbox environment, and if so, how did you frame that request and what kind of turnaround did you experience?
Your help would be greatly appreciated.
Many thanks in advance.
All responses (
Answers (
