blogs.teztech.com

A customer of mine has a voice mail system that forwards .wav files to the Exchange Server email address. They also have a Blackberry Enterprise Server (BES) that (on good days)  keeps their Exchange Server mailboxes in sync with their Blackberries. Naturally enough, these users would like to listen to their voice mails on their Blackberry units. The emails are already there on the Blackberry with the .wav files downloaded. All they needed was the ability to play the .wav file attachments.

It turns out that the ability to listen to .wav files was added to Blackberry Enterprise Server 4.1 Service Pack 2. We were only running Blackberry Enterprise Server 4.1, so an upgrade was in order. After downloading the 225MB “upgrade” file, the upgrade program managed to run just long enough to wipe out our Blackberry Server. The error message I was getting said something about being logged into a different account than the one that started the setup program. I might have even believed that message if I weren’t so very careful about logins. After a sort time of trying to get things fixed on my own, I decided to wait until morning to call BES support.

With the first guy Keven, from BES support on the phone I uninstalled the original BES installation and downloaded another 225MB file (this time, the full setup with the service pack included). We also checked a bunch of permissions related to the Windows user account named bes that I had setup for the BES service to run under. After waiting for the monster download to complete, I finally got the software installed. Things seemed to be working, but I eventually got reports from my users that they couldn’t send emails from their Blackberries. Time for another call to BES support.

This time, I got Brandon. Together we sent some test messages that all failed and checked about a zillion permissions for the bes account. Eventually Brandon tells me it’s all Microsoft’s fault and we need to get a hotfix mentioned in a MS Knowledgebase (KB) article. With the information from the MS KB article, I finally got BES working again (I hope). FWIW, here is the email I sent to Brandon after I got things working:

---

The Send As permissions for the bes service account we set never did work, but with the MS KB article, I figured out how to fix it and my fix seems to be working. I thought you might be interested in why what we did didn’t work and how I fixed it:As you said, all the information is in the MS KB article. I would paraphrase the problem this way:

MS stores email related permissions in both Exchange Server objects and augmented Active Directory objects (such as Users). Previously, there was a global “Send As” permission that applied to user’s mailboxes that could be granted at the Exchange Server level on Exchange Server objects such as the mailbox store. The latest patches from MS removed the global Exchange Server level “Send As” permission. Now the only way to grant Send As permission is to grant them on the individual mailboxes associated with Active Directory users.

Ideally, there would be a way to globally grant the bes service account Send As permission for all the individual mailboxes at once. This is what we attempted to do when we added the bes account with Send As permission for “User objects” to the domain object in Active Directory Users and Computers. In my case, however, this grant won’t work. The reason it won’t work is that in our domain here, the individual Active Directory User objects are set to not inherit any permission from their container. You can see this in the User’s properties in Active Directory Users and Computers: Click the Security Tab, then the Advanced button – the “Allow inheritable permission from the parent to propagate…” check box is cleared. Why it is set this way? I don’t know, but it must be common. As long as the User objects (and their associated mailboxes) don’t pick up permissions set at the container level, no amount of waiting is going to get the bes account the Send As permission it needs.

Here are some different ways to fix the permissions problem:

1) Apply the hotfix mentioned in MS KB article 907434. I didn’t try this, but I assume it works.

2) Go to each Blackberry user in Active Directory Users and Computers and enable permission to propagate. There are a lot of different permissions and I have no idea what kind of problems this might cause. I wouldn’t recommend this solution.

3) Go to each Blackberry user in Active Directory Users and Computers and grant the bes account Send As permissions. This is the safe, straightforward solution.

4) Create a program or script to do (2) or (3) automatically. In the MS KB article 907434 there is a script you can use to identify the accounts that might need Send As permissions, then grant the Send As permissions to all the individual User accounts at once. Automating option (3) with this script from the MS KB is the solution I chose. I found the script to be pretty well written and fairly easy to use. However, I am familiar with this type of scripting.

In my case, now I’ll have to remember to execute step (3) each time I add a new Blackberry user to our system.

I still say the entire BES architecture is way, way too complicated and brittle. If RIM is interested, I could write a specification for a much simpler and much more robust set of programs that could accomplish the same tasks with fewer resources (both computer and people). I know it’s unlikely, but I throw it out there mostly in frustration with the continuing sad state of BES.

In the short term, it seems to me like you either need to require the hotfix (maybe secure permission to distribute it from MS) and/or figure out a way for your Setup and Blackberry Manager programs to grant the bes service account the Send As permission for individual Users. Obviously, this can be done with some Active Directory programming, but that is a little tricky in your case as you are instructing us users to create the bes account without Domain Administrator permissions and run your Setup program as the bes account. Overall, I think it would be wise for you to take complete responsibility for the bes account – creating it, granting it the correct permissions, a menu option to fix permissions and passwords later, etc.. That way, Setup can be run as Administrator. As long as you don’t take full responsibility for the bes account and the delicate set of permissions it requires, we will all pay the price on the back end with technical support calls.

---

I know this post is a long, crazy rant. I’m mostly posting it here in case anybody else runs into this problem.