Guy's Troubleshooting Advice | When troubleshooting, ask your self what was the last thing I did? Now undo those settings and see if that cures your problem. |
| Q1) Have you refreshed the Group Policy settings? | Run Gpupdate /force |
| Q2) Why is my Group Policy not working? | a) Is the user and the computer in the correct OU? Check which OU the user and the computer is located. b) Check Block Inheritance. c) Possibly a No Override policy is preventing your settings. d) Has the user 'Apply Policy' Permission? Or have they 'Deny Policy' Permission? |
| Q3) Could it be a synchronization problem? | There are two factors in Group Policy synchronization. Active directory replication from the FSMO master to the other DCs. Also FRS (file replication services) replicating the very group policies under the sysvol\sysvol folder. Be ruthless, logon an as an administrator at the Windows 2003 server, which holds the FSMO PDC Emulator master and see if that cures the problem. |
| Q4) You want to know which Policies are in force |
|
| Q5) Can I refresh the policy without a reboot? | That depends! Most do. Gpupdate /force refreshes the policy instantly, however some policies require a reboot or a user to logon again. For example, Software policies. |
| Q6) Why can't I open the policy editor? | Perhaps you only have read only permission. Full control is needed to open the GPO. |
| Q7) What causes 'Failed to open the Group Policy object' | Most likely a DNS problem. Try NSLookup, Ping, Ipconfig to confirm or deny the diagnosis. |
| Q8) Why do I get the 'Missing Active Directory Container' message? | Hopefully, its just a DC replication delay. Try and force domain replication in Active Directory Sites and Services, drill down trough Server to NTDS and synchronise. |
| Q9) How can I stop this error: 'The Feature you are trying to install cannot be found'? | Check the share and NTFS permission on the .MSI package folder. |
| Q9) My Script Policy does not work | For specific help with logon scripts, Check out this section |
| Q10) My VBScript Policy does not execute via Group Policy? | The script runs perfectly as a console user, but not as a logon script on a Workstation. Solution make sure that on the Workstation, the primary DNS server = Domain controller. If necessary set the DNS server manually rather than relying on DHCP I thank Bob Phillips for this tip. |
| Q11) Spaces in Script names? | Beware spaces in logon script names. E.g. Head Quarters.vbs . Try Head_Quarters.vbs. Thanks again to Bob Phillips for this tip. Thanks again to Bob Phillips for this tim |
| Q12) Where do I start creating a Group Policy? |
|
| Q13) If all else fails | Check the Event Viewer. Filter the Application Log for Source = SceCli. Really we should have checked here FIRST! If you find a suspicious entry, then check the ID numbers and details in TechNet. |
| Q14) I have made a terrible foul up. My policies are a disaster | Run DcGpoFix to return the default Group Policies to their original state.
|
Troubleshooting Group Policy Tips
GPMC (Group Policy Management Console) Introduction
GPMC (Group Policy Management Console) Introduction
Remember that Microsoft designed the GPMC for Windows Server 2003 rather than W2K. Get your copy of GPMC.msi as a download from Microsoft's site. While I am assured that the GPMC will work on Windows 2000 Domains, I have not got it to run. (However, I have not tried that hard as I now prefer Server 2003.)
The GPMC unifies Group Policy management across your Active Directory forest. Before the GPMC, administrators needed multiple tools to manage Group Policy; the Microsoft Active Directory Users and Computers, the Delegation Wizard, and the ACL Editor. Not only does the GPMC integrate the existing Group Policy tools, but also it brings the following exciting new capabilities:
- A user interface that makes it easier to create and edit each Group Policy.
- New WMI filtering means that you can apply policies to particular machine, or only if there is enough disk space.
- Interfaces to Backup, restore, import, and copy Group Policy Objects (GPOs).
- Simplified management of Group Policy-related security.
- Reporting for GPO settings and Resultant Set of Policy (RSoP) data.
Windows Desktop Search and the implications on WAN performance
Windows Desktop search (WDS) is a great tool to help you to search through the unwieldy plethora of documents or emails that you may have scattered across your desktop. With the addition of 3rd party IFilter add-ins, it makes it even easier to find what you are looking for.
As of version 3.01, Desktop search has disabled the indexing of online mailbox on a default installation due to performance implications on the Exchange server side. Companies sometimes have the need to still run Outlook in Online mode due to security requirements of not having local OST’s, or they need real-time email for business purposes. With some of those requirements, companies have the need to also have fast message/document retrieval which Windows Desktop Search can surely do without a problem.
WDS does have some group policy settings that will now allow online indexing of mailboxes and a listing of all the settings for WDS 4 is at http://technet.microsoft.com/en-us/library/cc732491.aspx. This setting that allows indexing of online mode Outlook profiles is "Enable Indexing uncached Exchange Folders". Once this is deployed via group policy, WDS will now start indexing online mode Outlook profiles. This of course could put a huge strain on the server as all of the users data is being indexed if deployed to a large user base. Recommended guidance states that you should deploy this policy to smaller subsets of users to prevent possible server performance problems. This is similar guidance to what Microsoft recommends for cached mode deployments.
With that said, I would like to now take us down a road where certain combinations of WDS policies can not only affect Exchange server side performance, but can also have serious implications on WAN performance. If you currently have a centralized Exchange deployment and users are accessing all of their email across WAN circuits, read on.
Let’s say you have an administrative assistant running in cached mode that needs to gain access to another users complete mailbox with a requirement that data in that mailbox is easily discoverable. This requirement can be easily met by using Windows Desktop Search and is very common in law firms. A default Outlook 2007 installation will have the "Download shared folders (exclude mail folders)" option selected for their user profile, so if this assistant had previously opened a another users non-email folder such as Contacts, Calendar and Tasks, WDS will index those items without any issue. This feature unfortunately does not meet the complete requirement as we need to index all items in the other users mailbox. After Full mailbox permissions is added for this assistant, they can now add this other users mailbox to their profile to view their data. Once you do this, you will now see that WDS will still not find any email items unless you have selected the folder in the mailbox and then performing the search. Everything so far is the default behavior.
WDS has a feature which will allow you to index online delegate mailboxes and is deployed via the GPO setting "Enable Indexing of online delegate Mailboxes". Once this setting is deployed, any user that has another users mail related folder in their profile will now get indexed. So that seems like a good thing, no? Well, we all know that indexing any type of mailbox in online mode will increase overall performance on the Exchange server and if users are doing this over a WAN, you will now see increased WAN utilization while WDS is indexing this data making direct RPC calls to the Exchange server. If this setting was deployed to a large user base while there are a number of profiles that have other mailboxes added to their profile, you could potentially saturate this network circuit. Your network administrator at this point would obviously not be too happy and your users would then start complaining that email access is really slow or Outlook may get disconnected due to this saturation. Our best practices dictate that this setting should be deployed to smaller user bases at a time to prevent increased client traffic to the Exchange Server.
Imagine deploying this policy to 1000 users all accessing Exchange across a WAN and all have an added mailbox to their profile. By default, WDS will only index 120 items per minute which should help keep the Indexing traffic under control. If all users workstations were indexing this amount of data at a time, we would be seeing about 120,000 items per minute of traffic. Couple that with any attachments that WDS is configured to index for such as PDF or Word documents, and this will make for a very bad network day.
There are ways to change the amount of items that are indexed per minute by modifying the GPO setting "Enable Throttling Online Mailboxes". Setting this policy to a lower value will help reduce the amount of items that are indexed per minute per mailbox and should also help keep some of the network traffic down to a minimum. The caveat here is that it will take longer to index these mailboxes. Keep in mind that is still going to be direct RPC traffic to the Exchange server with minimal amount of throttling.
To help reduce some of this overhead, Outlook 2007 has a registry entry ( CacheOthersMail ) that will allow you to cache other users mail folders in an OST file. This was first introduced in KB955572 and requires that you disable the downloading of headers. This was then rolled up in to the Outlook 2007 post SP1 Sept. 24, 2008 hotfix package (957909) . If the indexing of delegate mailboxes policy has been deployed to these users and you add this Outlook registry key, you will now see a mixture of traffic being generated by WDS. One is direct RPC traffic to the Exchange server and the other is Outlook FxGetBuffer function calls or otherwise known as Outlook sync (ICS). The Outlook sync traffic will become more prevalent over time as the other users mailbox is cached locally in the OST file. FxGetBuffer calls are a lot less expensive than direct RPC calls to the Exchange server, so deploying the CacheOthersMail registry key may help with overall WAN utilization during initial indexing. You still need to plan on increased WAN traffic as synch traffic coming from many clients could also cause potential WAN degradation issues.
WDS Registry Reference
Registry data to index data in your mailbox if you have an Online mode profile
Key: HKLM\software\policies\Microsoft\windows\windows search
DWORD: PreventIndexingUncachedExchangeFolders
Value: 0
Registry data to index shared mailboxes:
Key: HKLM\software\policies\Microsoft\windows\windows search
DWORD: EnableIndexingDelegateMailboxes
Value: 1
Registry data to change the amount of mail items that are indexed per minute.
Key: HKLM\software\policies\Microsoft\windows\windows search
DWORD: EnableThrottlingOnlineMailboxes
Value: 120
Accepted Values (Default: 120, Min: 6, Max:600)
Outlook Registry Reference
Registry data to Cache others users mail data in an OST
One-off users
Key: HKCU\Software\Microsoft\Office\12.0\Outlook\Cached Mode
DWORD: CacheOthersMail
Value: 1
GPO deployed
Key: HKCU\Software\Policies\Microsoft\Office\12.0\Outlook\Cached Mode
DWORD: CacheOthersMail
Value: 1
One of the most taxing combinations of WDS settings with relationship to Exchange Server and WAN performance is deploying "Enable Indexing uncached Exchange Folders" and "Enable Indexing of online delegate Mailboxes" simultaneously. If you also index attachments which is the default behavior, this could put increased burden on network resources and could cause considerable downtime for your users. Deploying these settings needs to be carefully planned out especially in centralized Exchange installations to prevent the situations that I describe.
