Detect loss of conectivity on workstation?

[dgsmith]

We've had a bit of a frenzy recently where kids are pulling the cat5 cables out of the sockets, and we are constantly running around to fix the problem where the kids can't access their My Docs. Some are now finding a good game site and then pulling the cable so we can't trace them (unless we go there in person, which we are getting a bit fed up of doing). I would imagine other schools have had this problem, and I hope some have adopted some system to manage it. My thought, although merely a passing one, would be to get a backround script or program running which would detect loss of connectivity, and maybe freeze or lock the mouse/keyboard (or to a similar effect) until connectivity is restored.

 

Now, this wouldn't be ideal on our wireless machines as they are obviously not as stable, but at least if it was possible in the "hot spots" then I could see if it worked. It was simply a passing thought, and i'd guess it'd involve a combination of backround programs and scripts to perform the task. If there are better solutions or alternatives then i'd appreciate hearing them.

[Michael]

I can't say I've ever experienced pupils pulling CAT5 cables out. This really is a job for teachers to stop this happening.

 

As for wireless, I do have a similar problem whereby children turn the wireless adapter off, then the next user cannot find the domain.

[plexer]

Yup classroom control issue kids shouldn't be touching anything except the keyboard and mouse and not those if it can be helped

 

Ben

[mac_shinobi]

I can't say I've ever experienced pupils pulling CAT5 cables out. This really is a job for teachers to stop this happening.

 

As for wireless, I do have a similar problem whereby children turn the wireless adapter off, then the next user cannot find the domain.

 

get that here with the wireless adaptor - think there is a setting on dell laptops to disable the use of the function keys. Not sure if thats of any use.

[dgsmith]

We have been there and done that with regards to wireless switches, only they were disabling it upon the logon scripts running (when applying settings), and timing it in such a way that it failed to apply the type settings and gave them local admin rights (this was the same for wired machines, only harder to do without being caught). Unfortunately, some kids here go into the rooms unsupervised, or likely go in there and pull a few without logging on, so tracing can be difficult.

I was looking for a way to deal with it if it happened, as preventing is isn't all too easy.

[Geoff]

There's a VBS script on the forums that'll reboot the machine if it loses network connectivity.

[dgsmith]

I did a few searches on relevant critera before making the post but couldn't find anything useful. Could you point me in the right direction or maybe recall what the key terms where for me to get the right search criteria?

if a VBS script exists, then it may be useful to see how it goes about performing the reboot/detecting network loss etc.

[_Bob_]

The following will drop an event into the logs detailing the currently logged on user when the network lead is disconnected. You could add it as a logon script.

 

strComputer = "." 
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\WMI") 
Set objEvents = objWMIService.ExecNotificationQuery ("SELECT * FROM MSNdis_StatusMediaDisconnect")
Const EVENT_FAILED = 2

Do While(True)
   Set objReceivedEvent = objEvents.NextEvent

   'report an event
Set objShell = Wscript.CreateObject("Wscript.Shell")
Set objNetwork = Wscript.CreateObject("Wscript.Network")
strComputer = "."
Set objWMIService = GetObject("winmgmts:"  & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
strEventDescription = "Network disconnected " & objNetwork.UserDomain & "\" & objNetwork.ComputerName & " by user " & objNetwork.UserName
objShell.LogEvent EVENT_FAILED, strEventDescription
   
Loop

 

If they are doing stuff prior to login you are a bit stuck, but if they are pulling your machines apart unsupervised access seems a bad idea.

[Geoff]

That'd work as a startup script though wouldn't it?

[_Bob_]

That'd work as a startup script though wouldn't it?

 

Should do if you want to modify it to reboot the machine or something, but obviously you won't be able to log a user name prior to a logon.

 

[Grommit]

Our kids also pull out the cat 5 when they are on a game...

 

Wonder how this will work under the BSF ?

[srochford]

Should do if you want to modify it to reboot the machine or something, but obviously you won't be able to log a user name prior to a logon.

 

 

There's also the problem that the startup script is normally run from a network share - if you unplug the wire before the machine has started up then all bets are off as to its ability to do much of use :-)

 

Having spent an excellent day yesterday at Viglen learning about all sorts of exciting new technologies I can tell you that part of the answer might be Intel Vpro/AMT - amongst many things this can do is alert you when a machine loses network connectivity. Sadly, that's no use unless you've got new machines but it's useful for the future.

[dgsmith]

Well, with regards to pulling the plug upon login, we countered this by a combination of upgrades to the logon procedure (hotfixes by RM, as it's a CC3 network), and also a startup script locally installed at each machine, which would ping the central server when login completes as well as checking for the existance of network shares. Using both was necessary, as if kids unplugged at the right time to bypass user settings, but plugged in at the right time as to get the ip back, it would get the ping response fine and give the all ok if just relying upon the ping; the network share is assigned during the settings being applied, thus to get this "local admin rights" amongst their other benefits would mean to forefit the network shares. When either or both of the criterion fails, the script informs the user of the logout action and logs them out immediately.

 

I can't say how truely effective this has been in terms of whether it works every time, as we don't log such events and kids obviously don't come running to us because they can't "get passed security" as it where, but through my own testing this worked to an extent that was sufficiently reasonable to counter the majority of attempts. We hear little (in fact make that none in quite some time) of kids having admin rights to the machines compared to late last year, as staff are encouraged to go around briefly and just check maybe once or twice a lesson. Certainly at least, a combination of these methods is worthwhile, and the fact reports of such event occurance has gone down to practically nil suggests to us that this has been made much harder, though by no means impossible, but certainly border-lining it.

 

Of course, this wasn't related to my query originally, and given this is a problem we no longer experience like we used to, I am still inclined to rectify the same "unplugging" problem just with these different effects. Supervising ICT access is something we constantly try to maintain, but it's simply impossible to do all the time, especially during lunch and after school. The knock-on effects for us aren't only just during lesson time (unable to monitor machines), but also the after effects of having to correct the problem when staff can't comprehend what to do themselves over the phone (which for some is understandable and we will happily sort it for them). My hope was that if there was a deterrent to such action, which meant the students would see no benefit in unplugging the cable (whilst logged on at least), then it would at least reduce the workload of rectifying it ourselves or explaining to staff. As expected, you might get the odd "driveby unplugging" to explain it simply, though if there is a solution to minimise the disruption where possible, then i'll gladly consider its trialing.

 

Slightly longer than I had intended - I have a habbit of rambling a bit excessively

Edited March 13, 2008 by dgsmith

[dgsmith]

The following will drop an event into the logs detailing the currently logged on user when the network lead is disconnected. You could add it as a logon script.

 

strComputer = "." 
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\WMI") 
Set objEvents = objWMIService.ExecNotificationQuery ("SELECT * FROM MSNdis_StatusMediaDisconnect")
Const EVENT_FAILED = 2

Do While(True)
   Set objReceivedEvent = objEvents.NextEvent

   'report an event
Set objShell = Wscript.CreateObject("Wscript.Shell")
Set objNetwork = Wscript.CreateObject("Wscript.Network")
strComputer = "."
Set objWMIService = GetObject("winmgmts:"  & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
strEventDescription = "Network disconnected " & objNetwork.UserDomain & "\" & objNetwork.ComputerName & " by user " & objNetwork.UserName
objShell.LogEvent EVENT_FAILED, strEventDescription
   
Loop

 

If they are doing stuff prior to login you are a bit stuck, but if they are pulling your machines apart unsupervised access seems a bad idea.

 

Just tested that on my home computer (compiled to exe and ran as a standard exe file, to test it's workability), and hey presto.. it detected the disconect in less than a second, and the cpu usage it needs doesn't even top 1% (I didn't notice an increase on cpu demand). Certainly something to work from! Cheers!