[flouie]

Hello,

I don't know much about the working of BES as I inherited it from a previous admin but I do know Exchange. I have 5 Exchange 2003 servers and 1 BES server and 1 Exchange Frontend server. I installed Microsoft KB926666 patch on 1 of the Exchange server to test before installing it on the rest. After I installed it and BES users on that Exchange server can no longer send, forward, or reply to any emails from their Blackberry, but they can receive email just fine and they can send and receive from their Outlook client just fine also. I've checked all permissions and the besadmin account have the correct permissions, I rebooted both Exchange and BES servers and still nothing works. I had to uninstall the KB926666 patch and everything is working again.

Does the KB926666 patch need to be install on the BES server as well? Because if it does then the patch needs to be deployed to all Exchange and BES servers at the same time. I hate to deploy a patch to all the servers without verifying it actually won't break something like the Blackberry sending issue I have now.

Any advice from all you BES experts out there is greatly appreicated.
Any insights on how BES and Exchange are integrated would be helpful too.

Thanks in advance.

[jibi]

I've yet to hear of any the patch impacting users' ability to send. The patch fixes calendaring issues with CDO.dll and does not appear to include updates that would affecting emailing. The patch does need to be installed on the BES, though. I would go ahead and install it there and see if it corrects the issue. We plan to install it on all servers (BES and Exchange) at the same time, though.

[|||||||]

It's the mark of the beast, it technically has 666 in it twice

[jrbes]

We are having the same issue, permissions have been revoked from the BES admin account (revoked send as, receive as, and admin info store). RIM had us go back and put the permissions back in. KB912918 talks about it as well. I moved my account and mailbox to the affected BES\Exchange domain and I am able to send now - just waiting to hear back from users that had experienced the issue prior to the rights being restored.

Appears that Store.exe version of 7560.23 and higher are impacted by this.

[Dookie]

Originally Posted by jrbes

We are having the same issue, permissions have been revoked from the BES admin account (revoked send as, receive as, and admin info store). RIM had us go back and put the permissions back in. KB912918 talks about it as well. I moved my account and mailbox to the affected BES\Exchange domain and I am able to send now - just waiting to hear back from users that had experienced the issue prior to the rights being restored.

Appears that Store.exe version of 7560.23 and higher are impacted by this.

Exactly! I've got some issues when we applied some unimportant hotfix which updated our store.exe file.
See this article: Users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003
and especially this one:
âxxx8364;xxx339;Send Asâxxx8364;xxx65533; permission behavior change in Exchange 2003

That's what i found.

Edited:
Check this: Microsoft Exchange Server 2003 Service Pack 2 with a Store.exe file version of 7650.23 or higher has revoked "send as" permission.
That KB updates store.exe to version 6.5.7651.61.
There you go....

[Kul]

Just to clarify, because the thread has confused me abit, I know that KB926666 needs to be installed on BES and Exchange - but I wasnt aware that it revokes the send as permissions.

Surely as Jibi said, this is or should be just a cdo change and not a store version change. Looking at the files it installs looks like store version is changed too. If this is the case, then I guess send as permissions will be revoked s long as your store is under the version listed.

[jrbes]

According to DART support, if your version of Store.exe is 7560.23 or greater (ours is 7560.28) it will impact your Exchange, the manual change is needed. We added the service account to a Exchange Admin group that has the correct permissions and it is working now.

[jibi]

So we applied a MSFT patch a few months ago that revoked these permissions. We did a manual fix to resolve the issue. Now if we apply the new patch, we have to repeat the samn damn process?

[jrbes]

I vote that someone else tries this first and lets us know!!!

[Snyder81]

Originally Posted by jibi

So we applied a MSFT patch a few months ago that revoked these permissions. We did a manual fix to resolve the issue. Now if we apply the new patch, we have to repeat the samn damn process?

I installed KB926666 on Friday on our Exchange org as well as the BES and did not see any affect on BES service account permissions. No problems sending/receiving email after I installed it. FYI, with the previous "fixes" I had to implement with the Exchange permissions issues a while back, I ended up creating a group in AD that all user objects inherit the necessary permissions from. The BES service account is part of that group. I am currently running BES for Exchange 4.1 SP2 in both test and production environments.

[Dookie]

Originally Posted by Snyder81

I installed KB926666 on Friday on our Exchange org as well as the BES and did not see any affect on BES service account permissions. No problems sending/receiving email after I installed it. FYI, with the previous "fixes" I had to implement with the Exchange permissions issues a while back, I ended up creating a group in AD that all user objects inherit the necessary permissions from. The BES service account is part of that group. I am currently running BES for Exchange 4.1 SP2 in both test and production environments.

Have to confirm that. Once you did the change in AD and run the script there seems to be everything ok.

I've ended up granting explicitly "Send As" permission on whole OU, other permission on Exchange EVS level.

[jibi]

Originally Posted by jrbes

I vote that someone else tries this first and lets us know!!!

I'm installing it tonight, so...

[jibi]

It's been about 2.5 hours since we installed this patch across all Exchange and BES servers. No permission changes were needed and no adverse impact has been seen, although we have previously run the 'dsacls' command to correct the impact of the previous Exchange patch from Microsoft (few months ago).

I always drop a copy of CDO.dll into the c:\windows\system32 folder (just a habit; may not even be required anymore), so I had to stop the services and copy the DLL from the Exchsrvr\bin directory to the system32 directory and restart the services. That was really the only extra step.

Calendar synchronization works. Tested with creating an appointment on my calendar in OWA and it synchronized immediately to the device. I removed it from the device and it removed it from OL. Created an appointment on the device and it immediately updated in OL. Removed it from OL and it fairly quickly removed it from the device. Hope that helps.

[txag94]

Originally Posted by jibi

It's been about 2.5 hours since we installed this patch across all Exchange and BES servers. No permission changes were needed and no adverse impact has been seen, although we have previously run the 'dsacls' command to correct the impact of the previous Exchange patch from Microsoft (few months ago).

I always drop a copy of CDO.dll into the c:\windows\system32 folder (just a habit; may not even be required anymore), so I had to stop the services and copy the DLL from the Exchsrvr\bin directory to the system32 directory and restart the services. That was really the only extra step.

Calendar synchronization works. Tested with creating an appointment on my calendar in OWA and it synchronized immediately to the device. I removed it from the device and it removed it from OL. Created an appointment on the device and it immediately updated in OL. Removed it from OL and it fairly quickly removed it from the device. Hope that helps.

Excellent! Thanks for the update after applying! It does help.