Unable to Mail Enable Public Folders

One of my clients had a recent issue. He wanted to create and "Mail Enable" a new public folder in their Exchange 2007 infrastructure. He used the UI (not the Exchange Shell commands) for the purpose. He did not receive any error messages when he right clicked the folder and selected "Mail Enable" from the context menu. However, then he wanted to verify the operation and tried to open up the properties of the folder. At this step, he received the following error:

The Active Directory proxy object for the public folder '\Root Folder\Sub Folder' is being generated. Please try again later. It was running command 'get-mailpublicfolder -Server 'ServerFQDN' -Identity "\Root Folder\Sub Folder".

We checked almost everything including the "msExchOwningPFTreeBL" attribute. Even if we created a top level folder, the behavior was the same. Mail Enable was running with no problems, but when we checked the properties of the public folders, we were getting the exact same error message.

Because we had retired the Exchange 2003 servers recently, I even thought this issue might be related. However I was not able to find anything to prove this.

My long Google search did not return much results either. Then, in Technet Forums, I found a post which was about a similar problem. In their case, they were working on the RTM version and they noticed that the "System Attendant " service had been shutting itself down intermittently. Their solution was to make sure that the "System Attendant" was running. After reading this post, we immediately checked and verified that the service was already "up and running". Then we thought, since we have nothing to lose, we could try restarting the service. After "System Attendant" restart, we "Mail Disabled" then "Mail Enabled" the public folder. Finally, when we checked the properties of the public folder, we got no errors and were able to verify the new e-mail address of the folder.

I really don't know what was wrong in the first place, but apparently "System Attendant" was not performing properly. Then the service restart fixed the problem. Since the other services do not depend on the "System Attendant" anymore, the service restart did not require us to take all the other Exchange Server services down.

We spent a couple of hours on this "interesting" problem, and with this post I am hoping to save you same time if you run into the same issue.