Sunday, October 28, 2007

Troubleshooting Long Login Times and Performance Issues in Great Plains

We faced this problem specifically for GP 9.  We tried a host of steps, then created a support ticket, submitted information log and trace info to Microsoft, and what actually fixed it was - moving to the latest service pack.

I'll put the information here - in case somebody finds it useful.

1 Check that you are running the latest service pack for Great Plains AND MSSQL.

I was used to ignoring this, and "Apply the latest windows updates" suggestion. But sometimes, this is the only thing that fixes things.

2 Check if tracing is turned on for all ODBC's

If tracing is enabled - there will be a sql log file created that would record every ODBC call that is made to any application that uses the ODBC drivers. Therefore the application is slowed.

To check the setting, click Start | Settings | Control Panel | 32bit ODBC | Select Tracing tab.

3 Check if a Dexsql log is accidentally on

Open the Dex.ini file that exists in your Great Plains application folder in Windows Explorer. Find and confirm the following statements in the Dex.ini file:




4 Turn off Home Page Display and check login time

Specifically the metrics and outlook section can be slow

5 Turn off security from Reminders and Check login time

Dynamics GP >> Forms >> System >> Reminder

6 Run profiler and review queries fired during startup

7 Are any anti-virus softwares installed on the system?

If the issue replicated only on machines that have the anti-virus

8 Can you reproduce the performance issue on all the computers?

This would identify if this is a machine related problem

9 Specifically, can you reproduce the performance issue when you are sitting directly at the computer that is running Microsoft SQL Server?

This would identify if you have network problems

10 Are there any physical symptoms on the computer that is running SQL Server? For example, is processor usage at 100 percent? Is the processor light on? With How many users do you face this problem ?


..::വഴിപോക്കന്‍[Vazhipokkan] | സി.പി.ദിനേശ് said...

Hi Jivtesh ,

Its a great help for me to resolve the login delay. I installed the latest GP service pack and login time was reduced drastically.

Thank you.

Jivtesh Singh said...


Glad i was of help! Take care!


Anonymous said...

I have a similar issue. I was running GP v8 on a SQL2000 server. I upgraded to v9 and also moved to a SQL2005 64-bit server. All the ODBC connections to the server run much slower. I have connections from numerous applications besides MS Access. The SQL2005 64-bit is on a W2003 64-bit server with 4 CPU's and 8gb memory. Plenty of hard disk space and only 15-users. I am not sure where to look for help. I sent ODBC traces to MS when we first converted and they saw nothing.

Anonymous said...

I had a number of workstations (XP, Win2k) on an AD network which took more then 10 minutes to get to the login screen... tried all the suggestions above and then some. Once logged in GP 9 is fast, no other issues.
The solution for me was to delete the affected user profiles. Once this was done all the login screen appear in 2 to 5 seconds. With saving/restoring the profile directories of my documents, favorites, desktop,and start menu, took approx. 30 minutes per machine.

Mike Lupro said...

I had this issue where the users were in one city/domain and the terminal server was in another city/domain.

The issue was caused by a mapped drive auto-started by the system policies (so ALL users could share in a common Accounting file share).

The users in City B/Domain B had LONG log-in times. Solution was to create NEW GP-ONLY log-in ID's to the terminal server where the Policy did not auto-set the mapped drive.

GP creates some type of directory on a server in Domain B that then GP tries to constantly update (or something like that). If someone has this issue I can probably dig into my notes and help.

Mike Lupro - MikeLupro@BestTechsNW.com