
Hi, at this moment were busy with setting up a new RDS enviroment based on Server 2012R2 and were dealing with a performance issue with the AX client. The first time that the client is started it takes about 60 seconds, if I close the client and start it again it's starting fine (normal behavior I suppose).
The current RDS enviroment is a Server 2008R2 and on this one the client always starts fine and fast, never see a Not Responding message or whatsoever.
The servers are running on the same VMware hosts with the same storage / LAN / etc. components. Can anyone tell what I can do on the new RDS enviroment to troubleshoot this?
Regards,
Michiel Dekker
SCCT
*This post is locked for comments
I have the same question (0)Identifying the root cause of such issues are very complex to troubleshoot without knowing your specific hardware/software/setup.
You can set up RDS in 2 ways, Virtual machine-based or Session-based. We went with the second option and do not experience any issues or slowness, how did you deploy yours? We are also using an SQL Server DB-based connection broker. Our AX shortcut is shared with an AXC file, and in the configuration we are listing available AX AOS instances. In the AX setup we have created a server cluster for the user clients, and it distributes the connection load without a dedicated load balancer AOS.
If your setup is similar, you have done it correctly. If not, revise what and how have you configured, because Windows Server 2008 and 2012 are quite different for RDS setup.
If your configuration is right, then maybe you have some group policy enforcement, or login scripts which are running when a user "signs in" (just starts the RemoteApp) that slows down the process. Or maybe your hardware is not up to speed and you do not have enough resources. We have noticed that sometimes the Print spooler service takes enormous amount of resources away (high CPU), and then AX slows down, due to most likely a bad printer driver.
Maybe you could have a look with some resource monitoring tool to have a look what is happening or what's different (SysInternals has some). Also monitor SQL Server and AX AOS load while only a single session is connecting. Maybe you could even capture an AX Trace to look deeper.