Scenario: A client has multiple AOS servers in their environment and you, as the system admin, have set up their cluster configuration in a way so that all of them are well-utilized. Some of the AOS servers are set as 'Load Balanced' which users will hit with their AX clients to spread the load, while others are set to 'Non-Load Balanced' and used as dedicated batch servers. (see Dynamics AX 2012 Cluster Configurations)
This client is also using Enterprise Portal. Perhaps for time and expense, purchasing, etc. However, periodically they see random timeouts, Error messages, etc. Some times a page will work, but when they click a button or refresh their view, suddenly an error appears or 401 web error.
One possibility is that your Enterprise Portal instance is pointed at a Load Balanced AOS server in your cluster. EP points to ONE AOS server, and that is defined at EP install time. Many times during installation of EP, installers will point at AOS 1. And often times, AOS 1 will be a user server (Load Balanced). Enterprise Portal does not like being pointed at a Load Balanced server. What we have found is that when EP is installed pointing at a server that ends up designated as Load Balanced, is that a user may be able to open a web page just fine at first in EP, but when they click somewhere or refresh, suddenly there is an error. We believe this is due to EP hitting a load balanced server when page is opened (AOS 1), then a button is clicked or refreshed and it ends up getting AOS 2 on that next call to AX (load balanced, remember?). EP gets confused and doesn't remember where it started from initially, then gives up.
Upon install of EP, point it specifically at a server you know will be a Non-Load Balanced server in your cluster configuration. This will avoid the problem. If EP is already pointed at a Load Balanced server, you can either move around the cluster configurations for that AOS, or need to reinstall EP.
Many thanks for your post. In an AX 2012 customer environment with active Enterprise Portal / Role Center, we suffered from long wait times, followed by script errors, in list pages. This started after we put our first AOS into a cluster with a new second 2. After dis-solving the cluster, the problems disappeared again.
ReplyDelete