web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics GP (Archived) / GP 2010 "Login Fa...
Microsoft Dynamics GP (Archived)

GP 2010 "Login Failed" on Windows 7 32bit Xendesktop

(0) ShareShare
ReportReport
Posted on by ChrisMac 140

I am currently attempting to deploy GP 2010 on a Windows 7 32 bit XEN desktop. Everything installs flawlessly but when attempting to login I am being told "This login failed. Attempt to log in again or contact your system adminstrator." I can use the same login from a non-Xen desktop and get right in. The GP is set to use the SQL for authentication. Is there something that I am doing wrong in the installation or do I need a patch for the Xen environment to recognize the login credentials? Any guidance would be greatly appreciated.

 

Thank you!

Chris

*This post is locked for comments

I have the same question (0)
  • Community Member Profile Picture
    Community Member on at

    Can you log in to GP using the 'sa' account from Xen apps? If so, then set up a new user in GP and try that.

    If not, then check your ODBC set up.

    Is it SQL Native Client?

    Are all tick boxes ticked off?

    When you log into th ODBC as 'sa' do you get past the login window?

    Ian.

  • ChrisMac Profile Picture
    ChrisMac 140 on at

    Ok the sa account works fine and I can log into the GP on the Xen desktop, we are using SQL native and the ODBC is setup correctly we tested it. I can get all the way in and pull up accounts under the sa loggin. However there are some end users who cant seem to log in. I wont have to create new accounts for all the users who cant get in will I?

  • Suggested answer
    Aaron Donat Profile Picture
    Aaron Donat on at

    Chris,

    this sounds like it has nothing to do with your deployment or software you are using.  If the 'sa' account can log into GP, then the client, ODBC and SQL are functioning just fine.  The issue sounds like regular users can't login using this machine.  So to me...it sounds like there is a password encryption issue. You need to verify that the ODBC DSN name is spelled the same across all machines that use Dynamics GP. The ODBC DSN name is part of the encryption key for the end users password.  So if on there machine, the ODBC DSN name is "Dynamics GP" and the ODBC DSN name on your Xendesktop machine is named:  "Dynamics GP 2010", then the encryption applied to the end users password will be different and the user will not be able to login.

    Get the DSN names the same, the end users password reset (if the DSN name changed) and then give it a try.

    Thanks!

    Aaron Donat

    Sr. Escalation Engineer

    Dynamics GP

  • Suggested answer
    Community Member Profile Picture
    Community Member on at

    I needed to make sure, in the ODBC connection setup, I was specifying the IP address of the server rather than the server name.  Didn't have this issue in v9, but GP 2010 is now a virtual server ... and that's likely why.  Other than that, make sure all boxes are unchecked, and use sa for the ODBC.  The only other thing was I needed to essentially reset everyone's password in our dev environment because the passwords didn't transfer over from the backup/restore from production.

  • Community Member Profile Picture
    Community Member on at

    I'm pretty sure you can use either the server name or IP address in the ODBC (Aaron - can you confirm that there is no reason why you can't use IP?) - as long as its the same on all workstations - either all IP or all server name. Ideally you should use a System DSN everywhere (the User DSN will work - but can cause issues with the advanced SQL options (on the GP user set up window). If users can't see the System DSN you set up - grant security rights to it under regedit.(do a search for all instances of the System DSN name in the registry- right click it and select security...and grand full read/write access to the user group).

    There is a script you can download to capture the SQL logins when setting up your test environment - but the user passwords will always have to change because the server name changes. Just set them all to 'Password1' and select 'Change password at next login'.

    Ian.

  • Community Member Profile Picture
    Community Member on at

    Hi Ian.  Very informative post.  I have 3 remaining employees to set up with ODBC, so I'll change their passwords to something basic and force a reset upon initial login... good idea.  

    I am not 100% sure why the server name did not work.  Both Production and Dev are residing on virtual servers, so that debunks my initial theory.  Without changing any other settings in the ODBC setup (except server name vs. IP address), it gives the basic "Login failed..." error.  If I change back to the private IP of the server, it works.  Change back to server name and try same login/pass, it fails.  So odd, because Production works just fine using server name ... but as far as I know, GP 2010 set up the initial ODBC upon installation, and it's using SYSTEM instead of 'sa'... that might be the answer there.  I don't know what password SYSTEM uses, so I was unable to test using that login in dev.  

  • Community Member Profile Picture
    Community Member on at

    I experienced this exact problem in GP2013 R2.  Using KB919345 I followed these troubleshooting steps:

    1. Verify the user has a SQL login.  (SELECT name FROM master.sys.sql_logins)

    2. Verify the user is not locked out of SQL database.

    3. Verify the user is mapped to DYNAMICS and company databases.

    4. Verify the user can login directly on the SQL server.

    5. Verify the server name on the ODBC configuration is the same on both the SQL       Database server and the client machine.  

    The source of our issue was #5 because one ODBC used FQDN for the server name and the other did not.  We modified them to both use FQDN and the problem was resolved.

    Joanne Herzog, Programmer/Developer

    Dynamics GP

    Grant County PUD

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

#1
mtabor Profile Picture

mtabor 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans