4 Years back when I started working on Dynamics Customer engagement and the common data service(now known as Dataflex Pro) was coming to life there were different admin fronts for managing, configuring and customizing each application and environment/instance. Those are still alive and functional but there have been new alternates introduced which are the way forward as everything transitions to the Power Platform. If you are new to the Power Platform or Dynamics 365 in general this is a good place to start and identify where to navigate for the specific task you want to achieve. I will try to list all of them on here as of July, 2020. The first one is the old CRM Admin center (https://port.crm.dynamics.com/G/Applications/Index.aspx) which was used for administering dynamics CE instances, installing solutions and applications, taking/restoring backups etc
This portal is still alive and well but there is a new alternate released by Microsoft offering the same and more functionality over the CE environments called Power Platform Admin center ( https://admin.powerplatform.microsoft.com/environments ) this offers analytics over the common data service, org capacity reporting, data polices and data integrator access. You also have the same functionality of managing environments, taking backups, initiating new environments etc as you did with the previous admin center. This is your gateway to environments if you are a developer or admin that works with multiple boxes, bookmark this one!
In order to customize and configure an individual environment whats still used is the customization portal through your crm environment as this offers detailed options on customization a lot of which have not been moved over to the power platform alternate yet
The new offering is the PowerApps portal(https://make.powerapps.com/environments/) from here you can create environment based Power automates(previously MS Flows), power apps, power portals, power virtual agents, AI builder etc basically all power platform services. You can also manage each component in solutions and have complete solution management available. So yea if you are doing anything on the power platform, bookmark this!
Those are the main ones, each power platform service has its own individual front as well which i did not mention here as they are all opened through these main portals. Below is the list of all portals we talked about and an additional one that was deprecated as soon as it was launched 🙂
Recently came across a scenario where we had to debug a user session that had limited rights to the system, one way of doing that could be for instance walking through a trace of the user session and another would be to debug code while user steps through the process but that would be done only for server side calls. So what if we need to debug client side calls as well, how to go about doing that was the challenge. Since if we assign the user role to an admin and execute the process we also have admin privileges which are higher up the ladder and do not limit access to what that user role has. Not to worry there is a way you can do this by following the steps below:
1. Run Dynamics AX as an administrator
2. Add the role you want to debug to your own user, let the Sys Admin role stay as well.
3. Open a new development Work space.
4. Place breakpoints where you need them.
5. Create below job
Us ISVs( Independent Software Vendors) want to make our own customized Ax solutions to run on predefined licenses so we can better monetize our solutions, well thanks to Microsoft we now have an ISV licensing feature to do this and do not need to create our own licensing mechanisms. The ISV licensing feature includes the following key capabilities:
ISVs can generate their own Boolean licenses.
A run-time check that ensures an ISV-generated license key exists.
You can read more about ISV licensing here. In this post I will be showing you step by step how you can create your own ISV licence against a model. Before you can create a license you also need to have certificates in order to sign that license so here are the complete steps from start to end:
First and foremost make sure you implement the desired roles and security in your code and tie all objects in your solution to it.
Create a configuration key (or a parent-child configuration key hierarchy) for the solution.
All code elements must bind to a proper configuration key or a hierarchy of configuration keys.
Make sure all code written for this solution has been moved to ISV layer and to a particular model.
Create a license code in the AOT.
Set the Authenticode (x.509 Certificate) to the license file. Go to the license code properties and find the ‘CertificateName’ item and provide ‘cer’ file (the public part of the certificate, You will use the SPC.cer file for this). Keep the private key (.pfx) part secure as it will be used to generate license file. Here are some details on how to do this:
Locate windows SDK on your machine, usually comes with .Net Framework, in my case I found it at following location
Copy following files from above folder to a new folder D:\Certificate folder, this would avoid wasting your time trying to run command on C:\ with no rights
To create a test certificate you can use the makecert utility, this will give you the .cer and .pvk file; as some of you faced problems with certificates I would like to add something here that I previously missed to mention. To use our own certificate we first need to create a CA(Certificate Authority) and then publish a code signing certificate through that authority. Creating a certificate authority is done through makecert as follows on power shell run the following command to create a CA:
Assign the license code to the configuration key. In the parent configuration key, select the license code in the properties. This locks everything together if hierarchy is maintained among other configuration keys.
Generate a FULL CIL.
Export the model by going to Start > Administrative Tools > Microsoft Dynamics AX 2012 Management Shell. Enter following command: axutil export /model:[ModelName] /file:[modelfilename] /key:[keyfilename]
[ModelName] is the name of the model
[modelfilename] is the path with filename to export the model to.
[keyfilename] is the strong name key generated using SN.EXE tool, in the case you want to sign the model with a strong named key. You can skip this part if you apply next step, which is to sign the model using a certificate.
Sign the model with certificate
You need a tool ‘SignTool’. You can get by installing Windows SDK.
Run following command:
signtool sign /f “[PFX file]” /p [PFX password] “[Path to the model file]”
Once you have implemented the code with the above approach, you can then generate a license for your solution as explained below:
/file:licensefile specifies the name of the generated license file
/certificatepath:filepath specifies the path to the certificate used to generate the license file. It is the private part of the X.509 certificate used on the licensed Code within AOT; basically the .pfx file.
/licensecode:name specifies the name of the license code used to generate the license file.
/customer:name specifies the customer name used to generate the license file. This will be provided by the Customer, it will be the Customer name on the AX license they have on their installation.
/serialnumber:number specifies the serial number used to generate the license file. This will be provided by the Customer, it will be the serial number of AX license they have on their installation.
/password:value is the value that must match the password of the certificate used to generate the license file.
/expirationdate:date specifies expiration date of the generated license. This parameter is optional.
/usercount:count specifies the number of simultaneous users for the generated license. This parameter is optional. (This is not supported anymore, so you can skip this)
After running this command you can write “type [licensefilename]” to see the content if the license file.
After you have your license you will share the model file and license file with the customer, also if you have created a self signed certificate(as we did with the makecert utility) then your customer needs to trust your Certificate Authority before they import the model and license. To do this simply run the command below on your customers environment:
certutil -addstore Root CA.cer
This adds it into the Windows certificate store.
Hope this post was helpful, for any questions feel free to leave a comment. Here are some good resources that helped me understand ISV licensing.
UPDATED: To overcome the “Certificate associated with license XXX is not a trusted certificate.” Error while importing license file the complete steps for creating our own certificate have been update, please find the updates in blue text.