I have been struggling with determining what is causing such sluggish login speeds whenever we log into AX 4.0, but have yet to determine the cause. I have had MBS support working with me on it, after much of my own troubleshooting combined with their troubleshooting suggestions and even as going as far to Profile the SQL server activity during the login period, a cause has not yet been determined.
Our development environment consists of two Dell servers, both running Dual Xeon 2.8s or higher, with 2GB of memory, both on GB ethernet, both Win2K3Ent. One server is a Development DC and SQL Server and the other server is an AOS/Terminal Services server. Either logging onto the AOS/TS and launching AX or logging onto the SQL/DC server and launching AX yields between 13 to 15 second login times. If I install the client directly onto my notebook (P-M 2.26 2GB RAM, 100Mbps eth XPPro) and login, same speed 13 to 15 seconds. I realized this morning after setting up dedicated 'Batch Server' from a Dell Optiplex P3 500 with 256MB RAM, also on 100Mbps eth (same switch as my notebook), and running Win2KPro, that the slowness couldn't be resource related because the Batch Server logs in within one to two seconds max.
This seems to me like it's an issue with AD and maybe the backwards authentication capability of a Win2KPro box onto a Win2K3Ent domain is different since WinXPPro and Win2K3Ent would logically have the same provisions for authenticating on a Win2K3 domain. I guess I'll have to wait and see if MS has any idea as to what the problem relates to with the addition of this new information. Is anyone else experiencing this long of login times? It's not 'crucial' for the login times to drop since a typical user will only login to AX once per day, but still it would be nice to shave at least half of that time off, but now that I know it can login between 1 to 2 seconds, that would be ideal to achieve.