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.
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.
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.
Comments (0) 
Themocracy