Login Problems

[Borvik]

GP 7.5 -> SQL Server 2000.

For some reason or other I am unable to log in to GP on my computer - no matter the login, I've tried my login, the administrator login, etc...

The same logins work perfectly on the machine next to me - just not my machine!

I am however able to connect the server using SQL Server Management Studio with the same logins that don't work in GP.

I suppose it could be a DSN issue, I'll try recreating that.

 

[Borvik]

I recreated the DSN and that does work. I didn't change the other one, and the look identical (except for the names) - the Test Data Source works for both as well, yet one doesn't work.

Oh, well - working now.

 

[Borvik]

Ok, this is weird. I'm still logging in, but I'll throw this out for anyone who might know what is going on.

I deleted the old DSN that wasn't working, and then renamed the one that was to match the old name.

Tried logging in again - and it failed. So I deleted all the DSNs and recreated the DSN - using the name "Great Plains" - I couldn't log in.

So I went in and removed the space in the name changing it to "GreatPlains" and it worked, I could log in. Apparently the name of the DSN was causing problems. That doesn't make much sense to me, but that is what it appears to be. By the way I'm using Vista: Business - if that helps anybody understand the problem more.

 

[VictoriaYudin]

Um....did I read this right and you're running GP 7.5 on Windows Vista? In a production environment? Let me just leave it at, 'I wouldn't.'

Victoria
Flexible Solutions, Inc.

 

[Borvik]

Yea, well - we are in a transitionary phase - attempting to upgrade to GP9.

 

[jazgeek]

I had a similar problem to this a long while back on a 2000 machine... I had to dig through the registry to delete references to the dsn entry. then a recreation worked



-----------
and they wonder why they call it Great Pains!

jaz

 

[Borvik]

*love* the registry. In theory and in most situations its a good idea, but sometimes it is just the source of many problems.

It's working now (didn't play with the registry) and as long as it stays working I'll be happy.

Just kicking out thoughts ideas to possible help others in the future.

 

[barbola]

We have this problem on all of our workstations. Even when we verify the DSN settings are the same, the only machine that a user's login will work on is the one that resets the password - so I have to sit at their machine, log in as 'sa' and reset their logins.

We have too many workstations to go through and do the registry thing you mention...but what would be the instructions to do that again?

 

[winthropdc]

FYI: There is a known issue with v9.0 and passwords.

The encryption used for v9.0 passwords is different to previous versions. This means that v9.0 will request users to change their password when they first login after an upgrade.

The issue is that the encryption algorithm uses the User ID as part of the encryption key. But the User ID is not wrapped in an UPPER() function, so it is case sensitive.

What this means is that if a user logs in as Fred and sets their password. They must now always login as Fred. FRED or fred will not work as the encrypted password sent to SQL will be different and the login will fail.

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer - Great Plains
Microsoft Dynamics Support - Asia Pacific

Microsoft Dynamics (formerly Microsoft Business Solutions)

http://www.microsoft.com/Dynamics

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[barbola]

David, this is the same response I have seen before but it doesn't explain the workstation issue. We were told to make sure the DSN settings were identical, and on a few workstations I have done this but it still doesn't allow another user to log in unless their password is set on that workstation by 'sa'.

I have only been able to synchronize one userid/password on two workstations. We have 45 users and about 25 workstations and no time to run around checking DSN settings.

I don't believe this has anything to do with the case of the userID.

 

[winthropdc]

I saw an issue recently which was about logins and DSN. At this stage the cause had not been identified, but creating a new DSN allowed the login to work.

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer - Great Plains
Microsoft Dynamics Support - Asia Pacific

Microsoft Dynamics (formerly Microsoft Business Solutions)

http://www.microsoft.com/Dynamics

Any views contained within are my personal views and
not necessarily Microsoft Business Solutions policy.
This posting is provided "AS IS" with no warranties,
and confers no rights.

 

[RobertC22]

I have also encountered this bizarre situation for one workstation.

Even creating a different DSN did not resolve the issue.
For that user, I too had to log on to his workstation, then into DynamicsGP as 'sa' to set the password. His DynamcisGP userid was then only useable on his machine.
This was regardless of the network account I logged onto the machine as.

In testing, the sql login password was reset using SQL-EM. DynamicsGP identified this and asked to change the password at logon. Changing the password was successful, but only useable at that workstation.

This workstation was no different in anyway for Operating System (Win XP sp 2), registry settings or permissions or anything software that could be reviewed.

------
Robert