Losing my Group Policy virginity
One of my projects lately has been going through some 1600+ login scripts (written in VBscript) and merely alphabetizing the mapped drive letters. Tedious and boring, yes but it wasn't as horrible as I'd initially thought. However, login scripts like this can certainly have their share of issues.
Recently, we had someone of a fairly high-level request a new "drive" be made for herself and some other fairly high-level employees. What ended up happening is that whomever made the share had misspelled a word in the command to map the drive. This caused the new share not to be mapped and any drives mapped after that to not be mapped as well. This of course, sparked a series of emails with high-level employees freaking out because they can't see important drives anymore, lamenting that their work is lost and demanding that IT do something about it. Good times, good times.
Right now, this is what our scripts generally look like. I've taken out any organizationally-specific information but you get the idea. Scripts like these are saved as cmd and titled as the username.
While this works, when we have to update these, we have to update each and every script by hand. This can get mind-numbingly boring and very prone to user-error. A single typo or a missed space can spell disaster for that script.
I was speaking of this to a friend who also works in IT and he asked why we weren't using Group Policy. I asked a co-worker as well as my supervisor if there's a reason we're still rockin' individual scripts versus something like Group Policy and both were in favor of utilizing something else but making it work could take a lot of time and effort. The jist of it is that there's no specific reason we're not using GP. The old method still largely works; It's just more error prone and doesn't offer the flexibility of something centrally managed such as GP. So, I got to reading. After a cumulative 5 hours of reading over 2 days, here's what I've learned:
I'll keep posting as I learn more about it.
Recently, we had someone of a fairly high-level request a new "drive" be made for herself and some other fairly high-level employees. What ended up happening is that whomever made the share had misspelled a word in the command to map the drive. This caused the new share not to be mapped and any drives mapped after that to not be mapped as well. This of course, sparked a series of emails with high-level employees freaking out because they can't see important drives anymore, lamenting that their work is lost and demanding that IT do something about it. Good times, good times.
Right now, this is what our scripts generally look like. I've taken out any organizationally-specific information but you get the idea. Scripts like these are saved as cmd and titled as the username.
@echo off
rem ------------------------------------------------------------
rem DELETE MAPPED DRIVES
rem ------------------------------------------------------------
rem ECHO
Deleting any mapped drives...
net use H: /delete
net use P: /delete
net use Q: /delete
net use Y: /delete
net use Z: /delete
rem ------------------------------------------------------------
rem MAP USER NETWORK FOLDERS
rem ------------------------------------------------------------
rem ECHO
Mapping your network folders...
net use H: "\\(fileserver)\directory$" /persistent:no
net use P: "\\(fileserver)\directory$" /persistent:no
net use Q: "(fileserver)\directory$" /persistent:no
net use Y: "(fileserver)\directory$" /persistent:no
net use Z: "\\(fileserver)\%USERNAME%$" /persistent:no
rem ------------------------------------------------------------
rem CONNECT PRINTERS FROM (print server)
rem ------------------------------------------------------------
rem ECHO
Connecting printers from (print server)...
rundll32 printui.dll,PrintUIEntry /in /u /q /n "\\(print server)/(printer name)"
rem ------------------------------------------------------------
rem Set Default Printer
rem ------------------------------------------------------------
rundll32 printui.dll,PrintUIEntry /y /q /n "\\(print server)/(printer name)"
rem ------------------------------------------------------------
rem Remove (print server) Printers
rem ------------------------------------------------------------
cscript /nologo /B "(scipt-file-location).vbs"
While this works, when we have to update these, we have to update each and every script by hand. This can get mind-numbingly boring and very prone to user-error. A single typo or a missed space can spell disaster for that script.
I was speaking of this to a friend who also works in IT and he asked why we weren't using Group Policy. I asked a co-worker as well as my supervisor if there's a reason we're still rockin' individual scripts versus something like Group Policy and both were in favor of utilizing something else but making it work could take a lot of time and effort. The jist of it is that there's no specific reason we're not using GP. The old method still largely works; It's just more error prone and doesn't offer the flexibility of something centrally managed such as GP. So, I got to reading. After a cumulative 5 hours of reading over 2 days, here's what I've learned:
- There's Group Policy Settings and Group Policy Preferences. The difference is that Settings are enforced, which means that users cannot change them, while Preferences aren't enforced and can be changed by users.
- A Group Policy Object (aka, GPO) can be applied to a Computer Configuration or a User Configuration. GPOs for a Computer Configuration will be set for any user that logs on to that computer or group of computers. Likewise, GPOs for a User Configuration will be set for that specific user or a specific OU (Organization Unit. It's an Active Directory thang).
- The tool that you use to create and manage GPOs is called Group Policy Management Console (aka, GPMC).
- Apparently, many Windows admins that it's merely myth that Group Policy works on XP, Server 2003 and older but it's actually true. You have to have Windows 7, Vista or Server 2008 with Remote Server Administration Tools (RSAT) installed to manage Group Policy Preferences, XP or Server 2003 to manage GPOs in general and everything before that (such as Win2k and older) can only receive GPOs, not manage them.
- Group Policy Preferences can be volatile which means that the Preference will be removed it if it no longer applies to the target.
- Speaking of targeting, Group Policy Preferences has Item-Level Targeting (ILT). Basically, it 's a way to see if the computer in question meets a specified set of rules before applying said Preference. If it meets all of the rules, then the Preference is applied. If it doesn't, then it isn't. Simple as that.
I'll keep posting as I learn more about it.
I typically create one GPO that handles drive mappings for all the users in a given OU (or multiple OUs, you can have a one-to-many relationship if you want) and then use Item-Level Targeting to assign drives to a specific range of IPs, computer names, users, etc. It works really well, the only catch is that older machines still running XP need to have the Group Policy Preferences update installed or the policy won't apply to them.
ReplyDeleteHere's a video with a decent(ish) example:
http://vimeo.com/16289615