Increasing Password Attempts in Dynamics GP (and What to Consider Today)

If you’ve ever been kicked out of Microsoft Dynamics GP after fat-fingering your password three times in a row, you’re not alone. It’s one of those small annoyances that has tripped up GP users for years—especially first thing Monday morning, coffee still brewing.

The good news: this behavior is configurable. The better news: before you change it, it’s worth thinking about why that limit exists in the first place.

The quick fix: edit your Dex.ini file

Dynamics GP stores a number of client-side preferences in the Dex.ini file (typically found in the Data folder of your GP installation). Open it in a text editor and look for—or add—this line:

SQLNumLoginTries = number

A few things to know:

• The default value is 3.

• Setting it to -1 gives users unlimited attempts.

• You can also set it to a specific higher number (say, 5 or 10) if you want a middle ground.

Save the file, relaunch GP, and the new limit takes effect.

What this setting does not change

This is an important point that often gets missed. SQLNumLoginTries only controls how many times the GP client will let you retype your password before closing the application. It does not override:

• SQL Server login lockout policies

• Active Directory account lockout thresholds

• Any password complexity or expiration rules set at the domain level

So if your SQL or AD policy locks an account after 5 failed attempts, that lockout still applies—regardless of what your Dex.ini says. Setting SQLNumLoginTries = -1 just keeps GP from closing on you; it doesn’t give anyone unlimited cracks at a password.

Should you actually change it?

In 2012, when this tip first made the rounds, bumping the limit was a common quality-of-life tweak. In today’s security landscape, the answer is a little more nuanced.

Reasonable cases for raising the limit:

• Users juggling multiple complex passwords across systems

• Shared workstations where typos are common

• Reducing help desk tickets for “GP keeps closing on me”

Reasons to leave it alone—or even tighten it:

• You rely on the GP-level limit as a defense-in-depth control

• Your SQL/AD lockout thresholds are already generous

• You’re working toward stronger authentication standards (MFA, SSO, conditional access)

The bigger picture: if users are routinely hitting the password retry limit, that’s usually a signal worth investigating. It often points to password fatigue, outdated credentials, or the need for single sign-on rather than a configuration tweak.

Looking ahead: GP, Business Central, and modern authentication

Microsoft has made it clear that the future of its ERP roadmap centers on Dynamics 365 Business Central, with mainstream support for Dynamics GP winding down. Business Central handles authentication very differently—it uses Microsoft Entra ID (formerly Azure AD), which means MFA, conditional access, and modern password policies are built in. The whole concept of editing an .ini file to tweak login behavior simply doesn’t apply.

If you’re still running GP, this Dex.ini tip is perfectly valid and useful today. But if password headaches are a recurring theme for your team, it may also be a small nudge to start thinking about your longer-term ERP strategy.

Need help thinking through what’s next?

At eIS Business Solutions, we work with finance and operations leaders every day to evaluate where their ERP fits today—and where it should be heading. Whether you’re optimizing a long-running GP environment or planning a move to Business Central, we can help you make the right call for your business.