Sunday, November 19, 2017

LIVE on R3!!!

We are live on R3!!!  The countdown continues ... it's been 2 days and 5 hours since our RTM environment went down!

The team came in this morning (Sunday morning) and ran through a battery of live transactions.  We ran various integration and each function ran a series of tests.  We decided at about 1pm to call it a GO!  We had a few final validations to complete, but felt confident.

I took the validation team out to a well deserved lunch.

I sent out the official WE ARE LIVE on R3 at around 4 pm PT with setup instructions to get to the new production environment.  The communication also included reminders on other setups and how to get assistance in the event they run into any issues.

Our first group of users came online about 4 hours ago in Asia, the next set of users will come online in 3 hours in France.  Our largest set of users will start coming in at 5 am.  We'll have several folks on site to support them.

We're not out of the woods yet.  We need to get past everyone getting reset up in the new environment.

But it already feels like a WIN!!!

Saturday, November 18, 2017

Our environment is upgraded - validating now!!!

DBA is done!

Our Production environment is upgraded!!!

- Database is split: business data and metadata.
- RTM USR layer model is deleted -- security is now in the CUS layer!
- R3 models and hot fixes installed.
- Several jobs were run related to hot fixes, differences in R3 that required some data clean up.

The environment has been passed to the IT Applications team for validations and a few remaining configurations and migrations.

- AIF services and Inbound ports need to be activated.
- Integrations need to be turned on.
- Batch jobs need to be set up.
- Some Transform projects need to be migrated.

We will have a functional team along with some of our IT team in tomorrow morning to perform live transactions to insure we are ready for Monday morning when all our users come online.

Friday, November 17, 2017

Nearly 8 hours in!

Started stopwatch @pvcj013

Initial steps completed:

- RTM Prod environment shutdown to all AX users.
- Batch processing completed.
- Integration activity drained.
- Backup of RTM Prod completed.
- 2 hours in (by stopwatch), DBA emails and says he going "DARK", no more status updates until upgrade is complete.


- 5 hours in (by stopwatch) - Email from DBA:

From: DBA
Sent: Friday, November 17, 2017 6:55 PM
To: IT Beaverton
Subject: I wish I knew this before I started the upgrade

Issue logged in our Issue Tracking System:

Issue Type:
17/Nov/17 7:15 PM
Due Date:

With the breaking doomsday news, we should delay the project to be with our loved ones.
Add Comment
But then closed by our BA:
Change By:
Planar Status:
New Backlog
Cannot Reproduce
Open Resolved
Add Comment
I awake in a stupor....What is going on!  But no worries, we forge ahead!

RTM going down in 1 hour to be transformed to R3!!!

Final reminders have been sent out to all company AX users.

Implementation partner is on-call in case we have an issue (always best to plan for this and then you won't need it right?!?),

DBA and IT have been emailed their steps.

Smoke testing team have identified live transactions to perform on Sunday.

I'm in Vienna right now, so headed for bed.  Hopefully I'll wake to find that we are well on our way!!!

I'll check emails before, between flights, and when I land at home.

Talk to you on the other side!!!

Thursday, November 16, 2017

Pinch me - it is happening!  Our R3 upgrade go-live cutover plan is in motion.  Final environments are being prepared...

We are refreshing our R3 Dev environment to be a copy of our final R3 UAT environment.  This is so that we can go back to review any testing or setups.  There are also few items that need to be done manually and won't go live until Dec 1.

One of our RTM environments is being upgraded with R3 components, this is the beginning steps of the upgrade.  When we shut down production which is only HOURS away, we'll copy the production database to this environment and perform the steps to split off the business data.

So in just about 15 hours our Production environment will be going down!  And the split will take place.

Wednesday, November 15, 2017

Liftoff minus 1.,.

We made the decision on Tuesday to move ahead with our upgrade plans!!!

We made this decision after expanding our test pool for the font issue.  No other users reported the issue.

Communications were sent out:

  1. To all enterprise employees to inform them of the upgrade, downtime to AX, and acknowledge and thank the project team.
  2. Directed email to all AX users to communicate one-time events, permanent changes, how to report and escalate issues.
  3. Directed email to manufacturing with additional information.
Preparations for upgrade:
  1. Environment refreshes - (1) copy of current production at the time of the upgrade and keep for reference of personalizations and general reference; (2) copy of our final R3 testing environment for reference; and (3) copy of R3 Prod after upgrade for production support.
  2. Smoke test preparations - we've identified several tests that we will perform live in the upgraded R3 environment.  Functional leads will work to gather transactions that can be performed on Sunday after the upgrade is complete.
  3. Lunch on Sunday - the smoke testing team will be thanked with a lunch out.
  4. Donuts - we plan to get donuts for go-live Monday for our manufacturing staff.  This is because so many will arrive at once and will experience a slow log in and one-time set up needs.
DBA is very busy!!!

Sunday, November 12, 2017

R3 Upgrade - The Final Countdown!!!

We are down to the final stretch!

  • Our final UAT was completed, a few issues but resolved and retested!
  • Communication to executive staff and managers sent a week ago.
  • Reminder to Finance and Operations management regarding downtime.
  • Final cutover plan completed and reviewed!
  • Two issues remain:
    1. Mapping of the user's local machine is not working.  This is something we did with group policies previously, it is not working in R3.  We will shift to using a network drive.
    2. Font issue - In some cases, the user see the AX menu in a very, very large font.  Upon navigation, it gets very small and then can overlap.  This leaves the user unable to use AX.  We suspect it is a Windows 10 issue.  So far it is only happening with 1 or 2 individuals and only when undocked.  We're asking 30+ people to test on Monday to see if any others experience the issue.  Hope not!
  • If we are a go - decision end of day Monday, then we'll take the production environment down on Friday at 3 pm (end of our day shift), and begin the upgrade.
  • Conversion activities by IT goes through Saturday afternoon/evening.
  • The project team will come in on Sunday morning to do live transaction smoke testing.
  • If all goes well, we'll release the system to all users by 4 pm Sunday for our Taiwan colleagues.

Saturday, October 7, 2017

A new go-live date - 40 days and counting...

Well... to try and hold our newly selected go-live date, we couldn't wait for Microsoft to find a solution to our printer issue.  It appears maybe that Windows/SQL Server 2012  just doesn't talk well to Dynamics AX.

So after reaching out to other Dynamics users on various social mediums (LinkedIn, Twitter, and AXUG online forums) as well as reaching out directly to companies in our local chapter, we've decided to locally install the printers onto each RD server.  This will complicate management and maintenance of printers and printer queues, but so far the printer list is staying stable.  The downside is that all users will see all printers that are installed.  Previously with group policies, we could define the list of printers for specific user group.  We have learned however that you can maintain printer using gpo, so we'll work on that.

We are now performing a final CRP which includes additional scope.  We worked on several backlog requests with work being done internally and from our implementation partner.  With R3, the workflow capability is more robust and we decided to implement purchase requisition approvals using job hierarchy and signing limit policy.  We also got Enterprise Portal installed, something that we did not do in our RTM environment.  This will give us the capability to send an email approval notification to approvers and they can click on a link which will take them to Enterprise Portal to approve without having to enter in their login credentials.

So besides having an upgraded environment with more current and supportable infrastructure and application versions, we'll also be adding some new functionality and capabilities to our users.

Sunday, September 24, 2017

One month later...where are we at with our R3 upgrade?

A month has passed since our original go-live date.  We have not solved our printing issue yet.

We opened a case with Microsoft and have had a number of interchanges, sent dumps and logs, done a lot of reviewing and looking.  The issue has been passed between technicians and product teams - the case has been around the globe!

We've created a fresh set of remote desktop servers pointing to a Windows 2012 report server.  We've also switched to User Profile Disk instead of roaming profiles.  We've added some additional group policies to further limit the number of printers a user will see (this we did in our current RTM production environment).  Microsoft found that we were missing a DLL related to .Net which had caused Dynamics AX to crash.  Microsoft had us compile MOF (Management Object Format) on each of our RD servers.  This corrected it TEMPORARILY!  The Microsoft case is currently in the hands of the WMI product team.

Our issue holding us from going live:  Dynamics AX will not consistently provide the correct list of printers.

We have set a new tentative go-live date which is in November.  A bit of a risk with this date since it is in a purported busy quarter for the company.  But hoping that we can resolve our issue and go-live before the end of the year.

However, we did not sit still and do nothing!

We reviewed our development queue and worked on several requests.  We set up and tested purchase requisition approval using signing limits, position hierarchy, enterprise portal, and a modified approval workflow.

We are preparing for another CRP and will perform another test upgrade.  We've started discussions with the business to get approval for the November go-live or determine when the next available window can be.

We've polled our local chapter to learn about their implementation and how they are dealing with printing.  We've picked up some ideas and will experiment with some of them in parallel to working the case with Microsoft.

The project continues...

Monday, August 21, 2017

Launch Delayed!!!

"A fully loaded shuttle ... includes lots of complex circuitry and moving parts, all of which can break. ... NASA will delay, or scrub, a launch after detecting an existing or potential problem. Delaying the launch can allow threats to dissipate or give officials time to diagnose and repair problems."  (excerpt from article)

And so it goes with our R3 upgrade.  We've delayed our launch that was planned to go-live over this past weekend.  We were not able to resolve our issue with Dynamics AX consistently serving up printer assignments.  We believe it is an issue with remote desktop services and how it is communicating with Dynamics AX.  We have a case open with Microsoft now.  If you want to read more about our issue, you can go to my previous post "RD server printing issues...share your experiences, PLEASE!"

Never fear though, we will push forward!  Stay tuned for more updates soon!

So I guess I'll have to spend my next few hours watching the total eclipse of the sun...

Saturday, August 5, 2017

Bartender label mysteries!!!

As a part of our Dynamics AX implementation, we have a bartender integration that allow us the ability to maintain our bartender label templates, populate the label with data from AX, and issue a print command to Seagull Bartender and printing is done on Zebra printers.

Print drivers are loaded onto our RD servers and the list of printers are served up to each user using group policies.  We have one print server.

Two mysteries...

Mystery #1:

We print using 2 types of label stock, some are continuous feed and others are perforated label stock.  We have over a 100 label formats.  Each label format includes printer settings.  In AX, we have a customization that populates the label template with data, and then issues a print command.

Somehow ALL our label formats were updated to perforated.  This caused quite a bit of havoc on our manufacturing floor because all our continuous feed printers started spewing out label stock and would not stop!!!

If we look at the label formats, the last updated dates are all different - some even very old.  How did that happen?!?  It seems some system operation updated them since the last updated date did not change.  We had been testing in our R3 test environment as well as printing in our production environment.

Mystery #2:
Something is slowing down label printing.  It can take up to a minute or more from when they issue the print command to when the first label is printed.  If multiple labels were requested, this can get very slow.  Sometimes the desired printer is not listed, and the user has to back out of the form and re-open in hopes that the printer list is updated.  Is it RDP, Seagull, or Zebra -- whose holding onto those labels???

PLEASE, PLEASE, PLEASE share any thoughts...

RD server printing issues...share your experiences, PLEASE!

What's wrong with this picture?

The printer is printing is going on!!!  Can't find my printer -or- it takes too long to print!!!

Okay, our issues are not that bad, but printing can be very slow coming out of AX.

We are using:
- Remote desktop services
- Group policies to determine what the user will see as their list of printers, this is because we have 4 main geographical areas
- Print drivers are loaded on each of the RD servers
- All printing goes through one print server
- Label printing uses a label interface application to Bartender
- Pixel perfect printing uses an application that has print forms that has some print management features
- Label formats and print forms share common folders between our R3 and current RTM environment

So now the story...

We've been working on an issue with our R3 environment.  The printer list was not populating properly.  It was not consistently serving up the complete list and/or the list that appears on the RD server is not matching the list that is seen once in AX.  Our infrastructure team has been working on these issues the last week or so.  We switched from roaming profiles to user profile disk.  But that has not appeared to have solved it.  They've done other things to try to help the situation, but I can't even begin to describe them!

Now coincidentally, we are having printing issues in our current RTM production environment.  Is it related?  We are not sure.  The environments DO share the same print server.  Could it be something we did on the R3 side that has inadvertently affected the RTM side?  Or is our RTM RD printing having its own issue because it knows its getting eliminated!!!  😀

We've been wanting to look at another way to control our printing.  Maybe the time has come, however at an unfortunate time - in the 11th hour of our R3 upgrade!!!

Anyone have ideas, experiences, or commiserating stories to share?!?  Has anyone looked at ThinPrint, UniPrint, or TSPRINT?  Any thoughts, opinions, ideas would be greatly appreciated by this PM!!!

Thursday, August 3, 2017

Security Series Unwrapped Completed - WHEW!!!

I hope you have enjoyed my Security Unwrapped Series!!!  Written in these 9 posts is what I have learned in the past 5 years - during our AX implementation project as well as post implementation from AXUG Summit sessions, webinars, and online community posts!!!

I want to thank all the individuals and websites that have helped me along the way.  Corey Bakhtiary of Arbela and Michael Cassidy of Fastpath, I've attended a number of your sessions! Microsoft's technet also provided many articles that were quite helpful.  Brent Wilson and Jason Nightengale of Sikich Consulting for being patient and providing some security details with me during our AX Implementation Project.  Matthew Maertern of Microsoft for answering many of my detailed questions last year before and after summit.  And there were many others that I can't recall at the heartfelt thanks!  I would not be here at this point of understanding without your help.

And now...I hope all of you that have followed my series, can fly like the planes in formation to successfully support Dynamics AX security for your organization!!!

Please share your comments, issues, or other areas you are interested in hearing about.

Hope to see you all at Summit in Nashville!!!

Tuesday, August 1, 2017

AX 2012 Security Unwrapped Series - Security Tidbits

This post will unwrap some miscellaneous Security Tidbits.   Some of the items noted are repeats of what I've posted already in this series, but thought to consolidate list here.

Management Reporter:
Management reporter inherits its security from the user's Dynamics AX security. Below are the access levels in Management Reporter and the privilege/duty that will grant MR access.

BI Cubes and associated AX reports:
Standard AX cubes are built and loaded using background jobs.  Several reports in AX access the BI cubes to create the report.  Many (but not all) of the reports have the word statistical in the report name.  To access these reports requires some additional access to be set up.  The BI cubes reside on the SSAS server, that server has role groups that the user must be a member to access the cube and hence access the statistical report.  The error you will receive if the user does not have access is:
"Either the user, <domain>\<userid>, does not have access to the Dynamics AX database, or the database does not exist." Below is a list of the various role groups:

Blocking users from Journals:
You can setup secondary access to limit the set of users that have access to posting inventory and general ledger journals.  This is done by defining user groups and using the "Blocking" feature on the journal name setup form.  Refer to my prior post: Security Unwrapped Series: Supplemental Setups for details.

Limiting users to specific organizations (aka legal entities):
By default when assigning access, the user will have access to all organizations.  If you want to limit them to specific organization (or legal entities), you can by granting by organization.  See my prior post: Security Unwrapped Series: Explaining the Security Menu for details.

Purchase requisition access:
By granting the Employee role to a user gives them access to create purchase requisitions.  However there is additional setups required before they can create a purchase requisition.  The navigation path is: Procurement and sourcing\setup\Policies\Purchase requisition permissions,

Each legal entity they are allowed to create a requisition in must be discretely granted - choose the view "By requester" and add the specific legal entities:

You can also grant an individual to create purchase requisitions in behalf of another person - choose the view - By preparer and choose the individuals they will be preparing purchase requisitions for:

Preventing updates to approved BOMs:
You can block updates to approved bills of materials by updating a parameter setting in the Inventory Management module.  Please refer to Kelly Kane's AX Soup blog entry: Don't Change my BOMs!

Other miscellaneous items:

1.  System administrator role can only be assigned by another System administrator.  Security administrators cannot assign this role to a user.
2.  Deleting a role, duty, privilege, or process in the UI does not delete the AOT security object.  You must go to the AOT to perform the delete.  If this is not done, it will cause a compile error.
3.  Enterprise portal also has its own security.  (I have not yet played with this, so will not add any details right now.  BUT expect it someday in the future!)
4.  Nesting roles is allowed and compiles without issue.  However the security add-in tool will only display correctly.  See my prior post: Security Unwrapped Series: Security Add-in Features for more details.
5.  When using the UI, your security elements will be in the USR layer.  When moving to Dynamics 365, this will be an issue.  This is because in Dynamics 365 security is compiled and stored as metadata.  To retain the security changes in the AOT, you will need to have a developer access the AOT to make the changes permanent.

Monday, July 31, 2017

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.

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)

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!

Sunday, July 30, 2017

Some R3 Upgrade Mysteries...HELP! 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.

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.
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!!!

Tuesday, July 18, 2017

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.

Sunday, July 16, 2017

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!!!

Wednesday, July 5, 2017

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!

Tuesday, July 4, 2017

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!!!