Category Archives: Exchange 2003

Why are my nested UDGs not being upgraded to USGs?

Posted on by — No Comments ↓

Without going into too much backstory for Exchange admins who already know why UDGs need to be upgraded to USGs for ACLs on public folder and mailboxes, I was having an "intermittently persistent" issue where UDGs that are members of other USGs are not being automatically upgraded to USGs.  Without the automatic upgrade, access to the resources the parent USG has been assigned will not work.

I started Googling to see what I could find.  The org-level attribute to control UDG conversion was not set, nor has it ever been in my environment.  UDGs are being successfully upgraded by Exchange; it is just nested UDGs that were having a problem.  Then I found the reason, and there is actually a KB article for it: 898082.

By design, for performance reasons, when a UDG is a member, whether direct or nested, and the parent group is a USG, Exchange will not convert the UDG to a USG.  Only if the parent group, the one actually being assigned to a resource, is a UDG at the time it is added to the resource, Exchange will convert the parent group and enumerate all members for other UDGs to be converted.

This makes sense so Exchange doesn’t enumerate members every time a group is added to a resource to check for member conversions.  Since conversion is meant to be a one-time event, performance would be adversely affected if it had to enumerate all members every time just to check for a UDG that happened to added since the last time.  So the enumeration only happens if the parent group is a UDG, which implies that the group has never been assigned to an Exchange resource and the one-time conversion can occur.

Cannot install Exchange 2003 SP2 on an admin machine with Outlook?

Posted on by — No Comments ↓

As all Exchange admins should know, Exchange (and/or ESM) and Outlook are not supported on the same system for a variety of reasons related to MAPI service providers.  However, there is a KB article (here) that tells you how to edit the registry to tell ESM to use mapi32.dll in the \exhsrvr\bin folder instead of the system32 directory.

I was installing ESM on a new application terminal server this morning and could not get SP2 to install.  The error was that Exchange 2003 was not installed and, therefore, you cannot apply a service pack to it.  But I had just installed ESM right before the SP install.  After some troubleshooting, I discovered that I had prematurely created the registry key as described in KB 329136.

The article clearly states to install ESM and the service pack(s) before creating the key.  Apparently, this is why, since the setup routine sees that registry key and it breaks something in it.  Deleting the key and rerunning the SP setup allowed it to proceed normally.

I assume you would also have to delete the key before upgrading to a future service pack, so if you use the key to allow public folder management, remember that its presence will inhibit service pack installations.

Updated Last Backup Report script

Posted on by — No Comments ↓

I had previously posted (here) a script to create an email that reports the last full backup time of every database in the organization.  There wasn’t too much in the way of error correcting, so the script in my environment was failing to send anything when an Exchange server went offline recently (but is still in AD).

I have updated the script, which can be downloaded here, to not error when this happens and include if it is unable to connect to a specific server and read the last full backup time.  The HTML rendering didn’t look right for the server reported with an error, and I couldn’t figure out why, so also updated how the table is built.  Now the report is one big table instead of every server in its own table.

Updated Exchange ActiveSync disable script

Posted on by — No Comments ↓

I previously posted (here) a script to disable Exchange ActiveSync for unauthorized users.  The script is based on using the dn of one or more groups to determine authorized users (i.e., if you are in the group, you are allowed).  This method recently failed me (twice) because some of the groups were renamed by another admin to make them more readable.  Not only were the display names changed, but the objects were renamed as well, so the cn and dn were changed.  This means my script couldn’t find the groups I had hard-coded, which isn’t good scripting practice anyway.

I have updated the script, which can be downloaded here, to search for the groups based on their objectGUID, which never changes no matter what you do to the object (rename, move, etc.).  Instead of hard-coding the dn of the object, I hard-code the objectGUID.  Then I bind directly to the object based on the GUID to retrieve its dn, which is used in the search filter to find the users I want to modify.

Note that ADO allows you to bind to an object given just its GUID, without having to specify other connection parameters.  You can also use the hexadecimal or binary format of the GUID in the connection string; AD will figure out which format you are using. I used the binary format in my script so that I could just copy and paste the value from Hyena into my script without having to convert to a hex value.

OWA access to public folders via front end hangs on Loading…

Posted on by — No Comments ↓

I just resolved an issue that started the other day where using OWA to access the public folders through a font-end server would result in a poorly-formatted toolbar and the word Loading… in the leaf pane.  Access to mailboxes was just fine, and it would work when using the Basic client; only the Premium client would exhibit the behavior.  Accessing the public folders directly via the back-end server worked just fine.

Because it wasn’t a content issue (mailboxes displayed fine) I could ignore permissions being the problem.  Knowing that everything except the content comes from the front-end server (stylesheets, scripts, controls) I started focusing on file version mismatches between the front-end and back-end.  Any patch that affects the rendering of OWA needs to be applied to the front-end first, and then to the back-ends.

I checked for hotfixes on both servers and they showed the same number of patches installed (based on KB article numbers).  The cause started to show itself when looking at directory structures.  The front-end server’s highest numeric directory in /exchweb was 6.5.7651.9, but the back-end server’s highest directory was 6.5.7651.25.  Researching what hotfix has a build number of 7651 yielded KB 911829.  This hotfix was released in April, but was rereleased in May as v2.

I patched the front-end server some time ago, but the back-end servers were only patched recently with this hotfix.  I used Microsoft Update to install the patch on these systems.  So what happened is that Microsoft rereleased the hotfix with newer files and a newer build number, but kept the article number under which it is published the same.  Microsoft Update doesn’t detect that a newer hotfix is available when the article number remains the same.  Downloading the v2 hotfix and running it on the front-end server created the 6.5.7651.25 directory and resolved the issue.

So this issue was caused by Microsoft not using good enough detection methods in Microsoft Update, and by me for not installing the hotfix on all the servers at the same time.  The latter is easy enough to correct, but I doubt that the former will be fixed anytime soon.

Change users’ default calendar permission (and email the users and admin)

Posted on by — 2 Comments ↓

Our IT Leadership team decided that it will promote more effective collaboration if the Default calendar permission for all IT employees is set to Reviewer (instead of the Default of None). As with many of my scripts, I started with the work Glen Scales has already done. Go there for information on the prerequisite for using this script to make the change (the need for ACL.dll).

Glen’s script uses an input argument of a server name. My distributed environment doesn’t allow for such a broad application, so I use the membership of a DL that contains the IT personnel. This DL actually contains other DLs, so I separately use another script by Richard Mueller that enumerates nested groups and puts the results into a domain local group that is used for other purposes.

After getting the group members, I loop through each member for only those with a mailbox that isn’t hidden. For those who haven’t been touched by the script before, a function is called that uses CDO to log into the mailbox, enumerate the calendar permissions looking for the Default entry, and change it to Reviewer. The user’s local FreeBusy Data folder is also updated to set the Default to Editor since that permission goes hand in hand when setting permissions on the calendar.

To keep tabs on who the script has touched, a notation is added to extensionAttribute4 (customizable). Those with that notation are skipped in the future. Then an email is sent to the user informing them of the change. I chose to do this because Exchange users may be used to the fact the the Default permission is None; this way they are aware that their calendar is open for viewing. It also helps with new employees who are not aware of this "policy" and can mark items as Private as necessary.

Finally, an email is sent to the admin with the results of the job run. It includes the display name, mailbox server, and whether the permission was set or the object skipped (to catch entries that slip through my filter). I have scheduled this to run weekly, and I will get an email each time so I know that the script is successfully running and which users are being modified.

All of the variables that require customization are near the top. These are for mail configuration, search filter, and the notation parameters for touched mailboxes.

Download it here or copy below.