Engineer / Solution Architect / Dynamics 365-AX Technical Consultant / Instructor (MCT)

In this article, I will try to explain the Dynamics 365 Finance and Operations security architecture. There is a docs article that I like very much, I will try to recap the topics by referencing it. It is very important to understand the security infrastructure. In today’s projects, managing security and authorization can be a very demanding process. In order to manage the needs correctly, it is necessary to know the infrastructure and the features, capabilities and constraints of security tools. In this article I will address the following topics. I did not translate them into Turkish. Sometimes there is a semantic shift, so I think explaning them is better.

•             Security architecture

•             Role-based security

•             Duties

•             Privileges

•             Permissions

•             Authentication

•             Authorization

•             Auditing

Finance and Operations application uses role-based security structure. Authorizations are given to roles, users are not directly authorized. Users are assigned roles. A user without any role has no authority in the system. The user assigned the admin role has full authorization. More precisely, they are not subject to any restrictions. Role-based security is a hierarchical structure as seen in Image-1.

Image-1

Role-based security

Role-based security has actually been created parallel to the work of business units. Role is the structure in which the necessary authorizations are gathered for a position with certain duties to fulfill those duties. The role is actually parallel to the employee’s actual job in the company. It does not mean that every employee has a role. In some cases, a single person may be managing different business processes. So they must have multiple roles. It is essential to organize roles according to the job, not the person. At least one role is required to log into the system. Generally, everyone is given the role of System User.  You can use the System administration > Users > Assign users to roles form to assign the role.

Role assignment is made by admin accounts. Basically, roles consist of Duties and Privileges.

Image-2

Duties

Duties are where the necessary authorizations are gathered to carry out a certain work process. A task can be assigned to multiple roles. Therefore, a change you make to the duty automatically affects the assigned roles. The role can be assigned directly in Privilege, but for a more manageable infrastructure, it is necessary to create and use the duties.

Image-3

Privileges

It is the structure where the authorizations required to do a certain job are gathered. For example, the payment cancellation privilege only has the authorization required to do this job. You can give this privilege directly to the role, but as I said above, it would be a better approach to collect them in duties and assign them to roles. Security and authorization objects are defined for all objects in the system. You can find and replace the ones you need and add new ones. Especially in new developments, it is absolutely necessary to create Privilege. Duty may not be required for every development. It may be enough to grant this authorization with a specific duty, but not without Privilege.

Image-4

Permissions

Permissions refers to the level of authorization to access a specific object. This can be a MenuItem or any object. Generally, authorization is given through the entry point. And these are usually MenuItems. In some cases we also use it to directly define authorization for an object of the form.

Authentication

This is my favorite feature in the new version. I can use all tools with a single email. One of them, of course, is the Finance and Operations application. To enter the application, your user login must be created. I explained it in my previous article. Usually users are expected to be in Microsoft Azure Active Directory (AAD), but you can also add external users. You can set up 2-step verification.

Authorization

Authorization controls access to the Finance and Operations application. Security permissions are used for this. Security permissions determine how certain objects of the application are accessed. These objects are: menus, menu items, action and command buttons, reports, service operations, web URL menu items, web controls and fields.

Finance and Operations application uses a context-based security, so we define the level of access to a certain object. When you associate a privilege with an entry point, you also define an access level. Such as Read, Delete, update.

Auditing

User login and logout times are recorded. You can access these records from the admin account. (System administration > Inquiries > User log).

In this article, I tried to introduce you to the security infrastructure. It is a very extensive and detailed topic. Generally, projects have a person or team responsible only for these processes. When not designed correctly, maintenance costs and problems can be annoying. It is imperative to place the due importance and test well during the project phase. Generally, since consultants have admin privileges, they can skip tests with the required roles. Here it is recommended that key users do tests with the relevant role, not as an admin. I will continue to address security-related issues.

Regards.

www.fatihdemirci.net

TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, security architecture, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apss, Power Virtual Agents, what is Dynamics 365, Dynamics 365 ERP, Dynamics 365 CRM

Segregation of Duties görev ayrılığı olarak çevriliyor. Let me explain it with an example. Let’s say you want two critical Duties not to be assigned to the same person. For example, two duties such as invoice processing and payment should not be assigned to the same person. You are in a company where thousands of people work and it is not possible to track at a certain stage. Here SoD comes into play. A definition you make through Duty gives you a warning for such situations and allows you to control them.

Let’s see an example using the security objects we used in previous articles. Open the Security Configuration form.

Image-1

From the Segregation of duties tab, click on the Segregation of duties rules button. This form is also available directly on the menu. You can see it in Image-9.

Image-2

There are no records yet in the form that opens. Let’s create one by clicking New.

Image-3

Specify a name and select two Duties. I have chosen two sample Duties. The only thing I pay attention to is, I know which roles these two Duties are used in. I will need it to show the example. Of course, you will make this definition according to your business needs.

Image-4

After saving, it comes to my test user. FD Customer listing task is attached due to its current role. I add a new role and select one that includes Customer Invoicing. When I click add, there is a warning saying that a conflict occurred. If I click Yes, it will create a solution record for me.

Image-5

The record created includes information about this operation. I can accept assignment with the Allow Assignment option.

Image-6

Accepting means overriding the rule, so it asks for an explanation. After providing one, we have added the role. We could have blocked it if we wanted to.

Image-7

When you create a new SoD, you can check if there are anything that does not follow this rule. There is something that doesn’t follow my rule, but since we created an override record it didn’t appear here.

Image-8

You can follow the created records from the menu in Image-9.

Image-9

In this article, I have tried to explain briefly what Segregation of Duties is. Although it is a very nice feature, it still has many deficiencies. For example, it only works with Duty, but there is no solution for direct Privileges assigned to a Role. It asks when adding it to the role, but it does not have a mechanism that controls the changing duty contents afterwards. It is possible to use it. Especially if you do not define authorization other than Duty and create your Duties with the right logic, you can use it very easily. Investments are still being made in this feature, I think it will become much more developed in a short time.

Regards.

www.fatihdemirci.net

TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, Segregation of Duties, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apps, Power Virtual Agents, what is Dynamics 365, Dynamics 365 ERP, Dynamics 365 CRM

How to Move Developments to Dynamics 365 Finance and Operations Test and Live Environments? 3- Build

In this article, I will talk about how to perform the Build operation required to move the developments we made from Visual Studio for Dynamics 365 Finance and Operations to Test and Live environments. Build needs to be performed on a certain Branch. When Build is complete, if there is no error, it will generate a Deployable Package for us. We need this package for code migration.

You have to perform Build through Azure DevOps, not from Visual Studio. After logging in as a user with admin rights, open the Pipelines tab. Unified Operations platform – Build Main will be created automatically when you set Azure DevOps settings via LCS. We will take this as basis. Since our environment is only Main Branch, I continue without making any changes in the basic settings.  First let’s see how we can run it, then we will examine the other settings.

Image-1

Click the Edit button from the ellipsis menu.

Image-2

Build steps are listed.

Image-3

If you want to build a different Branch, you need to change the Server path. We are making a change here.

Image-4

You can right click and Disable steps that are not required at this time. I disabled the Deploy Reports step because I do not have a report development.

Image-5

The main step is Build the solution. Our Branch path is here again. If you want to build a different Branch, you should change this as well.

Image-6

Click Queue. Whn you click Run in the popup window, Build operation starts.

Image-7

You can follow the Build steps.

Image-8

If it completes with no errors, it will look like the following. If it gives errors, it is necessary to examine the logs and errors. Generally there are not very complex problems. There are cases such as missing reference, incorrect Check-in, but there may be situations that need to be further examined. You can open it by clicking on the record.

Image-9

When you enter, all your previous Builds will be listed. You can view their status and information. The first record is our last Build, completed without error. Click to open it.

Image-10

You can see details about the Build here. Click and open the relevant part (3 published).

Image-11

Under Packages, Deployable Package starting with AxDeployableRuntime is created. We need to download it from here and upload it to the LCS. I will explain this in my next article.  At this stage, the Build operation is done. Now let’s look at how you can create a new Pipeline.

Image-12

Main Pipelines are created by default. If you want to create them in other Branches, you either make all the definitions manually, which is very demanding, or you can use the Clone or Export features. For both cases, do not forget to change the path settings for the new Pipeline.

Image-13

You can Import the Exported file from the following path again. Generally code is transferred to live environment from Main or Release Branch, and to test environment from Dev Branch. Of course, these are approaches that vary depending on the project and the team.

Image-14

In this article, I tried to explain how Build is triggered through Azure DevOps. A machine is required for Build right now, but we will soon be able to do this thanks to an agent. It will be a faster and inexpensive solution. By completing this stage, we have reached the final stage in code migration. In my next article, I will explain how we deploy code over LCS.

Regards.

www.fatihdemirci.net

Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, Build, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apps, Power Virtual Agents, what is Dynamics 365, Dynamics 365 ERP, Dynamics 365 CRM

In this article, I will explain how you can publish SSRS reports (Deploy) for Dynamics 365 Finance and Operations application. It is one of the basic reporting tools of SSRS. You can use it in the reports you want to produce output. After the initial installation or after creating a new report, you need to publish it to see it in the app.

First, open Power Shell as Admin.

Run the following code for your Azure environments. Folder paths may change with updates.

K:\AosService\PackagesLocalDirectory\Plugins\AxReportVmRoleStartupTask\DeployAllReportsToSSRS.ps1 -PackageInstallLocation “K:\AosService\PackagesLocalDirectory”

Run the following code for local environments.

C:\AOSService\PackagesLocalDirectory\Plugins\AxReportVmRoleStartupTask\DeployAllReportsToSSRS.ps1

There may be some warnings, but you can ignore them while waiting for the result.

Image-1

All reports published without any errors.

Image-2

If you want to publish a certain report with Power Shell, you can use the code below.

K:\AosService\PackagesLocalDirectory\Plugins\AxReportVmRoleStartupTask\DeployAllReportsToSSRS.ps1-PackageInstallLocation “K:\AosService\PackagesLocalDirectory” -Module ApplicationSuite –ReportName .Report

Finally, you can publish a newly created report via Visual Studio as shown in Image-3.

Image-3

In this article I explained how to publish SSRS reports. There are many topics related to reporting. In my following articles, I will talk mostly about reporting features.

Regards.

www.fatihdemirci.net

TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, SSRS, Deploy, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apss, Power Virtual Agents, what is Dynamics 365, Dynamics 365 ERP, Dynamics 365 CRM

In this article, I will try to explain how you can update the versions of your Dynamics 365 Finance and Operations environments. First of all, we should give credit where it is due. Microsoft made the ERP system update almost like the Windows 10 update with a very good solution. I think the One Version approach is a revolution in business software. All customers using ERP in the cloud have to receive updates published periodically. The good thing here is that Microsoft updates the system at will, thanks to the Extension approach. Your developments are rarely affected by this. In the old system, it was a process that took months to even upgrade to a higher update. Now you can get it done in days or even hours.

In this article, I will explain how to upgrade a demo environment from CU34 to CU35.  First, select your project.

Image-1

Select the environment you want to update.

Image-2

Your environment information appears. Go down and look at the update information.

Image-3

It says that there is an update. Click View Update.

Image-4

It shows all of the update packages. Click Save package.

Image-5

Here I have selected all the packages. You must do this for the version update. If you need different updates, you can choose the package directly from here. Then click Save package.

Image-6

Name the package and click Save package.

Image-7

This takes some time depending on the size of the package.

Image-8

If it completes without error, the following explanation will appear. Complete the process by clicking Done.

Image-9

Go to the Asset library and open the Software deployable package tab. Package has arrived but has not been approved yet. We have to wait for a while.

Image-10

After approval, open your environment again and click Apply updates.

Image-11

Select your package from the page that opens and click Apply.

Image-12

The confirmation screen will appear. Click Yes and continue.

Image-13

It says our version will be updated. Click Yes.

Image-14

After that, the update process starts. You can track the status of the environment here. If there is no problem within 1 hour, the process will be completed. If there is a problem, you can refer to the log to see the origination.

Image-15

When the update is complete, if there was a problem, there are options such as undo and retry.

Image-16

In this article, I explained how an environment is updated to the new version. It’s a very simple process. If you need to update multiple environments, you don’t need to create packages for all of them. You can use the same package for all your environments. Make sure your environment is open before starting the update. If you turn off the machine from Azure side, LCS doesn’t see it. After the update is complete, it is useful to start a synchronization via VS for demo environments like this.

Regards.

www.fatihdemirci.net

TAGs: Microsoft Life Cycle Services, LCS, Azure, Azure DevOps, Update, Microsoft Dynamics 365, MsDyn365FO, MsDyn365CE, MsDyn365, Dynamics 365 Insights Power BI, Power Automate, Power Apps, Power Virtual Agents, what is Dynamics 365, Dynamics 365 ERP, Dynamics 365 CRM