AX 2012 Security Unwrapped Series - Security Add-In Features

This post will unwrap the Dynamics AX Security Add-In Functions.  This function is available via the AOT and helps to analyze the security related to a specific menu item, table, etc.  I use this function to research what roles, duties, and privileges and their permission access levels for a specific menu item.

First you need to know the object name before you go into the AOT.  You can do this with a right click when in a form and select Personalize and the Information tab.

Once in the AOT, navigate to an object, right click, select Add-Ins > Security tools.  There are 3 sub-functions available when looking at menu items (You will see this function on any AOT object, but likely with limited or in some cases no functionality):

1. View related security roles is the key one to use as a security administrator.  
2. View related security objects goes a bit deeper technically and most useful for developers.
3. Security development tool will take you to this tool if you have it installed. (This is a topic of another blog in this series!)

The sub-function that I use in particular is View related security roles.  Displayed will be all the roles, duties, and privileges that have access to this menu.  Further it will display the permission access level - Full control, View, etc.  Please note that there is one bug with this form.  It displays the role and sub-role.  If you have embedded roles more than 2 deep, the information may not be accurate.

Please refer back to my first post in this series, AX 2012 Security Unwrapped Series - Understanding Role Based Security, that describes the security object hierarchy and the permission access levels.

With this information, you will see all the privileges that have access to either view or update. Additionally, you will understand the duties and roles that the privilege is a part of which will help you decide how you want to grant access to this menu item if requested (and who currently has access)!  The basics for maintaining security was described in my previous post in this series, AX 2012 Security Unwrapped Series - Explaining Security Menu.

Organizing your upgrade project...my thoughts

I was asked - Who does what in an AX upgrade project?  Should you hire your partner to do the work or do it internally?

This is a great question and I'm sure a lot of debate out there regarding approach.  Let's use this blog post to begin a discussion thread!

First, here are my thoughts (and it really applies to any project)...

Project Management - I always prefer to manage the project internally.  This is because an internal resource cares the most about the final outcome and understands the company's concerns.  If you pass management to an outside resource or partner, you then need to manage them and convey information, point them to the proper resource, explain implications and business impacts, etc.  The internal resource would likely have this knowledge already.

Technical Resources - This one is debatable and really depends on your implementation and how you've structured support.  If you have an internal support staff which includes a database/system administrator and developers, then taking care of the work internally makes sense.  We have an internal staff, but we are a small team.  Specifically for the 2012 R1 to R3 upgrade - it is very complex, so we've engaged our implementation partner to advise and assist with the upgrade process.  We also have a large customization that our partner developed and supports, so of course we will need to contract them to assist with this as well.  We also have some of our own development and we will take care of this ourselves.  However we'll use our partner for some general advise.

Functional Resources - With any upgrade (and as I stated in my earlier post "The beginning of an upgrade journey"), you should (1) review release notes for new features - do they replace any customizations or affect any business process implemented and (2) review customizations - are they still needed.  Then of course, you need to test every business process to insure they still function as designed or if they need modification due to changes in the upgraded software.  This, in my opinion, is primarily done by internal staff.  This could be done by your partner, if you have your processes clearly defined with every scenario documented with the expected outcome.  Then you could engage a partner to perform the testing, but likely most companies don't have documentation this detailed.

The Project - Create a project plan with a work breakdown structure, who is responsible, time duration, dependencies, and timeline.  Be sure you have clearly defined project roles and everyone involved is aware of their responsibilities.  I spoke about this at the 2015 AXUG Summit in the CUG07 - The Theory of Evolution In Successful Project Management.

So some questions to ask yourself as you begin to plan a project:

1. How much control do you want?
2. Do you have internal resources and do they have the expertise and knowledge?
3. Do you have a budget and if so, how much can you afford?
4. Do you have a partner that understand your business and your concerns?

You can't get completely out of project, but you can farm out as much work as you like.  If you farm the work, be sure to assess the risk of how well you communicated your requirements and concerns to a partner, and that they fully understood and you trust their work.  Put a process in place to check in, follow progress, understand issues and impacts.

Also in the end, you have to decide how much internal knowledge, expertise, and understanding you want to retain internally when the project is over.  The more you pass off, the less you'll know.

Please share your comments and I'll moderate a discussion!

R3 Upgrade: The code upgrade - don't forget to Run code upgrade checklist!

In my prior AX Upgrade post, R3 Upgrade journey - creating the R3 environment, I referenced the Upgrade in-place technet Article.   The article details out a long and arduous procedure, it is packed full of information and steps for the system administrator to follow.  It also directs you to several other articles. When doing the code upgrade, you need to run the code upgrade checklist after applying each model.

From the Upgrade in-place technet Article

This is very critical to insure that any new objects being defined will carry across to the R3 environment.  In particular any new custom tables - it is VERY, VERY important and will affect your data upgrade!!!  The technical lingo and pointer to the technet article is "preserve legacy element IDs [AX 2012]" when upgrading.  If you miss this step, you will lose the Business Data that are in these tables.  You will have to start over with applying code layer by layer.  This is because R2 added a column, partition, to all tables so you won't be able to copy the table over using SQL "select into" command.  Refer to technet article Data partitioning architecture [AX 2012] for more information.

We missed this step in our first attempt!

AX 2012 Security Unwrapped Series - Explaining Security Menu

This post will unwrap the Dynamics AX Security Menus and their functions.  It is located on the System administration Setup menu (see below).  I've also provided a diagram the general format of the security form.  There is a lot of information provided so I created a from template that describes the type of information that is displayed in each pane.

Setup Menu in AX

Diagram of Security Form

Assign users to roles
This menu item will allow you to assign multiple users to a role.  It is also a good form to use when you want to inquire on who is assigned a certain role.  When you first enter this form, it will display the list of roles in the left pane.  Click on a role to see the list of users directly assigned to this role in the lower middle pane.  I say directly because if you have embedded roles (this is discussed below in Security roles), then this form will not show those assignments.

The lower middle pane will display all AX users with a check mark beside the users that have access.  In the right pane, there are 2 sections displayed.  The top section shows the duties and privileges in the role and the lower section shows the roles of the selected user.  Select the Manually assign / exclude function in the lower middle pane to bring up another window where you can select additional users to add to this role. 

Assign users to roles - lower middle pane

If you want assign roles specifically to a single user, then it is simpler to use the edit user form.  This menu item is in the System administration Common menu under Users > Users.  Select the user to edit.  From this form there are several function, you can Assign roles or Remove multiple roles to a user as well as limit users access by company using Assign organization function.

Common menu and Users edit form

Assign organizations function allows you to limit a user to a specific company or list of company.  By default when you assign a user to a role, they have the access in all companies.  This function will allow you to modify the access of the specific user and specific role that has been selected.  As you can see below, when you enter the form you will see that Grant access to all organizations is selected since it is the default.  Select Grant access to specific organizations individually, the list of all company entities defined will then be displayed.  Select the desired company and click Grant.  The companies granted will be noted in the lower pane as seen below.  Use Revoke if you wish to remove a company from a user.

Assign organizations sub form

Security roles

Use this menu item to view, create, maintain, or delete roles.  When you first enter this form, the roles will be displayed in the left pane.  Navigate to an existing role in left pane.  The upper middle pane displays the AOT name, Name, and description.  The lower middle pane is where you'll see the contents of the role and this also where you can add or remove duties and privileges.  

If you want to embed a role within a role, in the left pane right click and hold a role and drag it to another role and release.  You will see the role in the lower middle pane and the role will have a + that you can expand the view in the left pane.

You can create a new role by clicking on New function for the left pane, then define it using the upper middle pane, and add duties and privileges using the lower middle pane.  

Security roles - lower middle pane

Security Privileges
Displayed in the left pane are the security privileges in hierarchical order by processes, duties, and privileges.  Click on the + sign to expand.  In the lower middle pane, you'll see the details of the item that is selected in the left pane.  If you select a privilege, it will display the permissions and allow you (1) add or remove privileges and (2) modify the access the access level of a permission.  Warning: if you change the access level, you are changing it globally for that permission!

Security privileges - lower middle pane

You can also create a new privilege.  Navigate to a duty in the left pane, click on the New function.  Define the privilege in the upper middle pane, and then add the desired permissions using lower middle pane.  You can search for existing privileges by navigating by process cycle (as on option), find the desired privilege, and select permissions and set access levels.

Add permission sub-form

Other menu items on the Security Setup Menu
Security entry point permissions is the Security Development Tool.  This will be discussed in detail in a future post in this series.
Record level security is a AX 2012 feature, it is being deprecated in Dynamics 365 for Operations.  It will be replace by Extensible Data Security (XDS).  At a high level, either function allows you to restrict access to only a part of a table.  For example, restricted access to only a segment of sales orders.
External roles displays roles that are intended to be assigned to users outside of the company, typically customers or vendors.
Segregation of duties is another sub-menu under Setup.  This will be the focus of a future post in this series.

R3 Upgrade: A year in the making...my personal reflections

Hard to believe that I started planning over 2 years ago, then started an internal effort in IT a year ago, but today one year later (!!!) we have a R3 environment with our company's data!!!

April 2014 - Created a skeletal project plan, started research, contacted ISVs and discussed with implementation partner.
January 2016 - Got a bit serious...contacted partner for an evaluation key, created a Contoso environment, collected up our ISV models.
March 2016 - Started informal project in IT.  System administrator begins to build an upgrade environment.  Partner working on upgrading our customizations.
June 2016 - After a lot of blood, sweat, and tears, we have an R3 modelstore!  But we have some work to do with our partner and with our own local customizations.
July 2016 - Some serious planning to organize documentation, partner developed customizations, local developed customizations, create plan to migrate security from usr to cus layer.
November 2016 - Create IT and functional project team and meet to discuss proposed project.
December 2016 - System administrator works with partner technical resource to complete upgrade process.  Enterprise portal and BI cubes are a new addition to our environment.
January 2017 - Second meeting with project team.  Team now has access to both Contoso and upgraded company environment; created lists for team members to begin review of release documentation, customizations, and open Microsoft issues that were waiting an upgrade.

So it is almost a year to the day of an informal project, but we NOW have R3 environments to evaluate!!!  I'm a happy girl!!!

R3 Upgrade journey - creating the R3 environment

Today: AX 2012 RTM CU3 running on  Wndows Server 2008 R2 and SQL Server 2008 R2
Target: AX 2012 R3 CU12 running on Windows Server 2012 and SQL Server 2016

Reasons to upgrade the infrastructure...below are the comments from my company's DBA:

There is some big improvements to SQL 2016 that we can take advantage of.  One of the biggest changes is the improvement to Query store.  For a dba, performance tuning will get easier.   There are some big improvements to security and auditing along with BI improvements.   Since we aren’t running Enterprise version, we can’t take advantage of the improvements to Always on, OLTP performance, operation analytics, and in-memory tables. 

With windows server 2012 we get on a more updated platform, big improvements to remote desktop services, PowerShell management, and a host of other management features.

Keeping our platforms moving forward will continue to offer up improvements and new features offered up by Microsoft.  

This is just to name a few reasons.  Keeping up with your vendors on software and hardware versions always has its advantages.  New features and enhancements are typically added to the most current releases.  You sometimes have to push to get support and bug fixes to prior releases.

Below is a diagram from Microsoft's TechNet Library Scenario: Perform in-place upgrade to AX 2012 R2 or AX 2012 R3 [AX 2012].  This for the most part describes our current environment and our target environment, what's different is we have a few additional AOSs and the BI are not represented.  On our BI server is where we have SSRS, SSAS, SSIS, Management Reporter and SharePoint (for Enterprise Portal).

We started our journey many moons ago as a background project.  Background projects don't get much steam as everything else takes priority.  So if you make the project official with a stated priority for your resources, the better off you will be!

When we started, the latest version out there was CU9.  Here are the basic steps (I'm sure I'm leaving out many detailed tasks done by our system administrator, but this should give you the general idea):

1. Created new servers (DB, AOS, and BI) and installed SQL Server 2014.  We'll upgrade to SQL Server 2016 later after we get compatible version software from our ISVs (one ISV will not be ready until 2017 Q2).
2. The DB is completely empty - NO business data!  It is truly like starting from scratch to build a new AX environment.
3. We then refreshed this environment with a copy of our current production environment.  Deinstall all application software - layer by layer from the outside in.  First CUS, then VAR, ISV, and SYS.  Then begins the rebuild.
4. Then build the R3 code base.  We installed vanilla AX, CU9, and compiled.  Installed all hot fixes that we had applied in our environment.  Next we installed each ISV model and compiled, then installed VAR models and compiled.  And lastly, installed our CUS model and compiled.  
5. All along the way, as with any compile, we had to resolve any code conflicts.  There were 3 main issues that we encountered:
• The main issue we ran into was - Microsoft and ISV removed or renamed an object that we referenced in our code.
• The second issue is element ids - Microsoft added some objects.  When we loaded our CUS layer model, we had element id conflicts.  Objects that we created in the CUS layer had the same element id as some of the new R3 Microsoft objects.  We had to update our objects to a higher unused element id number.  We will be creating a powershell script to do this in an automated fashion for future compiles.
• We also had a small bit of code merging to do with our CUS model due to changes in our VAR model from our implementation partner.
6. We installed Management Reporter and SharePoint on the BI Server.
7. At this point, we were able able to export a modelstore!  This is now the beginning of our R3 compiled code base.

Then there are steps that splits the database into two as depicted in the diagram above.  Surprisingly, we found out that the Business Data that is depicited in the above diagram contain everything from our R1 database however the AOT is not referenced anymore!  The R3 modelstore that we built is now in the modelstore database.

We also had to publish all SSRS and MR reports.  BI cubes were built and deployed.  Client was set up.

Friday (January 6, 2017), the project team met and we provided the URL to our project team!  They now have access to R3 with Planar data.

Whoopie!!!