Ben’s Tech Blog

We recently noticed that there were some blank entries in the GAL, in other words, there was a completely blank line between some objects in the GAL. If I double-clicked on any of these blank entries I’d receive the following message:

The properties dialog box could not be displayed. Internal MAPI error: An unsupported interface was requested of an object property. Contact your administrator.

The blank entries where only included in the ‘online’ GAL, offline address books were not affected, as well as Outlook Web Access and Outlook Mobile Access.

It turned out that someone had modified the security ACL of an OU, and Exhange no longer had access to view these users. The OU contained user objects for users who had left, but they were still mail-enabled, although interestingly enough, hidden from address lists. Once I set the permissions of the OU back to the default (which includes rights for the Exchange Domain Servers and Exchange Enterprise Servers, and rebuilt the domain RUS object the blank entries disappeared.

The Windows Server 2003 Active Directory Users and Computers snap-in (ADUC) includes the ‘Saved Queries’ feature which allows you to save queries for future use. One of the nice things about this feature is that once you save the query you can view the actual LDAP query string. You can then proceed to customize the string, or copy and paste it into a script for example.

The biggest shortfall that I see with the ADUC find/search utility, is when it comes to selecting a Condition, and this is where you may need to customise a LDAP query. The drop-down allows you to choose from Starts with or Ends with etc, but what about Contains? If you want to search all users to find a description for example that contains a word or phrase anywhere in the description you can’t using the standard method. This is where using a saved query comes in handy.

The easiest way to construct a custom query is to start by creating a query that is close to what you would like to search for. In this case you could construct the query by using either Starts with or Ends with as the condition, and then modify the query string once its saved. I’ll run through this now.

1. Right click on Saved Queries, then Select New -> Query.
2. Give the query a name, then click on Define Query
3. In this example, we’ll just search users, so select Custom Search from the drop-down.
4. Click on the Field button and select User -> Description.
5. Select Starts with and enter the text that you want to search for, e.g “test lab”, then click on Add.
6. Click on OK. Notice that the Query string field is now populated. Highlight and copy the Query string text and click on Define Query again.
7. Higlhight the criteria that you added before and click on Remove.
8. Click on the Advanced tab, and then paste in the query text
9. At this point you can now customise the query text. To search for descriptions that contain “test lab”, you need an asterix (*) on either side of the text. So you need to add an asterix to the end of the search text so that it looks like the text in the image below.

10. Click on OK, then OK again.
11. Right click on the Saved Query and click on Refresh. You’ll see that users with “test lab” anywhere in the description will be listed, for example, a user with “Sydney test lab user account” as the description would be listed in the results.

Of course, customizing your LDAP searches can allow you to do a lot more than what I just demonstrated. If you start exploring ADSI Edit you’ll find more attributes of objects that you can search on that aren’t listed in the ADUC search fields. For example, if you wanted to search for all users that have mailboxes on a particular Exchange server, you could use the msExchHomeServerName attribute. Your LDAP query would like something like this:

(&(&(objectCategory=user)(msExchHomeServerName=/o=OrgName/ou=AdminGroupName
/cn=Configuration/cn=Servers/cn=ServerName)))

The LDAP queries that you construct aren’t limited for use in ADUC, you can implement them in scripts that perform LDAP queries or third-party software that performs LDAP lookups for example. The ADUC saved queries feature just allows you to construct the basic query, from there you can modify it to do what you need. I should point out that you can also construct LDAP queries and view the LDAP string when you create Query-based distribution lists, or Exchange Address Lists/GALs.

We recently had hundreds of users leave our organization due to a takeover and we needed to remove each user from all of their distribution lists and security groups. Although we wanted to remove the users from all groups, I wanted to ensure that we had a record of what groups they were members of in case we needed to add them back in. The script that I created removes the user from all of their groups, but first records the list of groups they are member of and exports the list into a report file. We’ve already had two cases where we disabled a user and removed them from all groups and was later informed that the user’s termination date had been moved forward so their account needed to be reinstated. The user’s previous group membership listed in the report file made it very easy for us to add them back into the groups that they should belong to while they are still with the company.

I’ve added the script here.

Despite being an excellent product, Microsoft Exchange has some limitations when it comes to email management for teams. There are several approaches to implementing a team email delivery/management solution with an ‘out of the box’ Exchange deployment but unfortunately each solution has a drawback.

This topic has been on my mind a fair bit recently as we have been setting up team messaging solutions under a new company structure. In the past I’ve implemented custom form solutions to manage team messages so that all of the desired features are incorporated, however custom forms are not used by this company and they don’t wish to use them moving forward. With that in mind, we had to look at the default solutions and compare their behaviors before making recommendations to the various teams.

The following table illustrates the solutions that we offered to each team with the behavior of the replies to messages that are sent to the team. Interestingly enough, accessing a shared mailbox via OWA was often the best solution for customer service teams that wanted to be able to track their sent items.

When decommissioning Exchange servers, I like to stop the Exchange services or shut the server down for a week or so before uninstalling Exchange from the server; that way if I have overlooked anything and an issue arises I can bring the server back online very quickly. This week I was planning the removal of an Exchange 2003 public folder server. I re-homed all of the public folders and waited until they had all disappeared from the public folder instances container for the pubic store on the server in question. The next day I shut the server down and after a while noticed that there was mail queuing on the front-end servers to the public folder server that I had shut down.

At first, it didn’t make sense to me why the mail was queuing for the public folder server that I had shut down - there were no public folder replicas on the server, so in my mind there was no reason for any mail to be delivered to that server at all. After closer inspection of the messages in the queues, I could see that the messages were queuing for public folders that never had replicas on the server in question, which led me to believe that the server was playing some type of ‘bridgehead’ role that I didn’t know about.

I came across this Technet article that explains how public folder routing works and it cleared up the confusion that I had. In summary, when a message is received by a front-end server (or any Exchange server that doesn’t contain a public store), the server queries Active Directory for a public folder server that contains a copy of the public folder hierarchy. The transport then delivers the message to the server that contains the hierarchy based on the result of the AD query. The server with the copy of the hierarchy then determines which server or servers contain a replica of the public folder that the message is addressed to and passes it on to the appropriate public folder server containing the replica.

As the article explains, the query result will always be the most recently deployed public folder server for the routing group. This was consistent with the issue that I had – the server that I shut down was in fact the most recently commissioned public folder server, so it made sense why the messages were queuing up. Of course, I powered the server back on to allow the messages to deliver, and then began to look at how I should approach the situation.

Uninstalling Exchange would had been the easiest fix, but I still wanted to keep the server offline for a few days before uninstalling Exchange. The article mentions that you can modify the msExchOwningPFTree attribute on the public store object, and this is the solution that I decided to go with:

“Editing the msExchOwningPFTreeBL attribute directly is not possible, because it is a back link. However, you can delete the msExchOwningPFTree attribute on a specific public store object. If you delete the msExchOwningPFTree attribute on the public store object that is unavailable, the msExchOwningPFTreeBL back link attribute will be automatically removed from the back link list. By changing the msExchOwningPFTree attribute, you change the list in the msExchOwningPFTreeBL list, and thus alter the public folder routing decision.”

The article doesn’t explain how to atually edit the attribute so I thought I’d post the solution here so that others could refer to it. Note that after I cleared the attribute I wasn’t able to mount the store without putting the attribute back in place again. Also, you can avoid this scenario by mounting an empty public folder store on each front end server. The solution below however provides an easy way overcome a mail routing issue similar to the scenario that I had, particularly if you have already shut down the server and can’t bring it back up immediately.

If you want to temporarily prevent a particular public store from being used as the initial delivery point for messages destined for public folders in a routing group, you need to clear the msExchOwningPFTree attribute on the public folder store object using ADSI Edit:

• Launch mmc.exe
• Add the ADSI Edit snap-in to the console
• Right click on the ADSI Edit container and click on Connect to
• Choose the Select a well known Naming Context option and select Configuration from the drop-down list, then click on OK.
• Expand the Configuration container, then expand out each container as follows: CN=Services then CN=Microsoft Exchange then CN=YourExchangeOrg then CN=Administrative Groups then CN=AdminGroupofyourPFServer then CN=Servers then CN=YourPFServer then CN=InformationStore and then click on CN=StorageGroupContainingYourPFStore.  In the pane on the right you see the public store object listed.  Right click on the object and click on properties. 

  

• In the list of attributes, double click on the msExchOwningPFTree attribute and then click on Clear and and then OK

  . 

  

Once I cleared the msExchOwningPFTree attribrute I shut the server down again.  I sent some test messages and monitored the queues on the front-end servers.  The messages were delivered to the public folders, and no messages queued on the front-end servers. When it came time to remove Exchange, I put the attribute back in place so that I could mount the public store, take a final backup and uninstall Exchange.

I’ve added 2 scripts that I created recently to the scripts page. Check out the links below.

VBScript - Export a list of Mail Enabled Public Folders visible in the GAL
VBScript - Export a list of all Mailboxes with their home Server, Storage Group and Database.

We had a user contact us yesterday who had deleted a public folder that contained a large number of subfolders and items. This is not usually too much of a drama, we have a 14 day deleted items retention period on our public folder stores, so its usually just a case of adding the DumpsterAlwaysOn key to the registry on the client, browsing to the parent public folder, clicking on Tools, then Recover Deleted Items and selecting the folder to recover. This time however, we received the following message when attempting to recover the folder:

“Outlook was unable to recover some or all of the items in this folder. Make sure you have the required permissions to recover items in this folder, and try again. If the problem persists, contact your administrator.”

Naturally, we checked the permissions; in fact we tried to use the Exchange service account mailbox to recover the folder but received the same error. We also tried temporarily disabling Trend ScanMail (our Exchange level antivirus) in case it was interfering with the recovery process. The folder would actually appear in Outlook temporailly before it produced the error, at which point it would disappear again.

We did a lot of searching around to find a solution; most forums and articles that we came across either suggested to check permissions and disable the antivirus like we had done or use isinteg to repair the database (which I’m not such a fan of). Others suggested that it wasn’t possible to recover the folder at all. After some more searching I came across a tool called MFCMapi.

Once I downloaded MFCMapi, I was able to browse the folders that had been deleted. I tried to recover the folder that the user had deleted, but it produced an error. However, because I was able to browse the sub folders, I attempted to recover one of the them and it was successful. I tried several folders, some were successful and others were not. I figured if we could get some of the contents back it would be better than nothing. It appeared that some of the contents were corrupted, which would explain was why Outlook was unable to recover the folder. Outlook doesn’t provide the option to recover the sub folders, and this is where MFCMapi really helped. I was able to restore the majority of sub folders with 5 or 6 of them not wanting co-operate.

You can download MFCMapi from here.

Once downloaded and extracted, run MFCMapi.exe and close the welcome window. To browse deleted public folders do the following:

1. Click on the Session menu and click on Logon and Display Store tables. You’ll see that it uses Outlook to connect to the stores, select your Outlook profile and click on OK

2. Click on the MDB menu and select Open Public Folder store. Tick the Use Admin Privilegesbox and click on OK.

3. Expand Public Root and IPM_SUBTREE. You’ll then see the public folders that you would normally see under “All Public Folders” in Outlook.

4. Navigate through the public folder tree until you get to the parent folder of the folder that you are trying to restore.

5. Right click on the parent folder and select Open Deleted Sub Folder Table. A new window will open displaying the deleted subfolders. Right click on the folder and select Restore Deleted Folder. A box will open up that allows you to select to also restore the subfolders, tick that option and click on OK. You may receive an error message stating that the folder couldn’t be restored, much like I did.

If you don’t receive the message then the restore was successful and you should see the public folder and items appear in Outlook. If not, don’t panic just yet, you may be able to restore some (hopefully most) of the subfolders. If this is the case, just navigate through the folder structure and attempt to restore each folder. Unfortunately it doesn’t allow you to select multiple folders using CTRL or SHIFT; I spent a fair bit of time restoring each folder one by one.

Considering that I was able to restore most of the folders and items that had been deleted, I was happy with the result, and so was the user. MFCMapi proved to be a very useful tool and I’m sure there will be times when I’ll need to use it again.