@PiqueABoo: I'll cover your points one by one, and I do apreciate them...
Yes I agree however the more intergration you have with AD then "potentially" the more delegation you have to give to those using the toolbar, now talking from exprerience I have come across sites where this is limited technical expertise due to many varying reasons and having to do mass delegation is not an option.
My starting position for any domain management app is that AD is where you do everything you possibly can because it is the native central, queryable, nicely replicated domain management database after all.
Neither is creating complex ADUC MMC's to do the job. The whole idea is simple to use, simply to deploy, and lightweight.
Yes very sad but very true, i've seen it.
If people's computer OU's do not reflect physical site topology then it's sad, but..
Again alot sites don't use this. Scenario: I release a toolbar to help users and technical staff make life easier but before you can use theres a fair bit of AD admin you need to do first, people just won't use the toolbar and alot of time, effort, and goodwill will be wasted.
There is a computer object attribute you can readily find and edit in ADUC specifically intended to hold a location and that can be entered in a user friendly format.
Yes a good point but they are definately reapplied at logon, or have I miss understood the question?
Hands up everyone if you have credible evidence of your proxy settings being reapplied during a policy refresh in the absence of any changes to your GPOs.
Again the idea was to have a lightweight clientless application.
Haven't thought this through, but is the real requirement to block the Internet (which might cause minor collateral damage when done via proxy fiddling e.g. maybe AV uses the IE proxy to get updates), or stop kids running apps they're not supposed to at any given point in time? Would it be more useful as something that stopped IE, Firefox and any other apps? Might write it off if I think about it some more, but I'd have considered a small appinitDLL to kill and sabotage subsequent startup of (temporarily) verboten apps.
The application would normally be installed on the teacher PC in a classroom or on admin (IT Support) PCs. The calls are based on classes built into the .Net framework which opens up alot more remote management and connectivity than before (non .Net languages) and the maximum memory footprint we have seen in testing when running shutdown commands on 25 virtual PCs was 4.5Mb and when sitting idle it uses around 1.1Mb
Question: I'm not clear about where the app that actually disables the net and shuts down a PC runs. Remote APIs, WMI etc., code running permanently on each PC (if so what's the rough memory footprint) or both?
Hope this answers some of the points you raised. :)