One of the benefits of having a calendaring application is to use
it for resource booking such as conference rooms, special equipment
or actually anything that needs to be shared.
The following article by Markus Klein, published at www.msexchange.org is
a very good guide to configuring such resources and working with them:
I know what you are thinking-is he serious?!?!
Actually I am serious and as someone that has taught AD classes I have to say
that GPO is the heart of AD. It is the most flexible tool to be used to harness the
power of AD. On the other hand I have seen it become a curse when it is overused
or used incorrectly.
In this post I would like to outline the overuse of GPOs. When a large number of
GPOs is created management becomes complicated and in some cases it may become
GPO settings accumulate when several GPOs apply to an object if none of the settings
collide. If the settings do colide the rule of thumb is that the “closest” GPO to the object has
If additional factors are involved such as ‘Block inheritance’ or ‘No override/Enforce’ are also
involved it can be quite complicated to decipher which settings apply to a specific object.
That’s the reason why it is recommended to use a minimal number of GPOs.
An additional tool that might help you get out of a bind if you have a large number of GPOs
is the Group Policy Management Console. This tool(add-on) provides a dedicated interface
for managing and more importantly understanding GPOs.
Using this tool you can understand which settings are configured and which GPO(for each)
owns each setting. This can be achieved by using the “Group Policy Results” branch.
The wizard hiding behind the branch enables you to enter the computer and user name you
wish to analyze and provides the exact settings that apply to them on the “Settings” tab found in
the left pane.
You can download GPMC at:
Ok,so I have been dragged to a technical topic when actually all I wanted to say was-Please
do not create too many GPOs… 🙂
When you work at a multinational/multilingual company the OWA interface’s language might become
important. Currently (Exchange 2003) provides the language of the interface based on the settings
configured on the IE used to access OWA.
The problem is that at times your users might be logging on to OWA from different locations
such as airports or Internet cafes which may block the IE settings. In that case your users
might get the interface in a different language then the one they are used to see.
To prevent this from happening you might want to hard code the language used by the OWA interface.
The following KB article explains how to do it:
The problem is that as you can see it isn’t that simple. Tal H. (Thanks!!!) created the DLL
file needed for the English language and I have it attached here.
[Disclaimer-Use this file at your own risk. I (or anyone else) do not take any responsibilty
for any damage,direct or indirect, that might be caused by using the attached file.
The file is provided as is,no warranties!!]
(Rename the file to AcceptLanguage.DLL)