Ghosts in Solus when doing Spring 2010 upgrade

[tech_guy]

I've got ghost users showing in 'information about your system' when using Solus 2. I thought this problem had been sorted? All the clients are shutdown so I know it's the ghost users problem still. How do I get rid of them - I can't remember?! The database upgrade tool can't lock the database because of them.

 

I'm doing the Spring release remotely - being 25 miles away from the site is a bit of a problem!

 

Many thanks!

[Cache]

I think when we had this, the only way to solve it was a server restart.

 

Whether restarting the SQL services will achieve the same result or not I don't know.

[tech_guy]

Thanks for the suggestions - I did a server restart but bizarrely they were still there. Stopping the SQL services had no effect either. I'm flummuxed!

[glennda]

Theres a way to force all users out, let me see if i can dig out the thing i get sent over from our support team.

[Sivadam]

Check out how to use Single User Mode. See 'KB88695 - How to force Users out of Sims.net' via SupportNet.

It does refer to SQL Server 2005 but is still relevant to SQL Server 2008!

Edited May 18, 2010 by Sivadam

[glennda]

Check out how to use Single User Mode. See 'KB88695 - How to force Users out of Sims.net' via SupportNet.

 

This is the one i meant.

 

There is also another thread about this http://www.edugeek.net/forums/mis-systems/52151-force-logout-sims.html

[Sarconia]

It does refer to SQL Server 2005 but is still relevant to SQL Server 2008!

 

KB96140 for SQL Server 2008, it's effectively the same process, just that it looks different to 2005.

[vikpaw]

Be careful though, as depending on how you do remote access, you might not have permission to do the upgrade if you limit it to local users only. I'm sure i had problems as a remote session wasn't considered local.

Better to use something that replicates you being at the console, like a network accessed KVM or logmein . . .

[tech_guy]

Be careful though, as depending on how you do remote access, you might not have permission to do the upgrade if you limit it to local users only. I'm sure i had problems as a remote session wasn't considered local.

Better to use something that replicates you being at the console, like a network accessed KVM or logmein . . .

 

I hit the server via logmein then RDP to the sql box from there. Do you think that's going to be an issue?

[timzim]

I hit the server via logmein then RDP to the sql box from there. Do you think that's going to be an issue?

 

No because you'll be accessing SQL locally from the server.

[tech_guy]

No because you'll be accessing SQL locally from the server.

 

Thanks, I didn't think it would be!

[vikpaw]

will it be considered locally, if you rdp from one server to the sql server...? i can't remember what issue i had before, but i'm sure it was to do with rdp. it was a Virtual server i was accessing.

It worked okay if i did the VMWare simulated console access, but i'm sure rdp failed as it was considered remote - but i may be wrong. just try it and see. worst case you could try and logmein to the sql box maybe...?

[tech_guy]

will it be considered locally, if you rdp from one server to the sql server...? i can't remember what issue i had before, but i'm sure it was to do with rdp. it was a Virtual server i was accessing.

It worked okay if i did the VMWare simulated console access, but i'm sure rdp failed as it was considered remote - but i may be wrong. just try it and see. worst case you could try and logmein to the sql box maybe...?

 

Thanks, for reasons I do not understand we can use logmein on our DC but not our sql box....

[vikpaw]

I don't normally go for the single user mode, though it's probably the safest way to do it. I just kick all off and remove permissions to the SIMS share (S drive), so noone can access the connect.ini that's held there and thus not log in again. The only people that have local connect.ini are myself and the IT manager so it's not a problem.

If anyone is left in the system they will still have access but if you restart the server / sql service that should throw them out

sorry, i'm digressing from the recommended method, which is what you need if you are having problems with ghosts.

[timzim]

I just kick all off and remove permissions to the SIMS share (S drive), so noone can access the connect.ini that's held there and thus not log in again. The only people that have local connect.ini are myself and the IT manager so it's not a problem

 

Doesn't this cause problems when you restore permissions & want users to connect again though? Losing rights to S: could cause connectivity errors to pop up on users' workstations (and hence calls to the helpdesk) - might need them to logoff/log again, depending on how their drives are mapped.

[vikpaw]

yes, but usually i'm doing the upgrade last thing on a wednesday (my friday) so they have gone home for the weekend and will be logged out. i might also do the work on thursday, so not a big issue.

plus, they all know that the first thing we ask them to do is reboot if something goes wrong, as it's not worth walking 100-200 yards in 40 degree heat without at least trying that panacea first!

[Banjo]

You can try de-attaching and reattaching the databases – this has worked for me in the past.

[timzim]

You can try de-attaching and reattaching the databases – this has worked for me in the past.

 

Bit like stopping the car, getting out, locking the doors, unlocking, getting in & starting up again just to go round a corner. Mind you, if it was Microsoft car you'd probably have to do this...

[Banjo]

Bit like stopping the car, getting out, locking the doors, unlocking, getting in & starting up again just to go round a corner. Mind you, if it was Microsoft car you'd probably have to do this...

 

Yup, and the weirdest thing is, I've been logged into Sims and have been demonstrating Assessment Manager 7 when a member of the office staff has run Solus and completed a successful upgrade (apps & database upgrade) with me logged in. AM7 crashed 10 minutes later, fired it back up and the workstation started to upgrade.