Your GP databases have moved, but users cannot sign in. Before resetting every password, confirm what changed and which accounts are affected.
A server move can require password resets, but connection settings, transferred logins, and database access also deserve review. Identifying the cause first helps your administrator restore access without making unnecessary changes.
Key Takeaways
- Moving GP to a differently named SQL Server can affect user passwords.
- Investigate connection and account issues before resetting users in bulk.
- Test the reset process and validate access before completing the cutover.
Why Can GP Passwords Stop Working After a Server Move?
Microsoft explains that GP user-password encryption depends on the server name used in the ODBC connection. Moving to a server with a different name can therefore require users’ passwords to be reset.
That does not establish the cause of every sign-in failure. Record the exact error and review the migration before choosing a fix.
Check the Scope of the Sign-In Problem
Start by identifying who is affected and where the failure occurs.
| What you observe | What your administrator should investigate |
|---|---|
| One user cannot sign in | That account’s credentials, status, and access |
| Multiple users fail after a server move | Connection settings, transferred logins, and password-reset requirements |
| A user can sign in but cannot access a company | Company access and database-user mapping |
| A user can open GP but cannot perform a task | User type, security roles, and configuration |
| One workstation fails while others work | Differences in its GP client and connection configuration |
Record the GP version, affected environment, server connection, error text, and recent changes. This information gives your support team a useful starting point.
If your environment uses Dynamics GP Service Based Architecture, include its authentication and integration requests in post-move testing.
Prepare Before Resetting Passwords
Have your GP administrator or partner confirm:
- Whether the work affects production or a test environment.
- Which users require a reset.
- Whether logins and company access were transferred correctly.
- That current backups and a recovery plan are available.
- How temporary credentials will be delivered.
- How users will confirm successful access.
Microsoft recommends testing its server-transfer procedure before performing it in production. Its guidance covers databases and logins as well as password resets.
If the move involves a hosting provider, establish who owns these tasks. Review these Dynamics GP hosting questions before scheduling the cutover.
Reset an Individual User’s Password in GP
For the server-move scenario described in Microsoft’s guidance, an authorized administrator can reset a user’s password through GP:
- Sign in using an account authorized to administer GP users.
- Open Microsoft Dynamics GP > Tools > Setup > System > User.
- Select the affected user.
- Enter and confirm the new password.
- Save the change.
- Have the user test access to the intended environment.
Confirm the procedure and password options for your release before proceeding. Microsoft’s GP server-transfer instructions provide additional technical context.
Need Help Restoring GP Access?
Bring the error message, affected user list, and details of the server or environment change. LBMC Technology Solutions can investigate through its Dynamics GP support and maintenance services.
What About Resetting Multiple GP Users?
A larger environment may justify automation, but the method needs to match the GP release, account configuration, and administrator’s intended scope.
Before using a macro or script:
- Define which accounts it should include and exclude.
- Review how it handles temporary passwords and password policies.
- Test it with a small, representative group.
- Confirm how failures will be identified and resolved.
- Protect any files containing credentials and remove them when no longer needed.
A published script should not be treated as validated for every GP environment. Ask your partner to review and test the approach before using it for a production reset.
Validate More Than the Sign-In
Once users can sign in, confirm that they can access the appropriate companies and complete representative tasks.
A successful password reset does not confirm that company access or security permissions are correct. Review Dynamics GP user types, licensing, and security access when a person can enter GP but cannot complete their work.
Where applicable, include these processes in post-move testing:
- Opening required companies and reports.
- Entering and processing representative transactions.
- Running scheduled integrations.
- Submitting and approving workflow items.
For teams using file imports, test the process for importing journal entries with Integration Manager.
If notifications or approval actions fail after access is restored, investigate them separately using these GP workflow email troubleshooting checks.
Dynamics GP Password Reset FAQs
Does every GP server move require all passwords to be reset?
Do not assume so. Have your administrator review the server names, connection configuration, and migration method to determine which accounts require changes.
Should we change GP user passwords directly in SQL Server?
Use a procedure confirmed for your GP environment. GP applies its own password handling, so a general SQL Server password change should not be assumed equivalent to a GP user reset.
Will resetting a password fix missing company access?
Not necessarily. Company access, database-user mapping, and security permissions may require separate investigation.
Can we use the same reset process in a restored test environment?
Confirm the procedure for that environment. Clearly identify the test system, control access, and review connected processes so testing does not affect production operations.
Ready to Resolve Your GP Sign-In Issue?
Tell us what changed, which users are affected, and the error they receive. We can discuss the investigation and support needed to restore access.
