|
Quite a few questions seem to pop up that can easily be solved by using group policy, but people do not know that the option exists or the extent of what it can do. I intent to give a comprehensive (as much as I can, anyway) overview on what group policy is and how to use it, with examples, so you can get cracking at making your life as a domain admin easier. Also because Cidrick told me to make this thread months ago and I am a lazy sack of poo poo. What the hell is group policy? Group policy is an extension of active directory that allows you to push out configuration changes to machine and user accounts automatically. It works by keeping the applicable configuration files and templates on the sysvol share of your domain controllers. Any member of a domain (machine or user account) will automatically poll a domain controller for the policies that fall within its scope and apply them at startup/logon. The domain controllers will also be polled at a regular interval while the machine is on or the user is logged on and applied if possible, but some will only be able to take effect with a reboot (typically logon/off scripts or package deployments). That's great! How I get started? You're going to need a properly functioning domain first, preferably at Server 2003 functional level or better. If you currently are operating in a workgroup, then something is broken in your brain and you should go about building a proper domain first before your life devolves in to unmanageable hell. If you aren't using Windows, then I have no idea why you are reading this thread. If you have the prerequisites, you are then going to need to install some tools on your workstation to manage all of this. On XP, you will first need to install the Windows Server 2003 SP2 Administration Pack (adminpak.msi) followed by the Group Policy Management Console SP1 (gpmc.msi). If you are using Vista, then you will need to install the Remote Server Administration Tools (RSAT)x86 or x64. After RSAT is installed, you need to go in to the Enable/Disable Windows Components control menu applet to enable the features. Make sure you have the latest service packs installed on your system. As for having a preference for using XP or Vista to do group policy management, I strongly recommend that you use Vista as it opens up a whole new set of management features that are not available with XP's GPMC and it really fills in some big gaps that were previously missing and had to be done with elaborate batch or vbscripts. And I don't feel like telling people the lovely old ways of doing things when a much easier, new method is available. More on these new features later. You also want to make sure that the optional Windows Update Group Policy Client Side Extensions is installed across the entire domain for these new features to be usable on older system, but more on that later when I get to patch management. I am in group policy management and it is intimidating as hell. The first thing you need to understand is that group policy primarily functions at the Organizational Unit (OU) level. You create a policy that defines some settings and link it to an OU, the top of your domain, or to the forest if you are managing multiple domains. The policy you link applies to that level and every sub-level below it(typically OUs below it, some exceptions will apply). You cannot apply a Group Policy Object (GPO) to a folder in active directory, which is fine in my opinion since folders in active directory are terrible and you should be using OUs for everything.Policies applied to OUs above the folder will apply to anything within that folder. Exceptions to this are if you have two policies applied at the same level that do opposing things. In this situation, the policy will the lower link order will take priority. You can view link order by clicking on the OU, Domain, or Forest and policies applied at the level will be listed to the right in their link order. Another exception is if you set the "Block inheritance" attribute on a Domain or OU. With this enabled, any policies above the block will not be applied to anything at the level the block is applied or below it. Additional policies can be added at or below the block level and they will function as normal. Policy blocks can get messy to manage so use them sparingly, typically in the event that there is a sub-domain or OU that is completely out of the scope of your control because someone else had been delegated responsibility. The third exception is if you have conflicting policy settings at different levels. For example lets say you set a domain level policy that says My Documents will not be displayed on the users desktop. All user accounts in the domain (assuming no inheritances blocks) will receive this setting. If you make a second GPO that says My Documents will be displayed on the desktop and link it to a OU within the domain, the lower level policy saying My Documents should be displayed will take priority that that OU and everything below it. Setting the "Forced" attribute on GPO link will override this behavior and the policy at the higher level will take priority. The Forced attribute will not override the Block Inheritance attribute of an OU or Domain. You will also notice that when a policy is highlighted you will see a scope pane to the right. The top "Links" menu will tell you all the places the currently linked to and if the link is Enforced. The more important setting to consider is Security Filtering; this setting defaults to the Authenticated Users group which is a built-in group that includes any machine or user accounts in the domain. The target user or machine account must be a member of the security group(s) in Security Filtering to receive the policy. You can also see WMI filtering at this level, but we will get to that later. That's great and all but how do I made an actual policy? Making and editing policies is easy. Go to Group Policy Objects, right click on the "folder" and select New. Name it and the individual policy editor will pop up and you can get cracking.  The first thing you should notice the categories are split in to Computer Configuration and User Configuration. Policies applied to Computer Configuration are executed with the local system account (machine's admin rights) and will apply to anyone logging in to the computer. Policies under User Configuration will follow the user's account that it applies to regardless of what domain computer they log in to. Most policies will be available under either category, with the exceptions being policies that change the OS configuration only being under Computer and policies that only configure a user's profile being under User. You may also notice a few sections are not familiar to XP/Server 2003 users such as everything under Preferences. These are the features that become available if you are building your policies on a Vista workstation, which is why I recommend it. Installing printers, making direct registry, ini, or environmental variable changes are now all naively supported which means you do not need to dick around with making batch scripts to do the work for you. Again, for these features to work correctly you need to install the optional Windows Update Group Policy Client Side Extensions. The Software Settings folder is where you apply packages to be deployed to computers automatically. Windows settings is where security policy, machine startup/shutdown or user logon/logoff scripts, printers, among other things are defined. Administrative Templates is a collection of pre-loaded .adm files that map to registry keys to define application and service settings. You can right click on the Administrative Templates folder and select Add/Remove Templates to import additional .adm files that you can download or pull out of the install media for applications. With Vista you also have the option to apply filters to this section based on services or keywords which acts as a rudimentary search feature. The Preferences folder is another new feature which allows for much more direct modification of files, registry keys, folders, virtually all of the control panel, along with a number of other options. With most settings it is just a matter of defining a policy setting or leaving it undefined and letting it propagate automatically. It is also possible to craft your own .adm files and use those to make registry settings, but in my experience the syntax is terrible and it is just more trouble than it is worth. You are better off defining the settings in the Preferences folder or running a batch script that will do the work for you. So what are some of the things I should do to start? There are a number of base-line things that you should be using Group Policy for in any domain, so I will go over those now. •Automatic Patching: You will most likely want to set up a WSUS server on your network to mirror Microsoft patches and define which ones you want deployed. You don't have to do this if you choose not to and can continue pulling updates directly from Microsoft, but this will save bandwidth and allow you to enforce the updates marked as optional. As I mentioned before, the Group Policy Client Side Extensions is classified as an optional update by extremely critical for getting the most out of Group Policy. That alone is a good enough reason to use WSUS. The applicable policies here are under Computer Configuration, Policies, Administrative Templates, Windows Components, Windows Update. When defining policies, make sure you look for the "Supported on:" comment on some of them. Quite a few features only became available with service packs or new versions of Windows, so make sure that isn't going to be an issue in your environment.  I typically find that the big deal-breaker features are all supported in 2000 SP4 and XP SP2 or 3 but many newer convenience features came about with Vista. The key policies here to look for are:
•Specify intranet Microsoft update service location •Automatic Update detection frequency •Enable client-side targeting  If changes are made directly to the registry, they will be overridden by policy. Local group policy for the machine is also overridden by policy coming from the domain. •System Security: NT, XP, 2000, and 2003 come by default with some very lax security settings that can be problematic. Some of these are for backwards compatibility with DOS/9x and others just leave me scratching my head. The first issue is password policy. You want to look at Computer Configuration, Policies, Windows Settings, Security Settings, Account Policies. An eight character password with enforced complexity requirements and a lifetime for 6mo to a year is what I would consider "safe" for most environments. You may want to rotate passwords more frequently or have a faster expiration depending on your security situation, but just remember that the more restrictive the password policy, the more likely people are going to write the drat things down. There is also the account lockout policy which is good for flagging/slowing down brute force attacks.  Lan Manager Hashes (They're loving terrible) Lan Manager (LM) hashes are the very old style of password authentication that were used in DOS and Win9x. They work by taking a password up to 14 characters (it cannot be longer) and cutting it in half, in to two 7 character passwords, and adding them together which effectively takes a 112-bit password and slashes it half to two 56-bit passwords which is just about as easy to crack as one 56-bit password. And if that wasn't lovely enough, it isn't case sensitive which makes it an even easier target for cracking. A rainbow tables attack on LM hashes can crack through about 10 LM hashes in 20 minutes with 98% accuracy on a modern computer, with simpler passwords (no special characters, numbers) being even faster and more accurate. Why does this matter to you? NT, 2000, and XP still support them by default. This was done for backwards compatibility so you can access password protected network resources on DOS/9x systems, but is a security liability to you. Microsoft has since replaced LM hashes with NTLM hashes which correct the security concerns. The problem is that by default your OS keeps cached domain credentials on the computer in the form of both a LM and NTLM hash in the event that the domain controllers cannot be contacted so you can still log in without being completely locked out. They are also used if you are negotiating remote access against a local system account (like local admin). Domain accounts are going to use kerberos for authentication which is brokered by the domain controllers and considerably more secure, along with not generating hashes. These hashes can be extracted out of decommissioned computers if they aren't wiped properly after use or if someone uses alternative boot media to load a tool that will extract them. To fix this issue, the applicable settings are under Computer Configuration, Windows Settings, Security Options:
•LAN Manager authentication level •Denying local logon/email only domain accounts: We ran in to a situation where retired users still needed a valid account to access their Exchange mailbox with, but we didn't want them to have the ability to log in to a physical machine. The solution we came up with was to create a security group called "Deny Local Logon" and then configure the policy Windows Settings, Security Settings, User Rights Assignment, Deny log on locally so that security group is denied local logon. Then all you need to do is propagate that policy to the entire domain and add/remove members to that security group. You may want to limit the scope of this policy to your workstations and not domain controllers or servers since users shouldn't have logon access there anyway, and someone accidentally or intentionally adding all domain users to that group could screw the pooch and having you restoring from tape. •Service Modification: Windows Settings, Security Settings, System Services gives you a powerful level of control over how services are configured on your workstations. Once such example was a bug in the ATI Hotkey Poller Service in an old version of the driver that broke roaming profiles. Instead of manually disabling it, group policy allows you easily disable the service on all systems. A new feature is that you can now also define security settings for a service, so specific accounts be given permission to Start, Stop, Restart, or have full control over specific services. Previously this had to be done manually at the command line and was a pain in the rear end. •Configuring the Windows Firewall: I know a lot of people run with the policy of disabling the Windows Firewall if you are behind your corporate boundary because it is a "secure" area. I've never bought that argument since one machine behind your firewall becoming compromised can remove that boundary and expose everything else and lets face it, there are a lot of ports that workstations just don't need to be talking to each other on. The firewall configuration settings are at Computer Configuration, Policies, Administrative Templates, Network, Network Connections, Windows Firewall, Domain Profile. The Standard Profile is used for when the machine isn't joined to a domain, so you can ignore that. The policies here to pay attention to are:
•Allow inbound file and printer sharing exception •Allow ICMP exceptions •Allow logging •Define inbound port exceptions •Allow inbound remote administration exceptions •Allow inbound Remote Desktop exceptions •Software Package Deployment: Software deployment is one of the most powerful features available with group policy. They two types of package deployments are Assigned and Published. If you are doing the package deployment as a machine policy, the only option you have is Assigned, where as a user policy has the option of Assigned or Published. Assigned means it will be installed by default, no questions asked, where as Published gives the option to install. For a machine policy, this happens as the machine boots up, so be warned that this can greatly increase boot times that first time and plan accordingly. A user assigned package will show up on the user's start menu and run the installer when executed. It can also be configured to install when the user logs on. A user published package will be displayed in Add/Remove components and the user will have the option from there to install the software or not. The biggest caveat to user packages is that the user needs local admin rights to be able to install this software, which your users really shouldn't have with a proper domain. It still can be useful to publish the packages to your domain admins or technicians though so they have an easy way to sit down and install applications with the transforms pre-applied and not have to dig around in a packages network share. Package deployment can only be done with .msi files. Most applications these days use .msi files, though they can be hidden in a .exe wrapper. The first thing to try is running the installer .exe with the /a switch which may perform an administrative install which essentially unpacks everything to a target directory (in this case, you want it to be your software distribution share which should always be referenced by the UNC path) without actually installing or registering anything on the system. If this doesn't work, you will need to run the .exe normally and then wait at the first screen it displays without continuing. At this point the .exe has uncompressed to a temporary directory located in %temp% (put that in a run dialog and it will take you there) and then look for a randomly named directory with a very recent timestamp which will most likely be your uncompressed installer files, with an .msi file in that directory. Copy the whole directory to your desktop or some other working directory and exit the installer. Then from the command line run the command "msiexec /a package.msi" and point the installer to you software distribution share to extract it. If it isn't packaged in a .msi file, you will most likely need to write some kind of batch file to do the job and tie that to your machine startup script. AppDeploy.com is a good resource for tips on deploying software, .msi or not. Customization of packages can be a more difficult task. Some vendors like Adobe will give you tools that will build a transform (.mst) file which you apply to your .msi package before you deploy it and they tend to be very straightforward. The Adobe Customization Wizard is an example of that and works for most Adobe software. Other times, you need to build the transform yourself. This can be done with the Orca tool that comes with the Windows SDK or tools such as InstEdit! can do the job easier as it is purpose build for customizing packages. That program is now also freeware but no longer advertised or supported by the company. You can load a .msi file and then make changes to the package's default settings, change the registry keys that are applied, or script batch files to run doing the .msi installation process among other things and then dump the configuration changes to a .mst that you can then apply to the package. To deploy the package, go in to your policy and right click on Software Installation and add a new package. Then point to the network location where the .msi file is located and pick from the list if you are going to Assign, Publish, or do an advance deployment of the software. You should most likely always pick advanced unless you are working with extremely simple software. Picking Publish or Assigned at this time will commit the package to the policy and you cannot delete it without deleting the whole policy, so be careful. Going to advanced will not commit the package until you actually press Okay from that dialog. In the advanced properties, look at the Deployment tab. There are a few options you can configure here, but the important and not so straight forward ones to consider are in advanced. The 32/64bit compatibility speaks for itself but the "Ignore language when deploying this package" can be important. If the person building the .msi package doesn't correctly define the package language or you are installing software that is by default for a different language, the deployment will fail. Apple seems to be in the terrible habit of doing this with every Quicktime release, so look for that if you are having problems. The upgrade tab lets you specify other packages in the same policy or in other policies that you are upgrading from, which is extremely useful for upgrading things like flash or java. Modifications is where you apply the transform file if you have one. Once you hit okay, the package and any transforms are committed and cannot be removed without deleting the policy and starting over. •Building Transforms/Deploying Java Example: Java is a fairly straightforward package to deploy. You can just drop down the provided .msi package and let it push out with generally no problems. However, java also registers that irritating justchk.exe process and pops up a system tray console to tell you java is DOING SOMETHING. Neither behavior is desirable in a managed business environment, so lets fix that. The first thing you need to do is get you hands on the installer. Go to the Java website and get a copy of their offline installer package (jre-6u7-windows-i586-p-s.exe currently) and save it to your workstation. Run it and wait for the first window to load but then do not click any options. Browse to your %temp% directory and then sort by date modified. You will see a very recent .msi file with some randomized name in the root of your temp directory (other installers will make their own subdirectory, which is nicer). Copy that msi package from the temp directory to your package share and then rename it to something nice like jre16u7.msi. Next fire up AppEditor and load that package from its network location. You will see a screen that looks like this:  Right now if you make any changes you are directly modifying a .msi package. This can do bad things so don't do that. Instead, go to Transform, New Transform... and then name you transform file something meaningful and save it in the same directory as your .msi package. Now you will see that you are working with a .mst file which layer over .msi packages and apply changes to their settings. With Java you will be primarily working in the Properties table (this will apply when you are editing most packages). The properties you want to change here are:
JAVAUPDATE = 0 RebootYesNo = No SYSTRAY = 0  This will disable automatic updating and checks, prevent it from rebooting the system, and keep the systray console from popping up every time a java applet is launched. The values will be highlighted in green when you change them, which indicates you are working in a transform. If you don't see pretty colors, then you are still working in the .msi package and are doing it wrong so don't save anything. These values are the command line switches you can define with the installer at the command line, but since we cannot use switches with a group policy deployment we need to change their defaults in a transform. To test your transform, fire up a command line and invoke 'msiexec /i "yourpackage.msi" TRANSFORMS="yourtransform.msi"' and just install with the default values. To test to make sure the transform was applied, look at HKLM\Software\Microsoft\Windows\CurrentVersion\Run and you shouldn't see a startup entry for justchk.exe or whatever the java updater process is called. Also if you go in to the Java control panel applet you will notice that the Update tab still looks active. That's because Sun, like most companies these days, has their head shoved shoulder-deep up their rear end and can't make an installation package that honors their own command line switches. Thankfully it will only check with an applet is actually launched, but if you want to be complete about disabling this then combine the software deployment policy with the follow machine startup script: code:Now we are ready to attach this crap to a GPO. *The following directions are assuming you have never done a Java package deployment to your domain before* Make the object and name it something meaningful like "Install Java Runtime Engine" and then edit the GPO. Go to Computer Config, Policies, Software Settings and right click on Software installation and tell it to add a new package. Select the package source from your package share (USE THE UNC PATH!!!) and select the Advanced radio button. If you don't, you won't be able to apply the transform. It will then pop up the properties dialog where you go to the modifications tab and select the .mst file you built. If you have prior versions if Java that you have deployed through group policy, indicate those on the Upgrades tab so it knows what policies this package is updating and it will remove the old versions for you. You may also want to select the option to remove the package when it falls out of scope, but for core plugins like this (Java, Flash, Quicktime) I don't like using that option. Click Ok to finalize the package to the GPO. Then go to Computer Config, Policies, Windows Settings, Scripts and add the above batch script to the Machine Startup entry. Make a link from the GPO to the OU where you what this to apply (this applies to machine objects, so don't drop it in an OU with just user objects) and you should be all set. •Folder Redirection: Roaming profiles can be a pain in the rear end. They're big, they slow down logon times, they balloon up in size, and do other oddities. One of the options to help correct this is to redirect Application Data, the Desktop, the user's Start Menu, and My Documents on XP and a number of other folders on Vista to a user's home directory on the network so they do not need to be synced with every logon and off event. This is done by going to User Configuration, Policies, Windows Settings, Folder Redirection a specifying the properties on each. With XP, redirecting My Documents will also redirect My Music, My Pictures, and My Videos as they are a sub-folder of that directory. Be careful when redirecting Application Data (or any other folder if you are already in production) as some applications can be poorly coded and will not like the junction point that is created. The method you use is up to you. If all users have a default drive mapping to a personal drive (let's say P:\) you could use Basic redirection and tell it to redirect without creating a username path and then set the path to something like P:\Application Data or whatever else you are redirecting. If you want to create a dedicated share or directory that all users redirect to, pick the option to create a subfolder for each user and point it to \\server\share\directory and make sure that all users have read and write access to that directory. By default when the personal subfolder is created it restricts permissions so only that user can access it. Under settings you have the option to change this behavior and also if you want to move the contents of the current folder to the redirect location. Typically you want to leave this on unless you are doing some kind of scripting to move everything all at once. •Simplifying logon scripts: Typically logon scripts are a complex mess of polling group memberships and applying drive mappings, network printers, or whatever else. With the new group policy features available in Vista, you can now define drive mappings, .ini files, registry keys, database sources, user environmental variables, and network printer mappings. The applicable settings are found under User Configuration, Preferences. If you are using direct IP mappings for printers, those are now supported as well. These are per-machine settings so you define them at Computer Configuration, Preferences, Control Panel Settings, Printers. That one in particular is a huge time saver over the old scripting methods of doing it. •WMI Filters: WMI stands for Windows Management Instrumentation. It is basically a database of properties about your system that you can query with SQL-like statements called WQL (WMI Query Language). These are especially useful for doing package deployments as you can poll information about system to ensure that it meets hardware requirements, among other things you could hack together to do crazy things with. To get started, you are going to want an easy way to browse your WMI database. For this you need the WMI Admin Tools. Be forewarned: This thing is old, works as an activex control of IE, and generally sucks. If you are going to use it on IE, you need your browser to gave protected mode off. Hopefully they write a new version soon that works as a snap-in instead of this garbage. Regardless, open up the WMI Browser tool. The very first thing you will want to go to is the binoculars browser button that will give you a big list of all available classes to poll. Manually browsing through the tree that is displayed by default will force the thing to go through and look up all associations while it expands out classes, and that is slow and often crashes the program. Good job, Microsoft. In this example, lets say we have a package that is going to install Nod32 on our workstations, but we want make sure that our old antivirus product still isn't installed before the new one goes on. To do this, we're going to do a query the installed applications and check for it being a registered product on the system. First from the Browse menu (binoculars button) scroll through the classes and find something that looks like it will work for you. Like Win32_Product. Add that class to your browse list and hit okay to bring up a listing of everything in there.  It looks like the name key is what we want to go by. So lets make a WQL statement. code:•Testing and Troubleshooting policy: Quite a few things can go wrong when policy is applying. Here are a few of the most common issues I have seen. Having your antivirus client correctly configured is a key component of group policy working correctly. If clients are attempting to pull policy off the sysvol share, this will trigger scan events by a real-time scanning engine which can cause file locks that result in policy not being applied correctly. This issue will be intermittent and very hard to diagnose as it will appear from the client end that the connection is timing out and dropping. This guide is a fairly good guide for setting up the common exclusions to Microsoft servers and services. Keep in mind that anything running a database is going to need some manner of exclusion or you may encounter problems. The eventlog (eventvwr.msc) is your go-to place to see if policy is applying correctly, with policy results being reported in the Application log. If you are pushing out application packages, one of the errors you may encounter will look like this: quote:Failed to apply changes to software installation settings. Software installation policy application has been delayed until the next logon because an administrator has enabled logon optimization for group policy. The error was : The group policy framework should call the extension in the synchronous foreground policy refresh. If you are not seeing policy being applied, attempt to manually update policy with gpupdate.exe. If there is an error at this point, there may be something wrong with the sysvol DFS share your domain controllers run. Make sure you can manually navigate to it via \\[domain fqdn]\sysvol. Also check to make sure you are pointed at your internal DNS servers an not somewhere else, as not being able to resolve the name to your packages share will shoot you down quickly. Beyond those things to check, you will most likely need to do some googling with error codes. If policy says it is applying correctly but you do not see this reflected in the eventlog or on the actual settings, then odds are the machine or user is not falling within the scope of the policy. The first thing is to check your Active Directory structure and verify that the user or machine object falls at or below the level where the link is placed and that there aren't Inheritance Blocks causing the problem. Keep in mind that machine policy will only apply to machine objects and likewise with user policy and objects. Because of this I keep all of my user and machine policy settings in discrete GPOs to avoid confusion on their scope. The exception to this may be your default domain policy as this is a good place to configure settings to which all objects within the domain should adhere to. If a quick spotcheck doesn't reveal anything out of the ordinary, your best bet is to use group policy modeling and results. Modeling is mostly used to figure out what policies are filtering down to a specific OU but won't tell you much about a specific machine. Results gives you a much more granular look at one specific machine, including which WMI filters evaluated as true or false and what security group apply so you can get a better idea of what is causing the policy to fall out of scope. When it comes to actual software deployment testing, VMWare Server or ESXi are great free tools that you can use to easily load up a single machine with a bunch of OS installs and test their installation as well as rolling back to an established snapshot. I have had a few packages (Acrobat Reader 8, Java 6u1) to which the uninstallers break and catching and testing in this environment is critical to a smooth rollout without a bunch of things breaking and people screaming down your neck. For a general hint, a large number of uninstaller errors can be circumvented by deleting the associate package key from HKCR\Installer\Products. That is about the extent of what I can think of to put in here to start. v1.1.0 9-12-08 Added transform build and java deploy example v1.2.0 9-12-08 Added WMI Filtering section v1.3.1 9-16-08 Added Testing/troubleshooting section, corrected WMI filter section BangersInMyKnickers fucked around with this message at 18:04 on Oct 30, 2009 |
#
?
Sep 11, 2008 23:29
|
|
|
|
| # ? Apr 18, 2024 04:57 |
|
|
Chiming in to say group policy has made managing a terminal server environment soooooo good. No more dumbass users accidentally shutting down the server, because that option (as well as anything else that could lead to harm) is completely unavailable to all OUs!
|
|
#
?
Sep 12, 2008 01:14
|
|
|
At my old job (Startec, now Americatel), I was able to single handedly support the entire Canadian network (two offices, around 250+ machines) thanks to Group policies. It is that powerful, and makes standardisation a breeze. And listen, don't be afraid of calling vbscripts in the GPO during logon, logoff, startup or shutdown. There are valid uses for it. I wrote a logon script that would map drives, add ODBC links, add/remove printers, and copy links and files based on both group and OU membership. Unfortunately, not many corporate clients are using Vista and its places like that there that can truly take advantage of what GPOs have to offer. Jailbrekr fucked around with this message at 01:47 on Sep 12, 2008 |
|
#
?
Sep 12, 2008 01:44
|
|
|
Jairbrekr posted:At my old job (Startec, now Americatel), I was able to single handedly support the entire Canadian network (two offices, around 250+ machines) thanks to Group policies. It is that powerful, and makes standardisation a breeze. Quoting this because it is great. For everyone else, if you want to apply a user setting on a per computer basis (regardless of who logs on) set GPO loopback processing to MERGE (or overwrite depending) Computer Configuration -> Administrative Templates -> System -> Group Policy -> Loopback Policy.
|
|
#
?
Sep 12, 2008 02:27
|
|
|
Here's a question that I've been wrestling with for some time. We want to set up group policies for users on some sort of role or location basis. Right now we're dumping everyone in CN=Users so it doesn't seem like setting up group policies on a per-user basis is really possible. We also have -great- difficulty moving people from CN=Users because of all the external stuff we have that look directly at that namespace for user queries. This is the structure I inherited and I'm being stonewalled every time I bring up a better structure so I'm not dealing with bullshit issues on 1500 clients. If somebody has a way to apply policies on a per-user basis without putting them in an OU to do so, I'm all ears.
|
|
#
?
Sep 12, 2008 02:41
|
|
|
Jairbrekr posted:And listen, don't be afraid of calling vbscripts in the GPO during logon, logoff, startup or shutdown. There are valid uses for it. I wrote a logon script that would map drives, add ODBC links, add/remove printers, and copy links and files based on both group and OU membership. Unfortunately, not many corporate clients are using Vista and its places like that there that can truly take advantage of what GPOs have to offer. You don't need Vista clients to use the new group policy features, only a Vista machine to build the actual policies. So long as the group policy extension update is installed on the XP or Server 2003 system they will apply there just fine, which is why I was trying to shift focus away from using VBScript and batch scripting. Xealous posted:Here's a question that I've been wrestling with for some time. We want to set up group policies for users on some sort of role or location basis. Right now we're dumping everyone in CN=Users so it doesn't seem like setting up group policies on a per-user basis is really possible. We also have -great- difficulty moving people from CN=Users because of all the external stuff we have that look directly at that namespace for user queries. This is the structure I inherited and I'm being stonewalled every time I bring up a better structure so I'm not dealing with bullshit issues on 1500 clients. Your best option in this situation is to get things restructured in a logical fashion and fix it. Not fun, but that should be your long-term goal. In the short term, make additional security groups and add users to and use those groups against policy security filtering to apply the policy to specific users within on OU.
|
|
#
?
Sep 12, 2008 02:46
|
|
|
How do you manage product updates with deployed software? Do you extract the updated software to a NEW folder/share and add it as a second package to the group policy object? How does it handle removing the old package and installing the updated one? Can you apply a base software install then use group policy to apply patches after? Should I patch the source and redeploy?
|
|
#
?
Sep 12, 2008 02:56
|
|
|
Balthesar posted:How do you manage product updates with deployed software? Do you extract the updated software to a NEW folder/share and add it as a second package to the group policy object? How does it handle removing the old package and installing the updated one? My general procedure is to keep everything filed in \\fileserver\packageshare\product\version#\ to make sure each version gets its own directory. With things like Flash or Acrobat Reader the installer packages are smart enough to remove the old version, but I typically don't like to leave that kind of thing up to chance. I keep a generic policy for installing Java for example, and each time a new revision comes out I do an admin install of it to it's new version directory and then add that installation package to the GPO that the software is associated with. By configuring the properties (advanced settings) of that package you are able to specify what existing packages the new one will be upgrading, and group policy will take care of surplanting the older versions you already have deployed with newer ones. With larger applications (Adobe Professional comes to mind), patches may be distributed in a .msp file. You can't just push this down to the clients and tell them apply it to themselves locally unfortunately. You need to use the msiexec switch "/update [*.msp]" to perform an in place upgrade of the package that is already on your packages share. However, clients do not know that you updated the source package so you then need to right click on package in the policy and tell it to redeploy. It pretty much does a full reinstall with the updated package source, but this can be really time intensive. A better option may be to get something like Shavlik's HFNetCheck to handle applying packages to non-Microsoft products.
|
|
#
?
Sep 12, 2008 03:07
|
|
|
BangersInMyKnickers posted:Your best option in this situation is to get things restructured in a logical fashion and fix it. Not fun, but that should be your long-term goal. In the short term, make additional security groups and add users to and use those groups against policy security filtering to apply the policy to specific users within on OU. I totally agree on the restructuring, but it is unlikely to happen in the near future. Thanks for the pointer, this put me in the right direction. If I understand this correctly, I can simply apply the GPO itself to a security group, which in turn, will filter down to user objects?
|
|
#
?
Sep 12, 2008 03:08
|
|
|
Its funny you posted this, we are working on group policy right now in my class. Its been interesting thats for sure. Especially when people in the class have restricted themselves from their own workstation.
|
|
#
?
Sep 12, 2008 03:12
|
|
|
Xealous posted:I totally agree on the restructuring, but it is unlikely to happen in the near future. Thanks for the pointer, this put me in the right direction. If I understand this correctly, I can simply apply the GPO itself to a security group, which in turn, will filter down to user objects? You apply the policy to OUs (in this case, your Users OU) but remove the Authenticated Users from the Security Filtering. With no one in the security filter, no validates as having the right membership to get the policy. Then add in specific security groups that user accounts are a member of who you want to receive the policy and they will get it.
|
|
#
?
Sep 12, 2008 03:14
|
|
|
BangersInMyKnickers posted:You apply the policy to OUs (in this case, your Users OU) but remove the Authenticated Users from the Security Filtering. With no one in the security filter, no validates as having the right membership to get the policy. Then add in specific security groups that user accounts are a member of who you want to receive the policy and they will get it. I see, so the Authenticated Users ACL would actually apply that GPO at the OU level while removing that permission ensures that it applies only to those objects that have been scoped. I assume security filtering can be used and abused on other objects as well, like specific computers and/or users?
|
|
#
?
Sep 12, 2008 03:34
|
|
|
Bookmarked, 5'd, I wish there was more I could do, your advice has already helped me out repeatedly in the past. I love you, Bangers. I love you in my knickers.
|
|
#
?
Sep 12, 2008 03:43
|
|
|
Xealous posted:I see, so the Authenticated Users ACL would actually apply that GPO at the OU level while removing that permission ensures that it applies only to those objects that have been scoped. I assume security filtering can be used and abused on other objects as well, like specific computers and/or users? Correct. By default it will not search for specific computers though, only users and security groups so you will need to add computer objects from the search list. One thing I do is make security groups for licensed software and set the security filtering scope to that group. That way, only the computers that are approved to receive the software will get it and if you need to check on how many current installs you have, just check the group membership. If you are doing this with licensed software, make sure you configure the package deployment policy so that the software is removed when the policy falls out of scope.
|
|
#
?
Sep 12, 2008 04:34
|
|
|
Is it possible to have a mandatory profile that uses folder redirection? We have a single profile for students (technically two, the XP version and Vista version) and it's set to be mandatory (renamed ntuser.dat to ntuser.man) to keep things clean and standard. The profile weighs in at about 6 megs once our basic application set is initialized.. Can I re-direct folders like appdata to a single network share that all students read from but still make it unmodifiable ala in mandatory profiles? I guess that sounds pretty impossible.
|
|
#
?
Sep 12, 2008 06:00
|
|
|
ogreboy posted:Is it possible to have a mandatory profile that uses folder redirection? Technically speaking, I don't see why this couldn't work. If you redirect all the profiles to a single common application data folder and ensure that only read permissions to those accounts apply to that directory, you shouldn't hit file locking issues. However a lot of program assume that they have write access to their %appdata% directory and things could break. It is really one of those things you will need to test yourself to see if it can be made to work.
|
|
#
?
Sep 12, 2008 06:20
|
|
|
You might want to include some information on how to write your own Administrative Templates or mention that Samba can do some cool stuff with PDC Group Policy without having to buy expensive software.
|
|
#
?
Sep 12, 2008 11:59
|
|
|
How 'granular' (not the word I'm looking for) should GPOs be? I've left our Group Policy alone since the guy who managed it left, and it seems to work. Looking at it now though, there's 49 GPOs listed, and this is for a network of 300 users. That seems like a bit of overkill. For example, he's got a separate GPO for each department printer, 3 separate proxy policies based on management level, a separate policy for each network software installer, My Docs and Application Data redirects split into 2 policies, etc.
|
|
#
?
Sep 12, 2008 13:43
|
|
|
BangersInMyKnickers posted:You don't need Vista clients to use the new group policy features, only a Vista machine to build the actual policies. So long as the group policy extension update is installed on the XP or Server 2003 system they will apply there just fine, which is why I was trying to shift focus away from using VBScript and batch scripting. I wish we had a test environment... I hate testing in production, but this sounds worth checking out. This may be a silly question, but... how do you build a policy on a Vista machine then apply it on a 2003 domain? BangersInMyKnickers posted:My general procedure is to keep everything filed in \\fileserver\packageshare\product\version#\ to make sure each version gets its own directory. With things like Flash or Acrobat Reader the installer packages are smart enough to remove the old version, but I typically don't like to leave that kind of thing up to chance. I keep a generic policy for installing Java for example, and each time a new revision comes out I do an admin install of it to it's new version directory and then add that installation package to the GPO that the software is associated with. By configuring the properties (advanced settings) of that package you are able to specify what existing packages the new one will be upgrading, and group policy will take care of surplanting the older versions you already have deployed with newer ones.
|
|
#
?
Sep 12, 2008 14:27
|
|
|
NinjaPablo posted:How 'granular' (not the word I'm looking for) should GPOs be? I've left our Group Policy alone since the guy who managed it left, and it seems to work. Looking at it now though, there's 49 GPOs listed, and this is for a network of 300 users. That seems like a bit of overkill. It may be overkill. Best practice in our organization has always been: Apply the fewest number of policies at the highest levels for maximum effect. Your OU structure should support this of course and if your OU structure is bad then you may very well need 50 policies to make everything work like you want quote:Whoa, seriously? Am I dreaming? Syano fucked around with this message at 14:45 on Sep 12, 2008 |
|
#
?
Sep 12, 2008 14:42
|
|
|
trekdanne posted:You might want to include some information on how to write your own Administrative Templates or mention that Samba can do some cool stuff with PDC Group Policy without having to buy expensive software. I haven't tried making templates since before the .admx format came about, but back then doing it manually or with any of the tools I could find was a complete son of a bitch. If you have something that makes the process a little more friendly, I would gladly work with it and do a writeup. As for Samba, I've never had the chance or need to work there so I can't really help. If someone else wants to give some information on it I would appreciate it. NinjaPablo posted:How 'granular' (not the word I'm looking for) should GPOs be? I've left our Group Policy alone since the guy who managed it left, and it seems to work. Looking at it now though, there's 49 GPOs listed, and this is for a network of 300 users. That seems like a bit of overkill. There isn't really a hard-set rule for this and it is going to depend completely on your environment. I personally have 36 active policies for my environment and I know there are some changes I could make to consolidate it down to about 30 if I wanted to. The best thing you can do if you want to begin policy consolidation is to evaluate each one and figure out what the highest level OU you can apply it to for the scope of the policy. Things that should apply globally you could merge in with your default domain policy to clean things up. Application deployment policies I would keep in to separate GPOs so that controlling the upgrade path with new versions is simpler. If you have groups of printers that apply to specific department or at least don't have use overlap between whatever group structure you use could be consolidated in to fewer policies. Policy objects have hardly any overhead unless something is screwed up with your domain, so consolidating objects is mostly going to be for each of management and your own sanity. Again, it is one of those things you are going to make judgment calls on and figure out how to apply the concept to what you are doing. Or you can just spit out a big screen cap of you directory and policy structure and ask for advice but I don't think many people would be comfortable with that. One thing I hope eventually gets added to group policy management is the ability to make a tree hierarchy in the actual GPO folder so I can file them by category. Having them sitting in a flat level mess is a bit annoying, but at least a good naming scheme can get similar ones to group together.
|
|
#
?
Sep 12, 2008 14:44
|
|
|
And it only took you ten months 
|
|
#
?
Sep 12, 2008 14:46
|
|
|
brc64 posted:Whoa, seriously? Am I dreaming? I got a huge boner when RSAT was finally released and it made my work Vista computer my favorite computer ever. Again, you don't need Server 2008 domain controllers to use most of the new features, just 2003 and the group policy extensions update. quote:I wish we had a test environment... I hate testing in production, but this sounds worth checking out. This may be a silly question, but... how do you build a policy on a Vista machine then apply it on a 2003 domain? Pushing out a new version of Java and building a transform for it is one of the things I will be working on in the next day or two. I will make a step by step guide as I do it. I will also put together information on policy modeling and testing before deployment, but for the time being get a copy of of VMWare Server and a test box that runs a few instances of XP. VMWare is great for actually testing package deployments or policy results.
|
|
#
?
Sep 12, 2008 14:51
|
|
|
Cidrick posted:And it only took you ten months And look at how amazing it is.
|
|
#
?
Sep 12, 2008 14:52
|
|
|
I've got some basic roaming profiles right now that I want to transform into either roaming profiles with redirected folders or back into plain old local profiles. Anyone know how messy that's going to be? I'm setting up some virtual test stations now but I'm curious if anyone has done it before.
|
|
#
?
Sep 12, 2008 15:34
|
|
|
I saw this thread title and assumed some lame thread asking how to do something rudimentary with GPOs. Imagine my surprise when I saw the wall of awesome text Bangers knocked out. Voted 5, bookmarked.
|
|
#
?
Sep 12, 2008 16:16
|
|
|
•Building Transforms/Deploying Java Example: Java is a fairly straightforward package to deploy. You can just drop down the provided .msi package and let it push out with generally no problems. However, java also registers that irritating justchk.exe process and pops up a system tray console to tell you java is DOING SOMETHING. Neither behavior is desirable in a managed business environment, so lets fix that. The first thing you need to do is get you hands on the installer. Go to the Java website and get a copy of their offline installer package (jre-6u7-windows-i586-p-s.exe currently) and save it to your workstation. Run it and wait for the first window to load but then do not click any options. Browse to your %temp% directory and then sort by date modified. You will see a very recent .msi file with some randomized name in the root of your temp directory (other installers will make their own subdirectory, which is nicer). Copy that msi package from the temp directory to your package share and then rename it to something nice like jre16u7.msi. Next fire up AppEditor and load that package from its network location. You will see a screen that looks like this: Right now if you make any changes you are directly modifying a .msi package. This can do bad things so don't do that. Instead, go to Transform, New Transform... and then name you transform file something meaningful and save it in the same directory as your .msi package. Now you will see that you are working with a .mst file which layer over .msi packages and apply changes to their settings. With Java you will be primarily working in the Properties table (this will apply when you are editing most packages). The properties you want to change here are:
JAVAUPDATE = 0 RebootYesNo = No SYSTRAY = 0 This will disable automatic updating and checks, prevent it from rebooting the system, and keep the systray console from popping up every time a java applet is launched. The values will be highlighted in green when you change them, which indicates you are working in a transform. If you don't see pretty colors, then you are still working in the .msi package and are doing it wrong so don't save anything. These values are the command line switches you can define with the installer at the command line, but since we cannot use switches with a group policy deployment we need to change their defaults in a transform. To test your transform, fire up a command line and invoke 'msiexec /i "yourpackage.msi" TRANSFORMS="yourtransform.msi"' and just install with the default values. To test to make sure the transform was applied, look at HKLM\Software\Microsoft\Windows\CurrentVersion\Run and you shouldn't see a startup entry for justchk.exe or whatever the java updater process is called. Also if you go in to the Java control panel applet you will notice that the Update tab still looks active. That's because Sun, like most companies these days, has their head shoved shoulder-deep up their rear end and can't make an installation package that honors their own command line switches. Thankfully it will only check with an applet is actually launched, but if you want to be complete about disabling this then combine the software deployment policy with the follow machine startup script: code:Now we are ready to attach this crap to a GPO. *The following directions are assuming you have never done a Java package deployment to your domain before* Make the object and name it something meaningful like "Install Java Runtime Engine" and then edit the GPO. Go to Computer Config, Policies, Software Settings and right click on Software installation and tell it to add a new package. Select the package source from your package share (USE THE UNC PATH!!!) and select the Advanced radio button. If you don't, you won't be able to apply the transform. It will then pop up the properties dialog where you go to the modifications tab and select the .mst file you built. If you have prior versions if Java that you have deployed through group policy, indicate those on the Upgrades tab so it knows what policies this package is updating and it will remove the old versions for you. You may also want to select the option to remove the package when it falls out of scope, but for core plugins like this (Java, Flash, Quicktime) I don't like using that option. Click Ok to finalize the package to the GPO. Then go to Computer Config, Policies, Windows Settings, Scripts and add the above batch script to the Machine Startup entry. Make a link from the GPO to the OU where you what this to apply (this applies to machine objects, so don't drop it in an OU with just user objects) and you should be all set. BangersInMyKnickers fucked around with this message at 17:07 on Sep 12, 2008 |
|
#
?
Sep 12, 2008 17:05
|
|
|
BangersInMyKnickers posted:Java stuff Will this work fine for a client that already has non-package-deployed java installed?
|
|
#
?
Sep 12, 2008 17:36
|
|
|
Java is a odd situation. Basically by default it will try to install all the versions side by side and just use to most recent one (assuming the applet honors that) so you will have a big list of Java 6 update whatever installed on your system. I'm not a fan of that behavior. If you have done all of your deployments through group policy and set the upgrades correctly on the package, it will remove the older versions when the new one goes one. If you have older versions that were installed manually or part of an image, this won't happen. To fix it, you'll need to do some batch scripting. Open up regedit and go to HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall You'll see a big list of keys with their product codes. Search through them and record the product codes for the java installs that you want removed (you may need to look at multiple machines to get them all). Now we make a batch script: code: Attach that script on to your java deployment policy.
|
|
#
?
Sep 12, 2008 18:24
|
|
|
BangersInMyKnickers posted:Attach that script on to your java deployment policy.
|
|
#
?
Sep 12, 2008 19:24
|
|
|
•WMI Filters: WMI stands for Windows Management Instrumentation. It is basically a database of properties about your system that you can query with SQL-like statements called WQL (WMI Query Language). These are especially useful for doing package deployments as you can poll information about system to ensure that it meets hardware requirements, among other things you could hack together to do crazy things with. To get started, you are going to want an easy way to browse your WMI database. For this you need the WMI Admin Tools. Be forewarned: This thing is old, works as an activex control of IE, and generally sucks. If you are going to use it on IE, you need your browser to gave protected mode off. Hopefully they write a new version soon that works as a snap-in instead of this garbage. Regardless, open up the WMI Browser tool. The very first thing you will want to go to is the binoculars browser button that will give you a big list of all available classes to poll. Manually browsing through the tree that is displayed by default will force the thing to go through and look up all associations while it expands out classes, and that is slow and often crashes the program. Good job, Microsoft. In this example, lets say we have a package that is going to install Nod32 on our workstations, but we want make sure that our old antivirus product still isn't installed before the new one goes on. To do this, we're going to do a query the installed applications and make sure SAV is gone. First from the Browse menu (binoculars button) scroll through the classes and find something that looks like it will work for you. Like Win32_Product. Add that class to your browse list and hit okay to bring up a listing of everything in there. It looks like the name key is what we want to go by. So lets make a WQL statement. code:
|
|
#
?
Sep 12, 2008 19:29
|
|
|
brc64 posted:Stupid Newbie question: how do you do this? Computer Config, Policies, Windows Settings, Scripts. Attach it to the startup or shutdown sequence of the machine. This is also the only way I know to to create a machine shutdown script that runs in the machine context and not the user's.
|
|
#
?
Sep 12, 2008 19:31
|
|
|
Great intro BangersInMyKnickers, but cached domain credentials are stored in a salted format. Rainbow tables can be used, but must be generated for a specific user name using every possible salt. A different name than administrator would complicate their use, but you can also set a registry key to only store the most recent domain login. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ set "CachedLogonsCount" to 0 to remove cached credentials, or 1 for only the most recent. http://antionline.com/showthread.php?t=264050
|
|
#
?
Sep 12, 2008 21:08
|
|
|
Oddhair posted:Great intro BangersInMyKnickers, but cached domain credentials are stored in a salted format. Rainbow tables can be used, but must be generated for a specific user name using every possible salt. A different name than administrator would complicate their use, but you can also set a registry key to only store the most recent domain login. Good to know about salting the domain credentials, I wasn't aware of that. I just have an extreme hatred for lanmanager and lm hashes because of their terrible design and never want them on a system. We had an incident a few years back were some student employees booted to a rainbow hash cd and cracked the local admin password, installed a keylogger, and then kept making bogus service calls to try and get us to log in locally on the machine. Those little shitheads gave us quite the wakeup call.
|
|
#
?
Sep 12, 2008 21:26
|
|
|
BangersInMyKnickers posted:I just have an extreme hatred for lanmanager and lm hashes because of their terrible design and never want them on a system. Glad it's a lazy Friday; I just set our LAN Manager authentication to "Send NTLMv2 response only. Refuse LM & NTLM" and broke a bunch of poo poo  Glad nobody was really around to care... Any clue why this would've caused multiple users to get locked out, all of whom are running at least XP Pro SP2?
|
|
#
?
Sep 12, 2008 21:30
|
|
|
Mierdaan posted:Glad it's a lazy Friday; I just set our LAN Manager authentication to "Send NTLMv2 response only. Refuse LM & NTLM" and broke a bunch of poo poo Where was authentication failing to? We have a NetApp filer and access to that became problematic with only NTLMv2 until we applied a firmware update. Network appliances would be the most likely source of trouble, or some clients applied the policy at different times and stopped talking to each other properly. A safer method of switching would be to increment to "Send NTLMv2 response only, refuse LM" and then bump it up to "Send NTLMv2 response only, refuse LM and NTLM" a few days later. If you have something that still wants to authenticate with LM, well... ouch. Also check your domain and forest functional levels for the hell of it. Test this stuff on individual systems first for the love of god.
|
|
#
?
Sep 12, 2008 21:37
|
|
|
BangersInMyKnickers posted:Where was authentication failing to? We have a NetApp filer and access to that became problematic with only NTLMv2 until we applied a firmware update. Network appliances would be the most likely source of trouble, or some clients applied the policy at different times and stopped talking to each other properly. A safer method of switching would be to increment to "Send NTLMv2 response only, refuse LM" and then bump it up to "Send NTLMv2 response only, refuse LM and NTLM" a few days later. If you have something that still wants to authenticate with LM, well... ouch. Also check your domain and forest functional levels for the hell of it. I didn't get time to look closely before backing the change out, but my inclination is that it was Outlook trying to auth via NTLM to Exchange 2007. Though, while our Domain functional level is definitely at 2003, but apparently Forest is at 2000 (we have no other domains, nor non-2003 DCs). I didn't even know that until just now, would that be forcing something to use a lower level of NTLM authentication than v2?
|
|
#
?
Sep 12, 2008 21:39
|
|
|
Mierdaan posted:I didn't get time to look closely before backing the change out, but my inclination is that it was Outlook trying to auth via NTLM to Exchange 2007. I was more asking to make sure you didn't have some old nt4 controllers sitting around or something weird like that. Kerberos is what you should be authenticating with in in a domain unless you are going by the IP instead of hostname, the other machine isn't on the domain, or you ports aren't open right. Then it will default down to NTLM or LM. Any of those apply to you?
|
|
#
?
Sep 12, 2008 21:54
|
|
|
This is an awesome thread, I'm just getting my feet wet with GPO now and had really wanted to use it for app deployment. Unfortunately I work for a small IT consultant and we can't bill for doing things like flash/acrobat/java deployment via GPO although it would make my life a lot better to not remote into machines and see all the little java icons in the taskbar bugging the poo poo out of the user. As a side note I think WSUS is something everyone should have if only because you can see way ahead of time if some XP system's auto updates took a dump which happens on like 1 in 4 xp systems at some point it seems.
|
|
#
?
Sep 12, 2008 22:15
|
|
|
|
| # ? Apr 18, 2024 04:57 |
|
|
Okay, so I just realized that I have been telling people to make registry changes with batch scripts when the new features let you do it in a much easier way. I guess old habits die hard. Going back to the java example where you need to change registry keys to disable the autoupdater, instead of doing a reg query and then dropping in a registry merge, just go to Computer Configuration, Preferences, Windows Settings, Registry. Make a new registry items that will update the registry values of EnableJavaUpdate and NotifyDownload to 0. Loads easier than going the batch script route.
|
|
#
?
Sep 12, 2008 22:22
|
|