Your checklist for Microsoft AX 2012 and older:
1. Patch your servers
- Non-production first then, after sufficient testing PROD
- Security updates should go in ASAP, the rest one month behind
2. Unique rebuild/reorganise index jobs
- 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.
3. Update status
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.
4. Data purging
- 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.eventcud (there is a job in AX to cleanse this but often still grows due to the criteria of the clean-up job)
5. Batch job setup
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.
6. Save ERP downtime
Setup Application Object Server (AOS) to have windows service auto restart 3 times before no action (most restarts a day) often saves ERP downtime.
7. Stop processes crashing
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.
8. Auto log-off
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.
9. Test your disaster recovery plan on a regular basis
- 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
10. Consistency check job
- 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
11. Test your backups regularly
- Perform full backups minimum daily
- Log backups as often as the customer needs
12. Check for users last login dates - so you can disable any unused accounts for License saving
- 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:
13. Allow security allocations to be audited
- Microsoft address the common request from customers to be able to audit security allocations made for users in Dynamics AX