How to handle users that standby their laptops

gollo · 06-20-2011, 11:48 AM

I've got a location that the majority of their users have laptops. With Windows 7 and standby being as good as it is most of these users don't reboot their computers on a regular basis (maybe once or twice a week).

What I'm seeing is that the AD script appears to stop running or stop reporting. When I first deployed the script I had almost all of my users showing up in the system. Now I'm only seeing those users that log in/out on a regular basis.

Is there any way to work around this? I had thought about deploying a scheduled task to run the script every 15 minutes or so. Is there any down side to doing this?

Thanks in advance.

Big D · 06-20-2011, 12:44 PM

If the task terminates the old process, assuming it exists, I would think it would be ok.

I thought you were asking how to make ppl reboot their PCs at first. You could probably use a windows GPO to kill the standby option on domain member machines.

gollo · 06-20-2011, 01:48 PM

Quote:

Originally Posted by Big D

If the task terminates the old process, assuming it exists, I would think it would be ok.

I thought you were asking how to make ppl reboot their PCs at first. You could probably use a windows GPO to kill the standby option on domain member machines.

Disabling standby isn't really an option. The problem appears to be when they go off site and then come back on the script appears to no longer reports. No idea if it is still running or not though.

In regards to the scheduled task: what would be the issue if there are two copies of the script running? Wouldn't it just report the same info twice?

sky-knight · 06-20-2011, 01:56 PM

The script simply tries to access a url on the UT server with some parameters. It does so in an endless loop. Check one of the units for a wscript.exe process after it returns and see if it's still running. If it isn't well there isn't much you can do.

This is why UT has a captive portal. It's more annoying, but a far more consistent authentication mechanism.

If only we could auto exempt users from the portal when the script is already authenticating them.

jcoehoorn · 06-20-2011, 02:28 PM

Quote:

Originally Posted by sky-knight

If only we could auto exempt users from the portal when the script is already authenticating them.

What makes you think you can't? I do this right now, after a fashion.

Faculty/Staff are on one vlan, wireless and students on others. Addresses that come from the subnet associated with the faculty/staff vlan use the logon script. Addresses that are associated with subnets used for residents halls and wireless either go to captive portal or are tracked by IP only.

We have longish lease times (8 days, the default, but a lot of deployments I've visited recently have it set much lower now, like 15 minutes or so), so tracking by IP isn't so bad. If I need to know a user for a specific IP I just add a captive portal rule for it. I could easily turn on Captive Portal for all of these users.

My understanding is that as long as Captive Portal and logon script don't overlap, and as long as I'm willing to allow for some overlap with faculty/staff who have part of their traffic go via wifi, I'm okay.

sky-knight · 06-20-2011, 03:01 PM

Yeah, but that doesn't help the corporate laptop user. You can't have the script deployed to a given range of equipment on a known IP range, then have the portal kick in for those addresses if the script doesn't do its job.

What you are doing is using different authentication modules for different networks. That works, and it works wonderfully. But in this case, we need both in the same place.

gollo · 06-20-2011, 03:04 PM

Ok, well I may have been partly to blame for some of my issues. As it turns out I had been making some changes in AD and changed the group that was used to deploy the AD script. Basically it wasn't deploying for most of my users.

I still think standby is killing the script though as one of my test users that isn't in this group and has the script deployed differently wasn't showing up after a couple of days either. I'll keep my eye on it and maybe I'll shift over to the scheduled task method if this doesn't clear it up.

Is there not a way to create a client that installs on the workstation (maybe as a service even) that includes the same functionality the script offers but on a more consistent basis? For example, what happens when a user reboots their laptop off site now and then come in and connect to the network without logging in? Does the script still run? A program would resolve this.

It could also house features like "login as" where you could run it on non-domain connected systems. I suppose I could get similar functionality by running the script as a different user but that isn't as elegant or simple IMO.

Sorry for going off a little bit there. I'm going to keep my eye on it now that I've got my script deployment working (again) and see if it actually is as bad as I think it is.

Thanks for the feedback.

PS proper VLAN support would be great btw. I don't see why a router module couldn't be bolted on in front of the UT VM....but then again a lot of things are really easy in my head

06-20-2011, 11:48 AM	#1 (permalink)
gollo Untangler Join Date: Jul 2009 URLs submitted: 2 Posts: 38	How to handle users that standby their laptops I've got a location that the majority of their users have laptops. With Windows 7 and standby being as good as it is most of these users don't reboot their computers on a regular basis (maybe once or twice a week). What I'm seeing is that the AD script appears to stop running or stop reporting. When I first deployed the script I had almost all of my users showing up in the system. Now I'm only seeing those users that log in/out on a regular basis. Is there any way to work around this? I had thought about deploying a scheduled task to run the script every 15 minutes or so. Is there any down side to doing this? Thanks in advance.

06-20-2011, 12:44 PM	#2 (permalink)
Big D Master Untangler Join Date: Nov 2008 Posts: 691	If the task terminates the old process, assuming it exists, I would think it would be ok. I thought you were asking how to make ppl reboot their PCs at first. You could probably use a windows GPO to kill the standby option on domain member machines. __________________ The beatings shall continue until morale improves!

06-20-2011, 01:56 PM	#4 (permalink)
sky-knight Join Date: Apr 2008 Location: Phoenix, AZ URLs submitted: 8 Posts: 15,454	The script simply tries to access a url on the UT server with some parameters. It does so in an endless loop. Check one of the units for a wscript.exe process after it returns and see if it's still running. If it isn't well there isn't much you can do. This is why UT has a captive portal. It's more annoying, but a far more consistent authentication mechanism. If only we could auto exempt users from the portal when the script is already authenticating them. __________________ Rob Sandling, BS:SWE, MCP Intouch Technology Phone: 480-272-9889 rob@intouchtechllc.com UntangleAppliances.com Phone: 866-794-8879

06-20-2011, 03:01 PM	#6 (permalink)
sky-knight Join Date: Apr 2008 Location: Phoenix, AZ URLs submitted: 8 Posts: 15,454	Yeah, but that doesn't help the corporate laptop user. You can't have the script deployed to a given range of equipment on a known IP range, then have the portal kick in for those addresses if the script doesn't do its job. What you are doing is using different authentication modules for different networks. That works, and it works wonderfully. But in this case, we need both in the same place. __________________ Rob Sandling, BS:SWE, MCP Intouch Technology Phone: 480-272-9889 rob@intouchtechllc.com UntangleAppliances.com Phone: 866-794-8879

Protect

Filter

Perform

Connect

Manage

Add-Ons

06-20-2011, 03:04 PM	#7 (permalink)
gollo Untangler Join Date: Jul 2009 URLs submitted: 2 Posts: 38	Ok, well I may have been partly to blame for some of my issues. As it turns out I had been making some changes in AD and changed the group that was used to deploy the AD script. Basically it wasn't deploying for most of my users. I still think standby is killing the script though as one of my test users that isn't in this group and has the script deployed differently wasn't showing up after a couple of days either. I'll keep my eye on it and maybe I'll shift over to the scheduled task method if this doesn't clear it up. Is there not a way to create a client that installs on the workstation (maybe as a service even) that includes the same functionality the script offers but on a more consistent basis? For example, what happens when a user reboots their laptop off site now and then come in and connect to the network without logging in? Does the script still run? A program would resolve this. It could also house features like "login as" where you could run it on non-domain connected systems. I suppose I could get similar functionality by running the script as a different user but that isn't as elegant or simple IMO. Sorry for going off a little bit there. I'm going to keep my eye on it now that I've got my script deployment working (again) and see if it actually is as bad as I think it is. Thanks for the feedback. PS proper VLAN support would be great btw. I don't see why a router module couldn't be bolted on in front of the UT VM....but then again a lot of things are really easy in my head