As many of us wind down for the festive season, now is a great time to think about the maintenance of the systems your business relies on, and get organised for next year. Next year, we see new trends emerging including Evergreen updates for Microsoft Dynamics 365, so use the end of the year to ensure you are prepared for changes to come.
There are significant differences in the actions you can take to maintain Dynamics 365 and Dynamics AX 2012 and older. Here’s our handy guide to the actions you should take now in order to maintain your systems:
- Non-production first then, after sufficient testing PROD
- Security updates should go in ASAP, the rest one month behind
- Standard SQL out the box is not very efficient
- Minimum best practice
> Ignore 0-33% Fragmented
> Reorganise 34-66% Fragmented
> Rebuild 67-100% Fragmented
Every version of the AX system fragments in different ways and speeds, so it is recommended that you run a check index fragmentation script to an output file/DB for a few weeks evaluate the collected data to see which your key tables are and tweak the above job to fit your exact system.
This should be run in accordance with the frequency of the index jobs. If you have highly transactional tables it would generally be beneficial to run more frequently but you can run jobs that only target fragmented tables.
- Use the standard module clean up batch jobs to maintain and keep your database growth in order. For example:
- Target and frequently check the following tables for large growth:
> Dbo.batchjobhistory
> Dbo.batchhistory
> Dbo.eventcud (there is a job in AX to cleanse this but often still grows due to the criteria of the clean-up job)
> Dbo.sysdatabaselog
User will set up more and more batch jobs as time goes on, ensure that they are configured with only say history ‘errors only’ as if you have 30 batch jobs running every 10 mins and logging history upon competition it will soon be millions of records and exponential DB growth.
Setup Application Object Server (AOS) to have windows service auto restart 3 times before no action (most restarts a day) often saves ERP downtime.
Setup AOS config to have garbage collector set to false, this will release RAM faster and stop processes crashing out the AOS if AX gets itself in a mess.
Have auto log off on thin clients for anything over a few hours as AX sessions can become corrupt if a user tries to reconnect.
- Know your RTO (Recovery time objective) how long your business can live without ERP
- Know your RPO (Recovery point objective) how much data can be lost during the disaster recovery process
- Test this process to make sure you can hit both of the above
- Can run in either check or fix mode against modules:
> Check mode may well hit the 1000 limit of info log messages
> Fix mode can fix missing data and orphaned data
- This can take a long time and should only be ran infrequently but still a planned activity
- For example: to fix inventory management
- Perform full backups minimum daily
- Log backups as often as the customer needs
- There is a last login report but this does not bring back just the last one per user, it has multiple entries per user
- SQL script can be easier to get this info. Below find an example which will only return one record per user:
SELECT USERINFO.ID, MAX(SYSUSERLOG.LOGOUTDATETIME)
FROM SYSUSERLOG INNER JOIN USERINFO ON SYSUSERLOG.USERID = USERINFO.ID
group by USERINFO.ID
- Microsoft address the common request from customers to be able to audit security allocations made for users in Dynamics AX
Microsoft Dynamics 365 is a completely different animal to Microsoft AX, but there are still steps you can take to maintain your system by:
Our guide covers it all in more detail. Download it below.