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.
9 comments:
The strangest thing is the other day I opened up AX, just as I had done for many times before and it near-instantaneously logged on. I figured maybe the problem somehow resolved itself, however once I logged out and logged back on, I got the same familiar 13 second log on time.
Now my AD is on the same box as my SQL Server and my TS Server is sitting on the same box as my AOS, maybe that's somehow contributing to the extra 3 to 5 second latency I am getting compared to your setup.
I am getting two additional Dell 1750 PEs early next week. One will become a dedicated DC, and one will become a dedicated TS server so that I will have a truely 3-tier setup versus the current 2-tier setup. I figure that should speed up login.
I'm new to Dynamics AX and we just installed a test server and are working with a vendor. The configuration is as follows:
1 Server running Windows 2003 SP1 - Running as Terminal Server, Dynamicx AX 4.0 Application Server, and SQL Server 2005. I know that this is not an ideal configuration and the production environment will be much different.
However, we are also experiencing the slow login issue with any new accounts that we create in Dynamics AX. However, the user account that was used to install MS Dynamics and SQL Server 2005 logs in quickly. One may think that it is then a rights issue, but an equivalent account that we add as a Dynamics AX user that has Domain Admin privileges (hence local Admin privs on the server)also has the slowness issue.
Today I copied the user profile from the user account that has a fast login to other accounts and voila fast login for anyone that I copy the profile too.
My assumption is that something must be written to the users profile when installing MS Dynamics AX4.0 that allows for the fast login.
The server is an HP Proliant DL380 - Dual Xeon Processors with 2GB RAM. There are 2 AD servers on the same LAN for authentication.
We are seeing anywhere from 20-30 second delay after double clicking on the Dynamicx AX icon before the application is fully loaded. After copying the profile from the user that installed Dynamics the application opens instantaneously.
Now we need to find what in the original users profile is actually required.
Well, we are getting close to determining the slow login times. It appears that the AX32.exe program makes a query to the Documents and Settings\Application Data\Microsoft\CryptnetUrlCache\Content and MetaData directories for a file called "A44F4E7CB3133FF765C39A53AD8FCFDD". This file and actually directory structure is missing for most of our new users that are connecting via Terminal Services. If I copy the \CryptnetUrlCache directory and files to the users profile....AX32.exe responds quickly.
Both Microsoft Dynamics and the Windows team are looking into this for us.
-Chris
Hi Dave!
We have the same issues here. I just checked that mysterious file and it seems I have it on my PC. Did you get any answer from MS?
Best regards, Helmut
http://axaptafreak.blogspot.com
Hi David,
I don't know what the situation is right now, but we were having the same problem. However one of the technical guys found out that it has something to do with the AD.
In properties of MyComputer there is a tab UserProfiles. He deleted the Global\ ones and after that the problems were over. The userprofiles were created again and now I have a loging time of a split second.
regards
Jan
Hi Guys!!!!
I also have the same problem...
I copied the Magic Files and it still was not working properly... BUT, I enabled internet connection on the server and it went from 15 seconds to 1 second to startup the Client...
I dont know exactly why does it need the connection but it solved the issue... I'll do some more tests on this.
Best Regards,
Pedro
pyramyd@gmail.com
Hi again...
More discoveries...
I've disconnected the server from internet, tried again and it still works fast...
Apparently is validating the Magic files, because I also noticed that they were modified when I started Dynamics client with internet connection. I also copied the files to other servers and it kept working OK...
So I copied the files to the Default user on the servers in order to propagate the effect to the rest of the users when they login and their profile is created...
Well... that's all for now.
I've been struggling to find out what was going on... so I'm VERY happy about this 'solution'. But I also think that Microsoft should provide a solution for this and add a note on the manuals for further reference.
Best Regards,
Pedro
pyramyd@gmail.com
The Magic Trick is
Shut down DAX.
Go into IE, select Tools|Internet Options|Advanced
If “Check publisher’s certificate revocation” under the security node is checked, then uncheck it.
Now try DAX again.is it faster?
Regards,
Subha
Just Shut Down the DAX Client.
You need to do this for every client machine.
Regards,
Subha
Post a Comment