It's Now Safe To Write Vista Software

• By Doug Barney
• 03/07/2007

Ironically, because Microsoft is a commercial enterprise and not open source, it's free to establish a vision and push it to the hilt (incidentally, this is an area our latest magazine, Redmond Developer News, covers intensely).

One of our favorite tools is Visual Studio, which -- if not the best IDE out there -- has to be in the top three. The latest update makes Visual Studio more compliant with Vista, which is a good thing. ISVs and corporate developers can and should build apps that exploit Vista's new security features first, and user interface improvements second.

VMware-Microsoft Scuffle Continues
Last week, we told you that Microsoft is refusing to license low-end versions of Vista to run on the Mac in virtual machines. Microsoft cited security concerns, which seemed like a pretty random argument to some critics (like me).

While I'm no expert in virtualization, the people at VMware are, and they also saw a certain speciousness in Microsoft's contention. And like me, they took their concerns to the Internet.

I found this all based on the fine reporting of NetworkWorld's John Fontana, whom I hired for the newsweekly. VMware, Fontana writes, wrote an entire white paper contradicting Microsoft's claims.

What's really amazing is that a large company can crank out an 10-page white paper less than a week after the topic comes to the fore.

Microsoft didn't write a white paper in response. Instead, an executive wrote a blog which reads more like a white paper. More interesting than the blog are the fawning comments underneath from what are obviously Microsoft employees!

Here's what Fontana had to say.

Microsoft-Google Scuffle Continues (This Time, Redmond Is Right)
Microsoft this week took Google to task for using whatever content it can find -- regardless of copyright. And as a writer, I've got to back Microsoft on this one.

Microsoft argues that Google often offers full access to books, movies, TV shows and other types of media without compensating the creator.

In fact, as soon as I finish this newsletter (which I desperately hope Google will pick up!), I'm going to finish my April Redmond print column where I argue that Web sites are trying to kill print by stealing print stories and offering them online. And if print was to be killed off this way, Google and Drudge and all those hideous, amateur-hour blogs would have nothing to talk about.

Tell me where I'm wrong at [email protected]!

Doug's Mailbag: The Hows and Whys of a BlackBerry Bust
This Monday, we ran a letter from Rann, an IT manager who wondered if Microsoft's Exchange Server DST patch may have been responsible for his company's BlackBerrys' sudden inability to send e-mail. Here are some readers' suggestions -- and criticisms:

I can empathize with the author, as I too was a 'victim' of the Exchange KB926666 patch. I spent many hours on an Enterprise Exchange upgrade this weekend, and ultimately decided it was easier to go with the flow than buck the system in this case.

I applied the patch on Sunday morning, and began receiving complaints of missed messages some 24 hours later. I initially sent messages to several BlackBerry users, and received replies from most. Suspecting this issue may be related to the recent patching, I called RIM for support. I waited for over three hours in the RIM support queue before being led through a series of steps to remove our BES Service Account from the Domain Admins group, and replacing Send As, Receive As and Administer Information Store permissions for the service account on the Information Store. The RIM tech politely referred me to several Microsoft articles, and advised the system would work fine if I followed the instructions in the articles.

After considerable testing with mixed results, I found I was unable to receive messages from three of 70 BlackBerry users, located in five mail stores. I too added the BES service account to these users accounts, and literally watched the BES account be removed every hour. (I never saw the "big picture" until hours later.) I started looking for a common thread, and only determined that all three users' mailboxes were located in the same mail store.

I again called RIM for support, believing that the problem was isolated to a single mail store. While waiting in the RIM queue for another three hours (true story), I actually read Microsoft KB907434. I then combed through all 40 groups each of these three users were members of, and found one of them to be in "Print Operators" and two in the Server Operators and Account Operators group. I reluctantly removed these users from the 'protected' groups, and stopped the BlackBerry Router Service for 20 minutes as outlined in BlackBerry Doc ID: KB04707.

Shortly after stopping the BES Router service, the RIM tech came on the line and I explained my actions. He recommended I stop all BES services and wait for 20 minutes. I did my best to entertain him for a half-hour, and again sent test messages to these three users after restarting the BES services. Much to my surprise, I was able to send and receive messages from all three users.

The bottom line is: This patch will strip any account with "Send As" permission for users in 'Protected Groups' within an hour. I ultimately realized that I needed to modify my behavior in order to make the system work. Since RIM and Microsoft will inevitably release more patches built around this framework, we can either scramble for a workaround each time or just comply now. Microsoft has been pushing for administrators to use the "least privilege" concept for several years, which is evident by this patch. RIM recommends creating separate accounts for administrators with a BlackBerry account, which I initially disagreed with (for about 12 hours).

My recommendation is to remove any BlackBerry user from a "Protected Account" as outlined in KB907434 and create a separate account for any users that need elevated privileges on a "Protected Account."
-Anonymous

I had the same problem only worse: We maintain both BlackBerrys and Goodlink devices! In the KB article, Microsoft writes that the patch is due to customer requests, but I think that Microsoft is tired of losing business to Good and RIM for mobile e-mail access and this is its way of sticking it to the smaller guy. This is just a very thinly veiled attempt to hassle people into using OMA through Exchange.

The two-account solution worked for us. It's a bit cumbersome, but it really only affected the accounts of Exchange admins and our domain admins who are all technical enough not to get too confused by the change. I half-expected Microsoft to force everyone to have separate accounts (I guess I shouldn't say that too loudly).
-Stephen

Unfortunately, this is a known issue that first came up back in April, I believe. I was unaware of this issue, and in June I set up WSUS to push updates to all of our servers and workstations, and then happened to be going to a Microsoft TechNet event a couple of days later. The morning I woke up and was heading to the event, I noticed that I had not received e-mail for quite some time, and I could not send, either. I had Idokorro software (amazing stuff for IT guys with smartphones of almost any kind) loaded on my BlackBerry, so I was checking logs and restarting services on the way there (I was not driving). When I got to the office later on that day, I still couldn’t figure out what had happened. Then after much Googling, I finally found that it had to do with the update, and the fix you have listed took care of it for me. Simple little one-liner in a command prompt took care of it!
-Christopher

In BlackBerry's article ID#11415718, they list the steps to do the updates. Step #5 in their article says to run the 'SendAsPermissionTool.' Did he do that step?

I am currently doing this and there were many things to do: latest Exchange SPs, latest BlackBerry SPs, update clients, update BlackBerry devices via PUSH, run the SendAsPermissionTool, apply specific Exchange Server DST patch, run Microsoft calendar update tool.
-Rick

The solution to Rann's problem is indeed the Microsoft patch for KB926666 (personally, I think it's the KB article number that's the true culprit). Had a heck of a time with this one when I installed it several months ago. Of course, if he had installed the original MS patch KB916803 closer to when it was released (in May 2006), it would be a complete non-issue now.

However, the issue is most likely that his BESAdmin account is still a member of what Microsoft refers to as a protected group. One of the reference articles in the maze of links, and the one that finally helped me solve the problem, is Microsoft Knowledge Base article KB817433. Rann needs to make sure that his 'BESAdmin' account is not in any of the groups mentioned in the article, and then wait the minimum 15 minutes for AD replications to take place so that changes are made.

As I discovered when I implemented this patch (or the earlier iteration of it), Microsoft did not make it simple to implement. You have to read all the related documentation and make sure all your Is have been dotted and Ts crossed. It took me about two weeks of reading and rereading the documentation to make sure I understood what needed to be done. And I still was on pins and needles when I installed the patch.

Hope this info helps. I wish Rann (and anyone else who still has to deal with this issue) the best of luck.
-Jon

First, BlackBerry warns of this over and over in its documents concerning the DST patches and has a tool to set the correct permissions.

Secondly, the BESAdmin account does not need to be a Domain Admin, and probably shouldn't be. If it's not a Domain Admin or any other privileged account, AdminSDHolder shouldn't overwrite the Send As permissions. RIM had me grant the permission at the top of the domain tree and I haven't had any problems with the account.

While I deeply sympathize with Rann's position and problems, we've all made those kinds of errors. I don't believe that this is a case of poor documentation or poor patch configuration. The information he needed was out there, he just missed it. I do think that RIM technical support should have been better equipped to diagnose this problem. It's in their own documentation!
-Mark

The patching process for these issues have been clearly and widely available for a very long time. Yes, there are issues upgrading. However, everyone with a BES support agreement can call and they will almost walk you through patching your systems to ensure BES uptime. This admin is clearly whining because he did not do proper testing and due diligence on the patch before implementing it.
-Brian

Before de-installing things that will need to be installed sooner or later, my recommendation for Rann is that he go here and follow the instructions that the BlackBerry team published on how to go about the DST updates. What Rann mentioned is a known problem that I personally experienced about four months ago after another MSFT patch install.
-Kelvin

Not sure why Rann would have been "quite surprised" about this. The Microsoft KB 926666 makes it pretty clear. I would recommend this article.

It states, "As an emergency measure to restore Send As functionality for business critical applications, you can grant Send As permission to a service account through inheritance on an Active Directory container or even an entire domain." Also, here is a step-by-step guide from RIM for doing just that.

Seemed to work for us. I don't know about Rann's config, but they also do say you shouldn't use a privileged account as your service account.
-Greg

This issue was discussed in Appendix A (upgrade checklist) of RIM's upgrade guide for DST 2007 PDF. Rann should have been more prepared knowing that this was an issue. That's my two cents!
-David

This is just another example of an IT manager who blindly applies patches without doing his homework. It was well-documented from Microsoft and RIM that the DST patch (MS KB926666 and RIM KB04707) would perform exactly as the earlier Exchange patches (that he knew about) would (MS KB912918) -- increase the security on the store.exe and not allow members of protected groups to perform the "send-as" feature. One only has to do their due diligence to know about the risks before they install the patch.

Assuming he had followed the instructions in MS KB912918 to make sure the BESAdmin account has the correct permissions, the only users that are affected by the DST patch are ones who are a part of Protected Administrative Groups: domain admins, administrators, Exchange admin, Enterprise admins, backup operators, etc. -- the high-level groups (full list found in Microsoft KB907434). The real question to ask is why are your normal users members of these groups? No normal user, even the president of a company, should be a part of the Domain Administrators group. He/she will never be performing IT duties and should not attempt to do so without the proper knowledge and training. Part of the job of being in IT is to educate your users (and say NO every once in a while) and with that, they will have to trust that you will do what is best for them. If your president demands full rights, then give him local administrator rights to his own computer -- he may destroy it by installing every piece of software he can find, but he will have a reduced chance of bringing chaos to your whole network.

I ran into this same issue, but only with members of my IT staff who were in these protected groups. To fix it, we created a new "admin" account for each user so they could still perform their assigned duties. Our existing accounts, with our e-mail addresses that were tied to our BlackBerrys, were removed from those high-level admin groups, and all AD security permissions reset to the default inherited permissions. I tested this by moving my account to our second e-mail server that had the patches applied. Because of this extra testing step, I had to wipe my BlackBerry, remove myself from the BES and then re-add myself to the BES and reactivate my BlackBerry. Our problems were solved with a little bit of forethought, research, planning and testing.

If you don’t have the luxury of having a testing environment, then you need to schedule a maintenance period with your organization so that all users know their BlackBerrys will not be functioning for a certain time period. You would need to really plan ahead: Do your research and figure out what you can do in the window of time you have and, more importantly, figure out your back-out strategy if your plan of action doesn’t work.
-Diana

Want to join the fray? Comment below or drop me a line at [email protected].