A frequent request I get is with OneVersion updates in D365FO, how do we as end users know what security changes are occurring between D365FO versions? A fellow Microsoft MVP, Nathan Clouse, reached out to me asking about wanting to add the same information to his dynamics.fo website. He has dedicated this site to show changes that are occuring between D365FO versions. We decided to collaborate together to be able to achieve this and I wanted to show the steps we used as well as show how you can utilize the same tools.
Getting the security files
The first thing that we needed was to gather the security files provided by Microsoft with each release. These files are spread out in each module within the PackagesLocalDirectory folder. On a D365FO development environment these can be found at K:\AosService\PackagesLocalDirectory (the drive letter may be different in your environment).
Under each module, are the different folders containing all of the objects that exist within that module. Within this list of folders there are ones dedicated to security, specifically the AxSecurityRole, AxSecurityDuty, and AxSecurityPrivilege folders.
Within these folders are the actual XML files that contain the security data:
Since there are hundreds of modules within a D365 instance, there was no way we wanted to go to each module individually to get the security data. So we ended up writing a PowerShell script to iterate through each folder and obtain the security layers and output them to a separate folder. The script outputs all security elements from all modules into their respective role, duty, and privilege folders. We can then zip this folder up to make it easier to move. This script can be found in the GitHub project that is linked to in the Resources section of this blog post.
Process the security files and create the output document
Once we run the above process on multiple D365FO versions, we now want to be able to compare the security files between the versions. In our case we wanted to show what new security had been added, what security had been changed, and what security had been removed. For the modify action, we decided to stay at a high level and not show the actual changes between the security versions.
To do this we created a .NET application that could read the security zip files created in the previous step and perform the comparison analysis. This solution again can be found in the GitHub project linked in the Resources section of the blog post.
To perform the analysis between D365FO versions the command format is:
D365FOSecurityComparison.exe <sourceSecurityFileZipName> <destinationSecurityFileZipName>
An example of the command, and the output you will get while executing is below:
Once successfully executed, the command will create a Microsoft Word document with security analysis data. The document will be broken into a roles, duties, and privileges section with each security layer further broken into added security, modified security, and removed security sections.
We plan on putting out a Word document for each D365FO release to show the security changes but we are also making the source code files for the applications used above so you can run an analysis for any version combination you would like.
Hopefully you find this solution and these documents useful, if you have any questions please feel free to reach out!
https://dynamics.fo/security-report – where the Word document outputs of the security comparisons of each version are hosted. Be sure to check out the rest of https://dynamics.fo while you are there!
D365FO Security Comparison – the prebuilt release versions of the application/files used in this blog post (use this if you do not want to build the project yourself)
GitHub Project – contains the source code and PowerShell script used in this blog post (use this if you want to modify the source code)
This sounds like a great idea, Alex. One question from me: will this work both with security changes done via the Security Configuration (“application”) and security changes done via the Application Explorer (“code”)?
This solution is only looking at the security that is provided by Microsoft via code, it was not designed to look at changes via the Security Configuration (application/user interface) panel as this would be custom security from an end user.
Very nice Alex.
How about using VS > Source control, comparing two different branches, one have older another current versions. There we have several options to select what to display from source or target branches.
But yes, your approach would yeild more details. Very nice
This option would work for custom created security in the AOT, but unless you are checking in all Microsoft code as well would not show changes Microsoft is making to security between environments.