It's Now Safe To Write Vista Software
We might knock Microsoft every now again here at Redmond Report, but there
is one area where we go pretty easy: developer tools. After more than 30 years
in the development tools business (anyone who actually used Altair BASIC is
automatically enrolled in the Doug Barney Hall of Fame), Microsoft is getting
pretty good at the game.
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!
what Fontana had to say.
Microsoft-Google Scuffle Continues (This Time, Redmond
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
Tell me where I'm wrong at email@example.com!
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
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
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."
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).
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!
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
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.
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
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.
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!
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
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.
Not sure why Rann would have been "quite surprised" about this.
The Microsoft KB 926666 makes it pretty clear. I would recommend this
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.
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!
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.
Want to join the fray? Comment below or drop me a line at firstname.lastname@example.org.
Doug Barney is editor in chief of Redmond magazine and the VP, editorial director of Redmond Media Group.