[SIMS] New SIMS install not letting users log on

[Number6]

Hi all.

Everything seems to be going awry at the moment and the jobs keep piling up!

New SIMS server - brand new hardware, Server 2008. We're migrating our existing SIMS setup to the new server.

Our DB manager installed SIMS onto the server and migrated the database. SQL was installed from the Capita disk. We had the devils own job getting it to work but eventually we did after a day and a half of solid work and hair pulling!

We've set up two workstations to access the new server. The problem is this:

No one can login. We get as far as the username and password entry screen but every attempted login is rejected with a "user unable to login, reason 0 (zero)". This happens for any user including sysman.

If we work directly on the server then any user can login as a user and SIMS works flawlessly, so it doesn't appear to be a server or DB issue.

We have raised a support issue with capita which is still open. We've tried their first recommeded set of fixes to no avail. Capita are now head scratching.

The workstations have had all traces of previous SIMS installs removed, firstly via add/remove progs and then a manual deletion of any remaining folders. This is followed by a registry clean, a reboot and a further registry clean before reinstalling. So we're fairly sure there are no remnants of connect files or any rogue registry entries. We've tried all this twice now. All appropriate network drives and connect files point to the right place.

Does anyone have any ideas we can try? I really need to get this fixed today as I'm on holiday for two weeks after today.

Thanks all.

[matt40k]

Few thoughs:

Check sims.ini, make sure setups is point to the new servers setups
Make sure the user has access rights to the s drive (sims share)
Make sure the firewall is opened up. (MSSQL,HTTP:8080(DMS),File sharing)
If you installed MSSQL 2005 standard\enterprise, enable TCP\IP
Checking the connect.ini (c:\program files\sims\sims .net\connect.ini)

[Number6]

Hi Matt

Sims.ini has all the correct settings as far as I can see.

Permissions should be fine because the workstations in question ran sims happily before, and if I change the network drive back to the old sims server the WS can access it just fine.

SQL was installed from the Capita disc as part of the SIMS setup, we didn't use any other instance of SQL.

My only other thought is that SQL permissions may be wrong but how do we check or change this on the Capita install?

[Ian_ICTDS]

Hi 6

Detaching and re-attaching the database using DBAttach usually re-creates the SQL users if something has gone wrong with the migration. Might be worth giving that a go.

Ian.

EDIT: Just noticed you said everything's fine on the server so DBAttach probably won't make a difference. Sorry. Might be still worth having a go though.

[Number6]

Hi Ian

We did that yesterday to no avail.

I don't anyway think it's a sims user problem per se, users can log into sims if they're working directly at the server, just not from a workstation.

[Ian_ICTDS]

Hmmmmm. I often find problems like this are down to the Connect.ini files on the workstations.

Do the clients PCs local connect.ini files (C:\Program Files\SIMS\SIMS .net) point directly to the server eg:

[SIMSConnection]
ServerName=SIMSSERVER\SIMS2005
DatabaseName=sims
DatabaseMode=OnLine
CommandTimeout=1000000

Or do you have a redirect:

[SIMSConnection]
Redirect=S:\sims

If you have a redirect, changing the path to a UNC path can sometimes help. Also worth checking that the connect.ini that the redirect is pointing to has the correct details.

If you don’t have a redirect and have the server details written in then check if they are correct. It should be in the format above.

Good luck.

Ian.

[Wils86]

ohh i might now why it aint working, before i left my work i shifted sims on to our new 64 bit server 2008 server. (almost went on a murderous rampage by the way) What i found was one or two people could log on so try every one with admin rights.

What happened is when you dettach and reattach a database sometimes, a user password is reset to the default one you get when you first register a user. You know the kind, goes like THDIBWIW3J or something like it.

If you can get in you'll find most peoples passwords have being reset. sorry Im not more helpful.

[Number6]

ohh i might now why it aint working, before i left my work i shifted sims on to our new 64 bit server 2008 server. (almost went on a murderous rampage by the way) What i found was one or two people could log on so try every one with admin rights.

What happened is when you dettach and reattach a database sometimes, a user password is reset to the default one you get when you first register a user. You know the kind, goes like THDIBWIW3J or something like it.

If you can get in you'll find most peoples passwords have being reset. sorry Im not more helpful.

We're aware of this and tried all the new and old passwords.

Same result - can't login, reason 0

[Number6]

Hmmmmm. I often find problems like this are down to the Connect.ini files on the workstations.

Do the clients PCs local connect.ini files (C:\Program Files\SIMS\SIMS .net) point directly to the server eg:

[SIMSConnection]
ServerName=SIMSSERVER\SIMS2005
DatabaseName=sims
DatabaseMode=OnLine
CommandTimeout=1000000

Or do you have a redirect:

[SIMSConnection]
Redirect=S:\sims

If you have a redirect, changing the path to a UNC path can sometimes help. Also worth checking that the connect.ini that the redirect is pointing to has the correct details.

If you don’t have a redirect and have the server details written in then check if they are correct. It should be in the format above.

Good luck.

Ian.

We use a redirect to a mapped drive.

I'll try playing with UNC paths, I haven't tried this yet although I have to admit I was contemplating it.

Thanks, I'll have a play now.

[Number6]

Nope

Changing connect.ini to a unc path made no difference.

[Ian_ICTDS]

Next I would try putting the server details directly into the local connect.ini rather that an redirect just to completely rule that out.

After that I would install SQL Management Studio Express from the Microsoft website on the workstation. Then use that to log into the SQL server just to see if you’ve defiantly got SQL connectivity.

Ian.

[Mcshammer_dj]

on the server

go to SQL 2005 and check that the surface configuration is set to allow remote access to the server

[Number6]

Next I would try putting the server details directly into the local connect.ini rather that an redirect just to completely rule that out.

After that I would install SQL Management Studio Express from the Microsoft website on the workstation. Then use that to log into the SQL server just to see if you’ve defiantly got SQL connectivity.

Ian.

Done the server details, no difference.

Trying the SQL Management now.

[Ian_ICTDS]

Good luck. If SQL Management Studio can’t connect you usually get a decent error message to investigate.

[Number6]

on the server

go to SQL 2005 and check that the surface configuration is set to allow remote access to the server

Yep, remote access by TCP/IP (not named pipes) is enabled.