[sims] Kicking People Out Of SIMS?

[Sam_Brown]

Morning Guys,

 

What's the best way for kicking people out of SIMS and making sure no one is conected to the database when it comes to running patches and upgrades?

[FN-GM]

Not done it in ages. I used to rename the connect.ini. Then stop SQL wait a while then start it again. rename connect.ini back to they can use SIMS again. Edited May 17, 2013 by FN-GM

[sparkeh]

I stop TCP/IP and named pipes connections to the db and restart sql, do the upgrade, then re-enable.

[Ashm]

You can also run the sp_who2 command in SQL Management Studio to see who is still connected.

[Ghostgame]

2 ways which I have come across is:

 

-stop the SQL service and only start it up when you want to apply the patch/upgrade/etc.

 

-disconnect the network cable to the server so no-one on the network can get on it (might not be a good idea if your internet connection goes through it first)

[broc]

I have been known to reboot the SIMS Server VM......

[mcrompton01]

We give people 48hrs notice of downtime/patches being applied (if possible) and tell them to out of sims. If the the patch has to be applied during the day we:

 

1. Check SQL Management Studio to find who is logged in

2. Rename the connect.ini to prevent new connections

3. At the given update time we run shutdown -i and add all the computers listed above (step one) and shut them down

4. Wait for all connections in SQL Management studio to disappear

5. Start the upgrade

 

I've even shutdown down senior leaders computers before as they know the time, they have had plenty of warning. Works well here and you'd be surprised to hear not people leave themselves logged in to sims on patch or update day.

[skunk]

Give a time they have to out by and then kill the pulsar.exe process on all machines on the network at that time. Can be done via pskill or we use Impero.

[Greg]

Easiest is to stop TCP/IP and(/or) named pipes connections to SIMS and restart SQL service.

This will still allow you to test upgrades and patches in SIMS on the server before releasing back to users.

 

If any users have full connect.in's locally rather than redirects then renaminng connect.ini on the server will not prevent their access.

[Rawns]

I can't remember who created this SQL script, but I'm sure I got it off another Edugeeker from a similar thread. We use this in management studio and it works a treat to see exactly who's in SIMS:

 

declare @mySIMSdb as nvarchar(100)

set @mySIMSdb = 'sims'



-- drop table #sp_who2

create table #sp_who2 
(
spid int,
status varchar(100),
loginname varchar(2000),
hostname varchar(2000),
blkby varchar(100),
dbname varchar(200),
cmd varchar(max),
cputime int,
diskio int,
lastbatch varchar(100),
pgmname varchar(500),
parentspid int,
request_id int
)

insert into #sp_who2
EXEC sp_who2

select loginname, hostname, dbname  from #sp_who2
where dbname = @mySIMSdb


drop table #sp_who2

 

If your using SOLUS2 to run the upgrade, script it (or run it via a command line) and use the /FORCEUPGRADE /SAUSER=sa /SAPASSWORD=password switches. This will disconnect any usert and apply the upgrade, handy for those few users who always leave SIMS .net running overnight! SOLUS3 should kick users out too by default.

Edited May 17, 2013 by Rawns

[chazzy2501]

meh- I just run solus and see if it works. if it does then no one can use the database

[jallsop]

I used AB tutor to connect to all workstations, and then send them all a polite message, before remotely terminating the application after 20 seconds.

[jinnantonnixx]

@Rawns, that was a first attempt.

A better script to see who's using the system is this:

 

use master;

select 	upper (sysprocesses.loginame) [sIMS User],
sysprocesses.hostname [Machine],
sysprocesses.dbid,
--	sysdatabases.dbid,
sysdatabases.name [Database]	
from sysprocesses

join sysdatabases on sysprocesses.dbid = sysdatabases.dbid

where sysdatabases.name like 'sims%'     --change this to your database name

order by sysdatabases.name  -- works for multihosting systems

 

Note that the connections are transient, so they come and go as and when needed by the client application. This means that you can't rely on it to use see who's got SIMS running on their desktop; it only shows if they're doing something with SIMS at the time you run the script.

 

But it's better than nothing.

 

 

It would be easy for SIMS to put a flag into the database to indicate when a user is logged on.

Edited May 17, 2013 by jinnantonnixx

[Steven_Cleaver]

Abtutor here as well, Email staff day before then if they haven't closed SIM's close SIM's on their machines and leave message on their screens but usually do it end of day.

[synaesthesia]

There's some half-assed solutions there!

 

1. Email all staff. Whinge that they never do what they're told and they're the reason for it not working.

2. Unplug server from network. Upgrade. (fit to an isolated vlan/different switch if you want to do it remotely or if you cba to download the updates beforehand)

3. Consume tea.

4. Plug server back in and head to the pub for a pint.

[vikpaw]

We give people 48hrs notice of downtime/patches being applied (if possible) and tell them to out of sims. If the the patch has to be applied during the day we:

 

1. Check SQL Management Studio to find who is logged in

2. Rename the connect.ini to prevent new connections

3. At the given update time we run shutdown -i and add all the computers listed above (step one) and shut them down

4. Wait for all connections in SQL Management studio to disappear

5. Start the upgrade

 

I've even shutdown down senior leaders computers before as they know the time, they have had plenty of warning. Works well here and you'd be surprised to hear not people leave themselves logged in to sims on patch or update day.

 

That's exactly what i do, except instead of renaming connect.ini i remove permissions from the share for all bar me, so i, and select users can still access if required.

I know that all have a redirected connect.ini so it's okay.

 

Plus, when they come back they can't access the system as the S drive gets disconnected. So when they ask why it doesn't work you have a chance to remind them why, again.

 

The shutdown -i is the best part, and you can send them a nice message in the process.

 

I have a hardcore set of around 10 staff that leave it on every night.