Exchange Server administrators typically use Group Policy settings to control the way Outlook is configured for the end user. Unfortunately, Group Policy-based configurations don't always work as intended. You can use these five steps to troubleshoot Outlook Group Policy settings when things go wrong.
1. Check the administrative template version.
If your Outlook Group Policy settings aren't being applied correctly, check the version of the administrative template you're using. The
Suppose you have the Group Policy settings working correctly for Outlook 2010. If you were to upgrade to Outlook 2013, those Group Policy settings would not apply because the underlying templates are version-specific.
Organizations that have used Office for many years often accumulate multiple administrative templates. It's important to make sure you're applying the Group Policy settings to the correct template. The administrative templates exist side-by-side in the Group Policy Editor, so it's easy to accidentally click the wrong template.
2. Check for contradictory policy settings.
You might discover that some of your Outlook Group Policy settings aren't being applied correctly. In these situations, do some research and determine if any contradictory settings are in use.
When enabled, some Group Policy settings cause other settings to be ignored. For example, the DisablePST and PSTDisableGrow settings are commonly used to enforce an organization's policies for using PST files. However, if the DisableCrossAccountCopy policy setting is enabled, the DisablePST and PSTDisableGrow policy settings are ignored.
3. Check the resultant policy.
One of the best things you can do when troubleshooting Outlook Group Policy problems is to examine the resultant policy. Group Policies are hierarchical and can potentially be made up of a combination of user and computer settings applied at the domain, site, OU and local computer levels of the Group Policy hierarchy. By checking the resultant policy, you see how these policy elements come together for a particular user on a particular computer. You can see which policy settings are in effect and where those settings come from.
To examine a resultant policy, open the Group Policy Management Console, right-click on the Group Policy Results container and select the Group Policy Results Wizard command from the shortcut menu. At that point, simply follow the wizard's prompts to specify information such as the user name and the computer name. When the wizard completes, you can view the Group Policy settings that apply to the specified user and computer.
4. Make sure the policy is being applied.
If none of the Outlook Group Policy settings are being applied, check to see if the problem affects everyone or if it's isolated to specific computers. If you find that the problem is computer-specific, the Group Policy settings you implemented may not be applied to that computer.
To troubleshoot this, examine the resultant policy to make sure there aren't exceptions being made for the computer account or the user account. If the problem still exists, it's possible that the policy settings simply aren't being applied. When this happens, verify the computer's network connectivity and its domain membership. Make sure the user is actually logging into the domain. If it all checks out, use the GPUPDATE /FORCE command to manually apply the Group Policy.
5. Verify the system time.
If all else fails, check if the clock on the workstation is having issues with Outlook Group Policy settings. If the time is correct, make sure the time zone is also correct.
Windows uses Kerberos-based authentication, which is a time-sensitive protocol. Kerberos will break down if the workstation clock is out of sync with the server clock by more than a few minutes. The authentication process will also break down if Kerberos stops working. Depending on your versions of Windows, clock skew might not immediately present an error message. Instead, the system might simply behave strangely.
If you try these five methods but still have trouble, dig deeper into the computer's logs for clues as to the cause of the problem.
About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as the CIO for a nationwide chain of hospitals and health care facilities, and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.
This was first published in December 2013