restricting concurrent log ins

[andyturpie]

Afternoon all,

 

Just wondered what your school policy was for restricting concurrent logins for staff? I have had a look on on our CC4 RMMC and I have noticed well into double figures logged into more than one machine. Can being logged into multiple machines cause proflie corruption? One response I've is that if we have to restrict to a single allow login, then its a fundamental flaw in RMCC4, which I beleve that can happen on vanilla networks regardless?

 

Any advice and thoughts on this will be appriciated as always!

Edited October 12, 2012 by andyturpie
edited

[JSchlackman]

Your timing in asking this question is perfect, as I'm about to post about a program I wrote that might help with this sort of problem. We don't restrict the number of concurrent logons, but we do keep track of them and automatically log off the oenes that have been left in the Disconnected state to long.

 

I gather I can't post a URL on my first post so look for a thread about Session Arbiter in the Windows 7 forum in a few minutes.

Edited October 12, 2012 by JSchlackman

[Jamo]

I have another program similar to the above althogh we don't have fast user switching enabled so that stale logons aren't a problem here. It basically just stops two logons at once. RSLogonLimit available RS Applications

 

We use it here for staff and student logons can be set to bypass for certain 'trusted' users who require a second logon, and in those cases it will just warn the user that they are logged on elsewhere instead of logging them off again.

[sjatkn]

@Jamo how does RSLogonLimit cope if a machine is reset and the user does not logon to the same machine again but moves on to another machine or even another class?

 

From what I saw on the website it looks like you would not be allowed to logon until an admin deleted your previous logon. Would I be right in assuming there is no test performed to see if the user is still logged on to the other machine.

[bossman]

@andyturpie:

 

Staff users = 1 login

SLT users = 2 logins

Student users = 1 login

 

With roaming profiles as in CC4 more than one login can cause corruption as user can be logged into 2 workstations at the same time and have applications and files open in both sessions which when the user logs out the changes are sent back to the original profile on the server but some staff leave themselves logged in to one of the sessions and when the shutdown task is initiated it tries to write the other changes also and this is where the corruption comes from.

 

When the user comes to log in to the machine which has been shutdown via the shutdown task forcing the log off of the user the it looks first for the local profile which has been stored on the machine and this maybe corrupted but loads it anyway and the user ends up with certain problems like printers not mapping properly or access rights to their own folder not being applied.

 

I would like to force everyone down to a one login practise with roaming profiles but unfortunately due to the laziness of some users it becomes apparent that they will not like this strategy and therefore have to run the risk of their profiles becoming corrupted, as long as they are made aware of this then they know what to expect.

 

Also with roaming profiles they obviously become larger and I have found anything above 3Mb also runs the risk of becoming corrupted so I regularly clean everyones profile at certain times (giving the users notice first) they all seem to agree as it makes their user experience that much better.

 

Running a VB script to clear all those profiles which are not required at shutdown also helps as the users get a fresh profile everytime they login.

 

Someone maybe able to go into greater depth but that is the overview.

Edited October 13, 2012 by bossman

[Jamo]

@Jamo how does RSLogonLimit cope if a machine is reset and the user does not logon to the same machine again but moves on to another machine or even another class?

 

From what I saw on the website it looks like you would not be allowed to logon until an admin deleted your previous logon. Would I be right in assuming there is no test performed to see if the user is still logged on to the other machine.

 

We allow staff users access to the student share so they can log off the student users themselves. It is mainly there for security, ie if one user were to logon as another to try to bypass an internet restriction or the like. You are correct that no actual 'test' is performed on the physical machines, it was written for simplicity so it doesn't rely on client applications, DNS, or anything to deploy client side at all if you see what I mean Staff users can only be logged off by an admin in our environment.

 

As for if a machine crashes, if the student logs on to the same machine as before, the logon is allowed, it is only when the user logs on to a different machine.

 

It seems to work that way for us. Let me know if you get any use from it.

[andyturpie]

Thanks guys - I haven't made the change yet I have left the RMMC users at 2 concurrent log ins for all, but a stroppy email to all teaching staff I have cut it down from around 25 users to only 1 today.

I have delprof2.exe and created a basic manual run script which cleans our terminal servers and our IT suites when run, but cannot fathom out how to create a CC4 package to deploy it and make it run autonomously yet!

[Michael]

UserLock will do what you require for concurrent logins.