Our company still employs the method of using XPO files to deploy modifications even though we're on 2012R2 and are fully aware of the MS deployment recommendations to a production environment. Please accept that fact as a given as I ask my question.
The usual sequence of events during a deployment involves draining the servers and ensuring only a sys admin is logged in to do the work. As the deployment happens we keep the 'reject new clients' flag checked on all instances. We've had on occasion during the import compiling process where the client would crash, and because the 'reject new clients' flag is on, we're forced to restart the AOS in order to get back into the server to do an increment or full CIL compile.
Does an XPO import require the application to spawn off worker threads to manage the particulars of the import, in which case having the 'reject new clients' flag on during the import would cause issues? I should mention that after having to restart the AOS, we do not check off the 'reject new clients' flag but rather proceed with the CIL compile with the flag off.
And yes, we're looking into adopting the recommended deployment approach by MS.
Thank you in advance for any help provided.
The best is to do the deployment and possible compilation (p-code or CIL) with no users in it.
When you allow users, they can access forms and enter data, but several business logic is not updated yet in .net code, so it will execute wrong coding if the CIL compilation has not been completed.
So my suggestion would be: First ensure compilation is correct, then have users allowed to access the environment.
André Arnaud de Calavon | Microsoft Dynamics AX Solution architect | My blog | My company
This post is my own opinion and does not necessarily reflect the opinion or view of my company, Microsoft, both its employees, or other MVPs.
My understanding has always been to keep users from logging onto the server(s) while the deployment is underway. My question is using the 'reject new clients' the proper way to go about it? As I mentioned, we often experience issues during the import process which crashes the client, and I'm left wondering if the 'reject new clients' flag could be causing the issue.
May I ask how you guard against users from logging into the system during a deployment? Do you simply use the 'reject new clients' flag on each AOS? A script which disables all users? Restrict access via the Terminal Server?
Thank you very much!
In my opinion, the "reject new clients" option isn't related to the client crash.
About deployment customizations on Production env, to avoid any issues, you should :
1- Stop all AOSs and leave one only for the deployment
2- Use the "reject new clients" option
3- Import XPOs
5- Compile Incremental CIL
6- If a terminal server sessions, delete the auc users local files
7- Start other AOSs
8- Use the "Accept new clients" option
Thanks & Regards
Respect the provided answers from other community members. Don't provide or do not copy the same answer to the same thread. Additional insights are welcome!
In addition: I have no customers who are doing the deployments using xpo files. In addition you should find a certain maintenance window. Usuallyma weekend or evening is used. This will be different if you have a 24/7 business.
If you prepare from the acceptance or staging environment a compiled model store, the downtime is quite small.
Thank you for the detailed steps. There are some steps I think well worth looking at for our deployment process.
If I may, I'd like to ask for some details on how #6 is accomplished. We do utilize terminal server sessions across multiple instances. So is your suggestion then to go to each server, and clear up the AUC files for every user in the 'users' folder? I believe we use roaming profiles so the actual VHDX files are kept on a different server. If you could offer some additional details, I'd appreciate it.
Yes, we unfortunately are a 24/7 operation and do carve out times during the evening when there is the least amount of impact. It's also unfortunate that we're still using the XPO method to deploy code but I have done limited testing with good results in our test environment using model stores. It's now a matter of implementing this new process. For the short-term we're still using XPOs.
Thank you for your input.
Check these links:
Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments (www.microsoft.com/.../details.aspx)