Countdown to R3 - 17 days!

I'm in the pilot seat and doing the pre-flight check.  We've identified a few "startup" issues that we are trying to resolve still or our "upgrade" flight will be delayed.  The flight crew is busy trying to resolve the technical issues so our upgrade flight can take off as scheduled.

If you are a techie or know a MVP that might be able help, please forward the issues to them.  The issues are documented in my prior R3 Upgrade post titled "Some R3 Upgrade Issues - HELP!".

The flight attendants are ready to test at a moment's notice as they are so, so ready for this flight to take off on schedule!

Flight attendants have a pre-flight items to check themselves, but they are minor in nature and have declared "ready for takeoff"!!!

Countdown now at 17 days, 19 hours, 48 minutes to lift off!!!  At that time, we'll begin our takeoff.  It includes all our final pre-flight steps, the 24 hour flight, then post-flight checks before we let all passengers off the plane make the announcement on the plane loudspeakers that we've arrived at our destination - R3!!!  The ground crew are ready to take the luggage off the plane and hand it to our passengers.

Cast
Pilot = Project Manager
Flight attendants = Project team members consisting of functional leads, IT applications business analysts and developers, and DBA
Flight crew = IT Operations staff - DBA, HelpDesk, network administrator, and network analyst
Ground crew = Project team and IT staff
Passengers = Our AX users
Luggage = this is the baggage that comes with the upgrade that affects all our passengers including usage data being reset, personalizations to be redone, batch jobs to recreate)

Scenes
Flight check = open issues remaining
Pre-flight check = pre-upgrade steps, these are some steps we'll do before we had the environment over to our DBA
Flight = 24 hours elapsed time that we've allowed for our DBA to run through the various scripts and steps to actually perform the upgrade
Post-flight checks = various configurations and migration steps done by the IT Applications staff

I hope you've enjoyed my analogy of the actual R3 upgrade flight, pre-flight, and post-flight!

Some R3 Upgrade Mysteries...HELP!...now solved, we hope!

We've got 3 weeks to go!  Still working through some technical issues.  I'm guessing it has something to do with our remote desktop and how it interacts with Dynamics AX.  But not completely sure.

Thank you to all that replied to me regarding this post!!!

Issue #1:
Whenever logging into AX, the below message is displayed "File Deployment: The client installation is missing the required files to run Microsoft Dynamics.  Click OK to install them now."

The user can click OK, and the system continues immediately into AX.

Solution:
One of our 3rd party packages (to remain unnamed) needed to copy a DLL file to a fileshare.  We removed Cryptolocker, and this has appeared to solve the problem.

Issue #2:
When trying to save a file attachment, the below message appears "The operation has been cancelled due to restrictions in effect on this computer.  Please contact your system administrator."

The user can click OK, and save their file.  We have files storing on a file share inside our network.

Solution:
This was also a security issue, and resolved.  AX was setting to default location to a place where users can't access - hence the error message.  Sadly, now the default is the bin directory - the user no longer see the error message.  They however will need to manually navigate to where their file does exist that they want to save as an AX attachment.

I greatly appreciate all the responses that I received!!!

AX 2012 Security Unwrapped Series - Implementation Approach

This post will discuss a implementation methodology approach to use for implementing AX 2012 security.

Dynamics AX 2012 security requires you to assign roles to users for their access to Dynamics AX 2012.  Microsoft has created standard roles which are comprised of duties and privileges.  These standard roles are the various functions within an organization and includes all the AX functions that are needed to perform the responsibilities of their job role.

Treat these standard roles as your templates or building blocks to create the security model for your specific organization.  To refresh yourself please read my entry in the unwrapped Security series, AX 2012 Security Unwrapped Series - Understanding Role Based Security.

Dissect your company and break it down into functional areas or responsibilities.  Then using the standard roles that Microsoft has provided in Dynamics AX, build your custom roles.  Here are some rules to follow:

• You may find that the standard role is a subset of what is needed for a role you want to build.  In this case, embed the standard role into your custom role.  
• If you find that the standard role has a few duties or privileges that you don't want to include, then I would recommend cloning the standard role and remove the few items that should not be included.  Then embed this cloned/modified role.  Name this cloned role so that you remember and reference it back to the standard role.
• If none of the standard roles suits your need, then create a custom role and add the duty and privileges manually that are needed.

Traversing through the Security menu and how to use the functions is discussed in detail in the 2nd entry in the unwrapped Security series, AX 2012 Security Unwrapped Series - Explaining Security Menu.  This will allow you to create roles using the user interface.  A note of warning, roles are AOT security objects and will create an object in the AOT.  So depending on the layer you've logged into, will define what layer in the AOT the object will reside.  Generally, users log into the USR layer.  However IT individuals, particularly developers have access to the CUS layer.  Check out my blog post titled "Whose code prevails...peeling the onion!" to understand the code layers.  If you choose to make this a developer task, they can create and maintain the custom roles in the AOT.  However instead of referring to the objects by their Name, you will need to know the AOT name.  The steps are very similar.  Embedding roles is done by adding a subrole.  You can add permissions via the AOT, something that you can't do directly in the standard user interface.

Creating your security model should be an integral part of your AX 2012 implementation project.  Below a high level summary of an implementation project and where developing of your security model should be interleaved.  The approach is a progressive methodology approach.  Treat your roles as any other development, logging issues during testing and solving them by updating your roles.

The Security Development tool will help you research what access is allowed by role, duty, or privilege.  Review my post, AX 2012 Security Unwrapped Series - Security Development Tool, for a detailed description how this tool works.  If you have access to the AOT review the post, AX 2012 Security Unwrapped Series - Security Add-In Features, can offer you some additional tools to determine security objects  you need.

AX 2012 Security Unwrapped Series - SOX Compliance

This post will unwrap the Segregation of Duty sub-menu in Dynamics along with a discussion on SOX Compliance.

The Segregation of duties sub-menu in Dynamics AX 2012 is under System Administration> Setup> Security menu.  It provides functions to set up SOD rules, however it is limited to setting up rules using the AX 2012 security duties.

There are 4 menu items:

- Segregation of duties rules.  This is where you maintain SOD rules.  There is also a button to validate the duties and roles against a rule.  It's best to know the name of the duties you want to put in your rule first.

- Segregation of duties conflicts.  After running the Verify compliance of user-role assignments menu item, all conflicts found will stored in a table here to then resolve.  From this menu, you can decide to allow or deny the assignment.  If you choose to allow the conflict, you need to enter in an override reason.

- Segregation of duties unresolved conflicts.  This will show those conflicts that have NOT been allowed.  Maintenance of the remaining conflicts can be done here.

- Verify compliance of user-role assignments.  This menu item will parse through all defined SOD rules and user assignments.  Any user that has a conflict will be reported in a log and results stored in a table.



Let's walk through an example.

The below compliance rule created using menu item Segregation of duties rules which states that you don't want someone that can create or maintain sales orders (Duty Maintain sales order entered into field First duty) to be able to ship a sales order (Duty Approve shipping operations into field Second duty).  The reason is that then an employee could steal company products which you enter into field Security risk.  If you allow some individuals to have this conflict in the system, then you can note what your mitigating process is into field Security mitigation.  Below is the completed rule in AX and validation run showing no roles out of compliance:

Below is an example of a rule defined and one that has conflicts in roles that exist in the system. Likely the roles reported should be corrected, otherwise anyone that has the role will be in conflict.

Now let's run the verification of user-roles using menu item Verify compliance of user-role assignments.  To simplify run, the example is assuming only the first rule is loaded.

These infolog message are also stored in the SOD conflicts table.  Go to either the Segregation of duties conflicts or Segregation of duties unresolved conflicts menu item to resolve the conflicts.

If you want to Allow assignment, you will need to enter why you are override the rule:

Or if you Deny assignment, you will need to select the role to exclude:

AX will log the actions taken in the SOD conflicts table.  Note the 2 conflicts that were address.  The first line is noted with a Resolution of "Override" with a Reason for override of "Only user at this location.".  The fourth line is noted a Resolution of "Exclude".

Using the Segregation of duties unresolved conflicts menu, AX filter only the conflicts that have not yet been addressed.  From here you can process each conflict, as you resolve each conflict it will be removed from this menu.

A few additional words about the limitation of this function.  In the above example, the rule was trying to discern who had the ability to ship a sales order and determine if they could maintain sales order.  This really needs come down to the privilege.  The privilege that actually performs the shipment in AX is Process sales packing slip which is in other duties, one duty is Maintain sales packing slip.  To perform complete SOD compliance, you would need to create multiple rules for every duty that had this privilege!  It can become quite onerous!

R3 Upgrade - Testing the Infrastructure

So the project team tested the applications, we thought we were good...

Then the IT Operations team reminded us that we'll have all new servers which means that we need to test that too!  What does that mean?  I can't say that I can completely articulate that, but here's a start:

Upgrading to R3 allows us to upgrade the infrastructure which means upgraded SQL server, windows server, remote desktop services, upgraded management software and tools to support all of the above.

We use multiple RD (remote desktop) servers to access AX.  Installed onto these servers are the same things that would be installed on your local PC.  This include printer drivers, Microsoft Office, and if applicable Bartender.

We use multiple AOS servers to load balance user sessions of AX.  One AOS is dedicated to batch processing in the evening.  There are some application components that need to loaded onto each AOS.

By advice of our system administrator, there were some specific areas we should test given we will have new servers (this is written in non-technical speak):

1. Create, save, and view file attachments.  This is to test going to file shares to load a file to AX and then retrieving it.  AX defines where documents are stored in Organization administration> Setup> Document management> Document management parameters.
2. Exporting of reports and form grid contents to Excel.
3. Printer assignments.  We control this by group policies which is set up on the RD servers.
4. Creating and printing of documents - Besides standard SSRS reports, we use Bottomline Transform/Precision Forms.  This will test the connection to the Transform server and forms we have defined.
5. Access to pdfeditor.  We have defined some of our Transform documents to be editable using a pdfeditor.  The pdfeditor needs to be loaded on the RD servers.
6. Label printing.  We have label software connected to AX which in turn uses Bartender.  License keys had to be applied to both, and for Bartender we had to hardcode some information on each RD server due to crossing over subnets.
7. Importing data into AX.  This tests the setup of inbound port setups and then actually being able to load files from file shares.

The above tests need to occur on each RD and AOS server to insure any setups or configuration that is specific to each RD or AOS is accessed and testing.

R3 Upgrade Countdown Counter - 32 days and counting!!!

I created a Countdown Counter for anyone who wants to follow 😊

This is when we will take our Production environment to all users and begin the final steps to upgrade to R3!

The production cutover plan has been drafted and now refining it for success...

Still very busy...

• Testing of the our new R3 infrastructure
• Commandeering resources for the cutover weekend
• Drafting the various communication messages
• Solving any open issues...

It's going to be a busy month!!!

R3 upgrade - Go-Live Countdown!

It's just a little over 6 weeks before we enter our upgrade weekend which is scheduled to begin on Friday, August 18 at 3 pm PST.

We've come a long way already!  Here's what we've completed:

1.  Reviewed all our customizations and determined what we didn't need or use anymore.  For those we decided to retain, we validated that they were still in working order or made the adjustments necessary to continue to use them.
2.  Built new servers with upgraded versions of operating systems and applications.  Besides Dynamics AX itself SQL, Windows Server, remote desktop services, PowerShell, SharePoint, Management Reporter, and Excel were upgraded.
3.  Created our upgrade script (view previous post upgrade script here) starting from the Microsoft published documentation.  Each company's upgrade will have their own nuances depending on your configuration and specific version.  Our DBA/system administrator stepped through the documented upgrade script and made his own script with additional notes and details.  Through our testing, we found additional steps that needed to be added to make our system functional.  There were also some things learned along the way that adjusted some steps.
4.  Built our gold modelstore (view prior post on gold modelstore).  This is your starting code base.  One of the early steps of the upgrade in place process.  The gold modelstore is vanilla CU9 with any VAR, ISV, CUS and USR layer models from your production environment and any adjustments you need to make to have a clean compile.
5.  Determined additional models to make our final code base that we'll take to production.  From our testing and validation of customizations, there were updates to code that we made.  Some came in the shape of hot fixes from Microsoft and our ISVs as well as code fixes related to our customizations.  We are also including a few additional enhancements that were identified by the business.

What we have left to do:

1.  Final round of testing.  Our DBA/system administrator will walk through a final dry run of our upgrade script.  Included in the script will be updated model from our implementation partner, a hot fix from one of our ISVs, and our internal development model.  We'll execute a mini regression test touching on key functions and integrations.
2.  Coordinate with the business.  Communications have already occurred to select an appropriate downtime window that will work with the business.  Planned are various notifications: an early communication of the upgrade schedule, a notification day of, and of course updates when the system comes down and when it will come back up.
3.  Create a detailed cutover plan.  Besides executing our unique upgrade script (#3 above), there are the steps that we need to perform ahead of the upgrade script and then what we'll do after.  Ahead of the upgrade scripts, we want to insure that the system is shut down to all users, we've completed a a final run of batch invoicing, load revenue and backlog to the data warehouse, shut down all integrations to/from AX, and back up the environment.  After the upgrade script is complete, there are some additional configuration steps to perform, code migrations of related and affected applications.  Then we'll perform a smoke test of key functions and integrations before making the announcement to the user base that the production system is back online and upgraded.

Then it will be all hands on deck from IT and the project team to answer questions and fend off any go-live issues.  Hopefully it will be minor familiarization type issues and the project team can go outside to experience the solar eclipse!

Register now!  Join your Microsoft Dynamics 365 and AX peers at D365UG/AXUG Summit on October 10 to 13 held at the Gaylord Opryland Hotel in Nashville, Tennessee.  Come early and attend Pre-Conference Academy Classes held on October 9 and 10.  Advanced Pricing ends September 7!

The sessions are organized into 13 main tracks, Security and Project Management being 2 of tracks that I will be involved in this year as organizer and presenter!  Each track also has a dedicated room, making it logistically easier if you are focusing on a single track!

Why you should attend

D365UG/AXUG Summit is THE go-to event that brings industry experts, software development vendors, and everyday users together to discuss important issues, trends, product updates, customer pain points, and genuine solutions.

The value of D365UG/AXUG Summit is endless! Here are a few reasons why YOU should attend:

·         Meet & Network with your user group buddies: Overcome system challenges without risking down time for your organization by making professional connections. D365UG/AXUG Summit connects companies in like-industries and individuals by job-role, so you can grow your support network.  At meal times, breaks, in the expo hall, and with other organized social events.  Check it out on the D365UG/AXUG Summit website.  Roundtables and Ask The Expert sessions are a good to meet new user group members of like interests and issues.

·         Geek out over great content: There’s no better instructor than an actual Microsoft Dynamics 365 or Dynamics AX user and that’s what makes D365UG/AXUG Summit unique. Learn how to make the most of your current implementation through user-led education around specific functions and modules within Dynamics 365 & Dynamics AX.  Users will be involved at every session (!!!), either as the main presenter, a panel member, or as a session moderator.

·         Evaluate and test solutions: Understand third party solutions and learn what they can do for your industry or organization.  From the Partner Solutions Showcase sessions to the Expo Hall, there are countless possibilities to hear, meet, and discuss with partners and ISVs.

·         Serve as a voice: Speak with vendors and Microsoft representatives so they understand your product pain points and can grow your industry with their products and future development.  Besides being a presenter at the general session,roadmap, and product strategy sessions Microsoft will have feedback sessions (previously called Conduits or Influencer sessions).  Check the conference full schedule as these come available.

Register now!  I hope to see you there this year!!!