Troubleshooting group policy can be a complex task. The vast amount of settings configurable using group policy and the fact that it depends on other technologies such as DNS and Active Directory don't make it any easier. The best practice when creating a new group policy is to restrict it to a test group before implementing it in a production environment (see Chapter 20, "Group Policy," for more information). Unfortunately, sometimes even when taking every precaution things do not go as planned and the end result is not what you expected. Do not fear; help is here! The next few sections go over fixing the most common problems and even preventing them in some cases. Backing Up and Documenting Group Policy ChangesGroup policy is backed up as part of the System State, which the SBS Backup Wizard includes automatically. However, restoring a whole server due to a group policy issue is not an attractive proposition. Although using the GPMC has improved the manageability of Group Policies, it is still possible to find yourself in a situation where you can't roll back to your original configuration. One practice that can save you a lot of headaches consists of documenting and individually backing up any changes you make to group policy. The simplest approach (and one that can potentially save you hours of troubleshooting) is to keep a copy of the group policy report before and after you make the changes. The steps are presented here:
Additionally, before modifying anything on the Group Policy Management Console, it's always a good idea to make a backup of your existing settings in case you need to roll back to them. To back up group policy objects on the Small Business Server domain, follow these steps:
Follow these steps to restore a group policy object:
General Troubleshooting GuidelinesIf you just applied a group policy and you are not seeing the results you expected, the first thing you should remember is that changes made via group policy are not immediate, and some even require a logoff or even a reboot. By default, computers have a 90-minute group policy refresh interval while Domain Controllers have only 5 minutes. However, to prevent network degradation due to a group of computers requesting group policy updates at the same time, there is a random offset time that can vary from plus or minus 30 minutes. In other words, when you change group policy settings, it can take up to 120 minutes before it is actually applied. If you want changes to occur immediately, you can open a command prompt on the client and run GPUPDATE, which refreshes the group policy settings. If you need to determine whether a group policy is being applied to a specific user and/or machine, you can open a command prompt and run GPRESULT on the affected device. You get a short report with the name of each policy (divided on User or Machine policies) and information on whether it is applied. Also, remember that several of the built-in GPOs found in SBS have their User or Machine settings disabled to speed up the loading process. If you modify the existing policies, make sure that you are doing it on the right location. There is also a server-side tool called the Group Policy Results Wizard that can be used to determine which GPOs are applied and the resultant set of policy. You can access this tool by opening the GPMC and right-clicking on Group Policy Results to bring up the wizard (see Figure 21.4). Follow the wizard to select the computer and the user you want to probe, and you will obtain a report detailing everything applicable to that user/machine combination. Figure 21.4. The Group Policy Results Wizard.Finally, another common source of errors in group policy is incorrect DNS configuration. Group policy depends heavily on Active Directory and DNS. You must make sure that your server and every workstation are set to use the SBS DNS server. Your ISP DNS servers must never be used to resolve DNS queries inside the SBS domain because unpredictable results might occur and group policies might not even load. If you are still experiencing issues with group policy the following whitepaper outlines additional troubleshooting steps and techniques used to determine the cause of the problem: http://www.microsoft.com/downloads/details.aspx?FamilyId=B24BF2D5-0D7A-4FC5-A14D-E91D211C21B2&displaylang=en. Troubleshooting Folder RedirectionMost folder redirection problems are normally caused by incorrect NTFS permissions issues rather than group policy problems. If you have asserted that the folder redirection policy is being applied to the users and still it's not working, you might be experiencing a permissions issue. Reopen the share root folder that has each user's redirected folders and verify that the NTFS permissions are correct. Of particular importance is that the Creator Owner group has Full Control over Subfolders and Files only and that the user (as a member of the Domain Users security group) must have Create Folders/Append Data permissions to the root folder. Remember that the user-redirected folders will be created automatically when the folder redirection group policy is applied. In that process, the NTFS permissions are set so that each user is the owner of his own folder. Also, permission inheritance is blocked, and only the user and the Local System account have Full Control access over those folders. However, to create those folders, the user must have enough permissions on the root of the share. Note One important side effect of automatically creating the user redirected folders on the network share is that the administrator (or anybody else for that matter) no longer has access to each user's files and settings. Although this is certainly desired in some environments, there might be situations where the administrator (or other users, such as a manager) should have access to those folders. You can find more information in the following Microsoft KB article: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q288991. |