Wednesday, June 28, 2006

BlackBerry Enterprise Server 4.1: free of issues, runs on SBS server, and FREE?????

That's right folks, BlackBerry Enterprise Server - or more specifically BES Express - is a relatively new product from RIM that is free to BlackBerry Subscribers, runs on existing servers - such as Small Business Server 20003 - and does not experience the nasty issues we've blogged about this past week. The reason for the give-away, well RIM does have to compete with the Windows Mobile Technology from Microsoft.

Today I had my first successful deployment of BES Express, and found it to be a far easier project than deploying the regular BES. Not to mention, the customer saved over $4000.00 in hardware and software costs.

Traditionally BES required its own Windows 2003 Server with NO exchange installed on it and NO Outlook -- the MAPI client was flaky and calendaring was an issue if you tried any other setup. But the BES Express version has none of these issues.

Standard deployment takes about 90 minutes. The server supports up to 14 users. Each user must visit RIM's website and sign up for their own, individual, license (BES Express is not licenses to companies).

If you would like the benefits of BES Express such as:
  • live synchronization
  • control over blackberries from the server
  • remote wipe and lock abilities
  • flawless synchronization not dependant upon the Redirector or Web Client...

contact us and we'll get you started. There is a link to our contact form near the top of this blog, on the right side, just use it to submit your info.

-- Karl J.

Wednesday, June 21, 2006

BlackBerry issues - final step...

One more thing to make things work - reboot your PDC.... If you are not sure what that means... reboot your main server (so if you have Small Business Server, it would be that). This is critical.. I've found out that even though everything may appear to be set right, nothing really is until a reboot. Go figure..

-Karl J.

Update to BlackBerry: Problems sending messages when using Enterprise Server

I forgot to mention one - very important - step that needs to be done. If your users were Domain Admins, even if you strip the Domain Admin rights from them, they will still be considered a protected account. Therefore it is necessary to follow a few additional steps to do that. Here is the informaiton you will need for that:

(UPDATE ON THIS: I am sort of inserting this paragraph after the post was published. I am still debating whether this is really necessary, especially if you strip Domain Admin rights. On one hand research suggests that it is... but then I was able to get around this for some users).

Special rules for adminSDHolder Protected Accounts
If you use the script to grant the Send As permission for a mailbox owner that is also a domain administrator, the Send As permission will not be effective. We strongly recommend that you do not mailbox-enable user accounts that have domain administrator rights or that are adminSDHolder protected.

The adminSDHolder object is a template for accounts that have broad Active Directory administrative rights. To prevent unintended elevation of privilege, any account that is protected by the adminSDHolder object must have access rights that match those that are listed on the adminSDHolder object itself.

If you change the rights or the permissions on the adminSDHolder object for a protected account, a background task will undo the change within several minutes. For example, if you grant the Send As permission on a domain administrator object for an application service account, the background task will automatically revoke the permission.

Therefore, you cannot grant the Send As permission to an application service account for an account that is protected by the adminSDHolder object unless you change the adminSDHolder object itself. If you do change the adminSDHolder object, this will change the access permissions for all protected accounts. You should only change the adminSDHolder object after a complete review of the security implications that may occur with the change.

To associate a mailbox with an account that is protected by the adminSDHolder object, follow these steps:
1. Start the Active Directory Users and Computers management console.
2. On the View menu, make sure that the Advanced Features option is selected. If this option is not selected, the Security page will not be visible for User account objects.
3. Create an ordinary user account to act as the mailbox owner.
4. Assign the ordinary user account a mailbox on an Exchange server.
5. Open the properties of the new mailbox owner account.
6. In the Exchange Advanced box, grant the Full Mailbox Access permission to the protected administrator account.
7. In the Security page, grant the Send As permission to the protected administrator account.
8. Click OK to exit the properties of the mailbox owner object.
9. Right-click the mailbox owner account object, and then click Disable Account to disable the account for all logons.

BlackBerry: Problems sending messages when using Enterprise Server

Many users that are currently utilizing BlackBerry Enterprise Server are experiencing a problem sending messages. Basically the message attempts to send and comes back with a red "X". The issue is documented by BlackBerry and Microsoft, however the information provided has proven inaccurate to a degree, at least in my experience. I am happy to announce that there is a fix for the problem, one slightly different than what is suggested.

First off, a little backgroun. If you are running Microsoft Updates on your MS Exchange Server than you are experiencing the problem. The same is true if you applied the hotfix described in "“Send As” permission behavior change in Exchange 2003", Article 895949, of the Microsoft Knowledgebase. Basically the behavior of the "Send As" feature has changed, and been torn away from the previous setting that controlled it - known as "Full Mailbox Access." According to Microsoft, the reason there is an issue to begin with is due to BlackBerry's installation and security assignment procedure that improperly utilizies the "Full Mailbox Access" setting. Microsoft suggests that they are simply enforcing a behavior in security that has been documented a long time ago and simply been patched now.

The solution to this problem is described by Microsoft KB-912918 and BlackBerry KB-04707. (NOTE: if the BB KB article link fails, increase the last number in the h-link incrementally as new versions will have higher numbers). However, it is my view that the articles miss out on vital information. So, I've written out the procedure with additional - critical - information. The revised procedure I've used successfully is as follows:

  1. Stop the BlackBerry Router first (contrary to 04707). This prevents users from sending. If a send is made during this procedure, all changes will be undone.
  2. Go to Active Directory and REMOVE all Domain Admin / Administrator privlidges from the users that have BlackBerries. If not, your changes will be automatically undone within 60 mintes of you doing them (again not documented). Currently there is no work around.
  3. Go to the domain level and assign BESAdmin (or whatever you use) "Send As" rights (in Security Tab) to the *User Objects*, from the Advanced Button. This will propagate to most users but not all (Microsoft KB-912918 has the details).
  4. Go to the users that were Admins before and go to Properties > Security > Advanced. You will likely have to add BESAdmin to their list. When doing it, make sure to switch to USER OBJECTS first, and then check "Send As". Failure to use User Objects will be a problem, so dont miss that.
  5. Wait 20 minutes for the cache to clear and start BlackBerry Router.

This does clear up the issue, I've been able to do it successfully on multiple servers. Keep in midn that the alternative is not to do Microsoft Updates or not apply the hotfix, but then you are left with a potential security problem. It is a catch 22. My oppinion, I rather keep MS Update and deal with issues if they arise.

-Karl J.

Friday, June 02, 2006

Security Issues You Need to Know About

I think most of us glance at Microsoft Security Bulletins and count on Windows or Microsoft Update to handle things, but sometimes that's not enough. Having a reasonable secured network is a multi-step process, but even wtih all precautions in place the threat of hackers is real.

Recently Microsoft published a bulletin - like all the others - named MS06-019 (kb: 916803) called Vulnerability in Microsoft Exchange Could Allow Remote Code Execution. In fine print it is labeled as "Critical", but we already know that Microsoft Critical Updates offer a broad range of software patches.

Before I tell you why you need this updated *immediately* applied to your Microsoft Exchange 2000 or 2003 server, I suggest you go and get it. Otherwise you may join a group of network owners that experience a chain of events that goes a little like this:
  • User receives a calendar appointment, it is auto accepted. Nothing catches it as unusual - after all, its just a calendar appointment - with a little code to it that exploits a hole in Exchange.
  • The sender of the appointment now has full control of your server - without your knowledge.
  • The sender goes in and does a few things to cover his tracks like: change your backup jobs so they appear to be running each night without actually backing anything up (for example changes the job to catalog or index, rather than back up).
  • Disables all logging features.
  • Installs various mail server updates.
  • Spams for a while.
  • Formats your servers C drive (erasing most data and killing your server).
  • leaving you with no server, no data, and no backups.

Can this happen to you? Yes - I've seen it. Can you prevent it - yes. Go - now - and do your windows updates. Switch your system to Microsoft Update to get comprehensive protection. Keep in mind you need Microsoft Update to install larger updates to Windows and patches to other Microsoft Applications, otherwise you remain an open target for hacker.

This article is based on: http://www.microsoft.com/technet/security/bulletin/MS06-019.mspx .

- Karl J.