RG-MCSE
asked on
How to Limit Logon Script to Specific Machines Only via Group Policy?
Hello,
There are several hundred computers spread out in groups of 20-30 in different classrooms. There are nearly a thousand students and teachers. The computers are organized by OU (classroom). In each classroom there is typically a teacher's workstation, too, that has attached to it one or more printers which are shared so that everyone else in the classroom can use them. Those definitions currently are being done manually and has gotten tiresome with all the turnover semester to semester and the number of students involved.
I want to connect a classroom's 2 printers to anyone who logs on to any student machine in that particular classroom, but nowhere else. As an example, Little Johnny in the Chem Lab doesn't need printers from English Lit 201. I wrote a VB Script that defines the network printers and sets one as default; it works well for all users security levels when I execute it manually off the desktop after I've logged on. It's specific to the classroom.
Now I want to automate this process and make it a logon script so that anyone who logs onto any machine in that classroom gets ITS two printers and no others. I created a group policy that defined my script in the user Windows scripts logon section. I was careful to place it in the policy folder. I attached that policy to the computer OU for that classroom. I even did a gpudate. But it never executes when I log onto a machine in that classroom.
Somebody told me that I can only associate a user policy with a user security group. I don't understand that (since policies contain both a computer and user component) nor even how that is practical since I want ANY user who logs on in a specific location (a unique classroom) to have a particular logon script run (with its own unique printers). I don't want printers being defined to a user for Classroom 4 when the user is logging onto a computer in Classroom 12. And it's unwieldly to impossible to keep regrouping students based on their classroom assignments (which change during the day). Intuitively, the logon script should be assigned/selected based on LOCATION (the computer by its membership in the OU) and NOT by who happens to be logging on.
But I haven't been able to figure it out yet. Any ideas?
There are several hundred computers spread out in groups of 20-30 in different classrooms. There are nearly a thousand students and teachers. The computers are organized by OU (classroom). In each classroom there is typically a teacher's workstation, too, that has attached to it one or more printers which are shared so that everyone else in the classroom can use them. Those definitions currently are being done manually and has gotten tiresome with all the turnover semester to semester and the number of students involved.
I want to connect a classroom's 2 printers to anyone who logs on to any student machine in that particular classroom, but nowhere else. As an example, Little Johnny in the Chem Lab doesn't need printers from English Lit 201. I wrote a VB Script that defines the network printers and sets one as default; it works well for all users security levels when I execute it manually off the desktop after I've logged on. It's specific to the classroom.
Now I want to automate this process and make it a logon script so that anyone who logs onto any machine in that classroom gets ITS two printers and no others. I created a group policy that defined my script in the user Windows scripts logon section. I was careful to place it in the policy folder. I attached that policy to the computer OU for that classroom. I even did a gpudate. But it never executes when I log onto a machine in that classroom.
Somebody told me that I can only associate a user policy with a user security group. I don't understand that (since policies contain both a computer and user component) nor even how that is practical since I want ANY user who logs on in a specific location (a unique classroom) to have a particular logon script run (with its own unique printers). I don't want printers being defined to a user for Classroom 4 when the user is logging onto a computer in Classroom 12. And it's unwieldly to impossible to keep regrouping students based on their classroom assignments (which change during the day). Intuitively, the logon script should be assigned/selected based on LOCATION (the computer by its membership in the OU) and NOT by who happens to be logging on.
But I haven't been able to figure it out yet. Any ideas?
I believe i'm not understanding a part. But is there a reason you can't use a startup script instead?
Isn't per machine printer deployment only supported under Windows XP and not Windows 2000? I was assuming that he had a mixed environment.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
"Intuitively, the logon script should be assigned/selected based on LOCATION (the computer by its membership in the OU) and NOT by who happens to be logging on."
Intuitive for YOU, but NOT for microsoft. They only think of a login as related to a user. If you reorient your thinking to a USER-based scenario, maybe you understand that microsoft is not as smart as you are.
Intuitive for YOU, but NOT for microsoft. They only think of a login as related to a user. If you reorient your thinking to a USER-based scenario, maybe you understand that microsoft is not as smart as you are.
ASKER
Well, this implementation of policies by Microsoft is abysmal, if indeed one cannot also enforce a policy based on a computer's membership in an OU and thus apply that policy to anyone who logs onto that machine. I have difficulties imagining they can be that shortsighted, especially since A/D has been around since the late 1990's. Sure, I can define a naming convention of the machines based on classroom then expand the VB script to test for a machine-name prefix or something else that effectively groups a set of machines into a physical location. But then, what's the point of putting machines into their own OU as a grouping mechanism? I'm (re)inventing my own grouping, just like I had to do prior to active directory.
Yes, intuitively, I just can't get over how restrictive everyone thinks the implementation still is after all these years. And it may be just that because, like everyone else who's responded, I haven't been able to figure it out yet either. So I'm going to let this question simmer for a while just in case what unfortunately appears to be the "common knowledge" turns out to be just that--common. (No insult meant, I include myself in that grouping.)
I appreciate victornegri's post of circumventions; many of these I'd considered myself already. However, Merete's response seemed to show the most promise and it was backed up with a specific example from UCAL that appears to be on point. While I've not tried this implementation, the sentence that caught my eye reads from the summary:
"Using a GPO linked to the computer OU, instead of the student account OU, and enabling loopback processing settings, activates processing of the user configuration settings of the computer GPO, which is normally ignored during user logon. By enabling loopback processing, any user setting available in the User Configuration node can be applied even if the GPO is linked to the computer OU."
Thanks, Merete, I need to study this more. I'll need a few days, maybe over the weekend.
Yes, intuitively, I just can't get over how restrictive everyone thinks the implementation still is after all these years. And it may be just that because, like everyone else who's responded, I haven't been able to figure it out yet either. So I'm going to let this question simmer for a while just in case what unfortunately appears to be the "common knowledge" turns out to be just that--common. (No insult meant, I include myself in that grouping.)
I appreciate victornegri's post of circumventions; many of these I'd considered myself already. However, Merete's response seemed to show the most promise and it was backed up with a specific example from UCAL that appears to be on point. While I've not tried this implementation, the sentence that caught my eye reads from the summary:
"Using a GPO linked to the computer OU, instead of the student account OU, and enabling loopback processing settings, activates processing of the user configuration settings of the computer GPO, which is normally ignored during user logon. By enabling loopback processing, any user setting available in the User Configuration node can be applied even if the GPO is linked to the computer OU."
Thanks, Merete, I need to study this more. I'll need a few days, maybe over the weekend.
ok. I'm a moron... I wrote "There is no loopback for user policies to make them apply to computer objects" in my previous post... LOL, that's the only form of loopback available. You can enable loopback processing on the GPO applied to the Computer OU and set it to "merge" the settings with the user's policies. This will allow you to set anything in the User Configuration section of the GPO and have it apply to those specific computers.
ASKER
Merete,
The article you cited was right on.
A little more digging revealed this, too: http://support.microsoft.com/?id=231287
Thank you very much, not only for the correct answer, and so quickly, but also taking the time to cite a working example from UCLA--another school with the identical problem (solved) that I was wrestling with.
And humble, too... "My first stab at it..." lol
If there was a score higher than "A" I'd surely give it to you; you've earned it. Full points awarded.
RG
The article you cited was right on.
A little more digging revealed this, too: http://support.microsoft.com/?id=231287
Thank you very much, not only for the correct answer, and so quickly, but also taking the time to cite a working example from UCLA--another school with the identical problem (solved) that I was wrestling with.
And humble, too... "My first stab at it..." lol
If there was a score higher than "A" I'd surely give it to you; you've earned it. Full points awarded.
RG
wow I am impressed, even though the jargon hurts my head, sometimes I have to use my own words. That was my pleasure indeed RG-MCSE . I'll keep this post of yours as a database.
Thank you very much.
Regards Merete :)
Thank you very much.
Regards Merete :)
For all of these, you would place the script associated with the user account and not computer account:
1) If you have static IPs set on the computers, you can check the IP address of the computer (i.e. set classroom 12 to be 10.1.12.0/16, classroom 13 to be 10.1.13.0/16, etc)
2) You can add a system environment variable to each workstation called "Classroom" and give it a value of "12" then query the %classroom% variable in the logon script to see what classroom it's associated with.
3) You can add the script to the HKLM\Software\Microsoft\Wi
4) You can make each student a member of each of the classrooms they are assigned to and map all printers for all classrooms they go to by checking group membership (this may be risky since students are known to mess around and play pranks like printing something to another classroom)
Remember that Computer policies get applied at startup and user policies get applied when the user logs on. There is no loopback for user policies to make them apply to computer objects.