atom beingexchanged

Monday, January 25, 2010

First-Look, Outlook 2010 Beta

As new versions of Exchange Server have come out, Microsoft has typically given us a new version of Office right along with them.  Exchange Server 2010 is no exception, with Office 2010 soon to be released to the general marketplace. Sometime in the first half of this year we’ll see a formal release, but you can download the beta version now, which will continue working (and being updated) until October, well after the full release is slated to happen.  As your intrepid Exchange reporter, I of course took it upon myself to inflict the beta on my production systems.  Mind you, I waited for the first round of WTF?! to be over, but those horrific errors seem to have been corrected by now.

First things first, if you have an x64 system, you will need to uninstall the previous versions of Microsoft Office (even 2007) in order to install the 64-bit version of Office 2010.  I’m pleased to say that personalization is maintained, and 2010 seemed to remember most of my customizations from the earlier version.  If you are using a 32-bit system, you do not have to pre-uninstall earlier versions at all, just do an in-place upgrade. Also, the beta does require a key, so you’ll need to be invited into the beta program or be part of TechNET to get your hands on both the bits and they key. 

Once the installation is done, you’ll find that most of the applications look the same as they did in 2007, except that the Office Button is replaced with a File tab in the Ribbon.  This keeps all functions looking and feeling the same, and is easy to get used to.  Now, open Outlook 2010 and be ready for a big change.

As announced, the Ribbon interface is now part of Outlook 2010.  It is very well integrated, with button bars and functions smoothly changing as you move from Mail to Calendar to Contacts views.  Many have criticized the Ribbon, and for those who hate it, you can now hide it.  For everyone else, you’ll find it a welcome addition to the Outlook interface.

Also added to Outlook 2010 is the ability to group emails by conversation.  This allows you to see all emails in a certain thread at once, with an expanding drop-down format.  I’m not the biggest fan of this, as I prefer using the search feature, but I will say it is well executed, and easy to figure out and navigate.  The coolness factor here is that the conversation grouping extends to multiple folders, so you can find linked conversations even in folders outside the Inbox.

Moving on to mail functionality: The overall interaction with Exchange hasn’t changed radically.  AutoDiscover is still available, and seems to work great within a corporate Active Directory Domain.  You can still manually add accounts for most mail formats, and you can now add Text Messaging if you’re using Windows Mobile, Outlook Anywhere and Exchange 2010.  Once configured, email sync and workflow is very similar to earlier Outlook versions.  Both cached mode and online mode are still available for Exchange 2003 and up, as is Outlook Anywhere (formerly RPC over HTTPS).

There are, however, a few very welcome changes to workflows in Outlook 2010.  The most noticeable is how you’ll see Outlook/Exchange Meeting Request emails.  When you preview or open these messages, you will still see the usual data, but you will also see the event itself as it appears in a mini-view of your calendar.  This means if it is adjacent to or conflicting with another event, you can instantly see what event it’s touching without flipping over to the calendar.  As I work with a large group of people, and often end up with conflicting schedules, this feature makes life a whole lot easier for me and my co-workers.

You can highly customize the Ribbon within Outlook. This many not sound like a neat feature at first, but since the Ribbon changes with every view (Calendar, Contacts, Mail, etc); this becomes invaluable. Having different Ribbon buttons for each view means that you can click New Meeting Request when in the Mail view, but not have that button take up space in the Calendar view (where it is a default choice).

Now, on to the NetBook.  The smaller screens on these devices (I have a Toshiba N205) make Outlook a living nightmare to work with.  Microsoft has finally listened to their audience and created tools in Outlook 2010 to make this an easier tool set to view on a smaller screen.  One tap of the “Reading” view button (in the extreme lower-right corner by default) and all of the fly-out bars collapse to the sides. The Ribbon also minimizes, and you are left with a wide-open space for your email list and Preview Pane, and nothing else.  All the features are still there, you just expand the left and right fly-out panels to access whatever you need, and click the menu choice to temporarily expand the Ribbon.  Most of the fly-out bars have quick-links on them, so you can drag and drop email from your Inbox to a favorite folder, for example. Reading view (one that works this well) is a tremendously useful system for Netbooks, and one that has been sorely missing for generations of Outlook clients.

I will put out blog updates over time as I find new features and as Outlook 2010 moves closer to maturity and release.  This will include information on the new Social Connectors as they are available.  Outlook 2010 comes with the SharePoint Connector, but as we have SharePoint 2003 and the Connector requires SharePoint 2007 or up, I can’t report on that one just yet.  Stay tuned for more info as it is available, and of course check out the Microsoft Office Home Page for official details.

One final note for this posting.  When you install the beta, you see two tray icons appear - “Send a Smile” and “Send a Frown.” These are feedback buttons that you can use to send information to Microsoft including screenshots (optional, of course) and text-based messages.  Many have expressed their disdain for them, so it’s good to notice you can uninstall just that bit of code by going to Add/Remove Programs (or Programs and Features in Win7) and ditching the Send a Smile application.  Personally, I like them and have used both, but I understand how not everyone would want them installed full time.

More to come!

Labels: ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, July 20, 2009

Big Brother is Watc…[Recalled]

The big kerfuffle over Amazon’s Kindle Team removing several books without warning from users’ devices (story and link at the end of the blog) has lead me to think about the various time clients have used the Recall Message feature. Typically, they have found that it behaved just slightly better than opening their office door and screaming “NOBODY READ THAT!”

There are a lot of great reasons to use Recall Message in Outlook and Exchange.  Perhaps something was sent before it was finished, accidentally clicking Send without typing in that last bit of information.  Maybe you meant to add an attachment but did not – in which case may I suggest some of the great tools at Sperry Software.  You may also have accidentally hit Reply All instead of Reply, or added in a group email list via AutoComplete instead of the one person you wanted to send email to.  All of these are legitimate reasons to really want to get the email out of everyone’s Inbox.

Years ago, Microsoft attempted to build the functionality of yanking back an errant email on command.  It required (and still requires) that you be using Outlook in Exchange Mode, and a Microsoft Exchange Server as your email platform.  When first introduced, this worked great.  There was no such thing as a preview pane, you were always using an Exchange Server and MAPI for communication, and folks were probably online and connected since there was no Cached Mode.

The issues arise when you look at what is required for a Recall attempt to succeed:

  • The user must be online and connected to the Exchange Server
  • They must not be in Cached or Offline Modes
  • The message must be unread in the recipient’s Inbox (including unread by the Preview Pane)
  • The recipient cannot have moved the message to another folder (unread or otherwise)
  • They must be using MAPI. Even POP3 or IMAP on an Exchange Server won’t count.

So, as you can see, since the majority of email users these days do not meet one or many of these requirements, Recall Message will fail for the majority of your users.  What they will see is the original email (unchanged) and a notice saying you would like to recall the original email.  This can often be just as embarrassing as the original gaff, as it acts as a glaring exclamation point that someone made a goof.

One more note, Recall Message will not impact the copy of the information on a Blackberry or other 3rd-party Smartphones and mobile devices.  So even if the user’s desktop has all the requirements met, they’ll still have a copy of the message (and the recall request) sitting on their mobile device.

In the days of Exchange and Outlook with MAPI connections being the only conduit to email, Recall Message was a great way to manage errant information.  Today, with so many ways to connect to any mail system, including Exchange Server, this feature has lost its usefulness and created a false sense of security.  Remember, if there is a chance that someone’s using a non-Outlook client or not meeting all of the requirements above, you will not recall the mail.  An ounce of prevention is your only cure these days.

As for the Amazon gaff, for those who did not see the news:  Amazon recently pulled all the books by a major author and deleted them off all Kindle devices that held them.  This was due to someone posting the books on the Kindle store, without the publishing rights needed to earn money from them.  Once Amazon realized what was going on, they of course stopped selling all the books from that vendor.  Unfortunately they also removed all the digital copies that were stored on users’ Kindle devices without mentioning it to the Kindle owners.  They did refund everyone’s money, and they did send out an explanatory email, but not until several days later after the blogosphere detonated with Amazon hate postings.

Frankly, Amazon’s user agreement does say that they reserve the right to do exactly what they did.  I can’t fault them for heading off trouble (in the form of a copyright litigation) at the pass. However, it could have been handled a lot better, with more information supplied immediately to end users about what was going on and why.  Amazon has promised to make this process much more transparent so that next time there is no confusion.

The reason there was such an outcry about the process this time (as it has happened in the past, quietly and without fanfare or hate mail)?  The author in question was George Orwell, and the books were the likes of 1984 and Animal Farm.  Both of these books deal with subjects like retroactively removing information that didn’t meet the criteria of an overarching body of government or law.

From Dictionary.com:

Irony: an outcome of events contrary to what was, or might have been, expected.

Labels: , , , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, June 29, 2009

Anyway, Anyhow, (Outlook) Anywhere

For some strange reason on my a classic rock kick these last few weeks, so today’s posting title comes from another song by The Who.

No clue?  Watch this YouTube video.

And listen for this lyric:

Nothing gets in my way / Not even locked doors / Don't follow the lines
That been laid before / I get along anyway I dare / Anyway, anyhow, anywhere

Outlook 2003 and 2007 offered a new approach to Exchange Server connectivity that did not exist in the wildest dreams of earlier versions of Exchange and Outlook.  These two versions of Outlook (and the upcoming 2010 version as well) have a feature set called Outlook Anywhere, previously known as RPC over HTTPS.

Since the dawn of distributed email systems, there has been a schism between the need for connectivity and the need for security.  Most servers can be isolated from the outside world in some way.  Many can be completely locked down and held within the corporate network.  Others can have limited web-based connectivity via tightly controlled front-end servers, allowing the sensitive back-end solutions to be protected inside the network.  The major issue for email was that the systems are inherently designed to communicate with the outside world.  In fact, it’s the whole point of the exercise for the majority of Exchange users.

Microsoft, to their credit, has created a series of systems that allow Exchange 2007 server to only expose the bare necessities to the outside world with the new Edge Server Role on that platform.  But not every company can afford that type of infrastructure, and it wasn’t available before the Exchange 2007 Server platform.  So most companies these days cannot take advantage of that role, and even when they do, the limitations of the Edge Server may not make it the best chose for remote users.

Before Exchange 2003, the alternative was to limit connectivity between the Exchange system and the world at large by using port control on the server side, and VPN connectivity on the user side.  This allowed for Exchange to see only what it needed to on the net, but also required administrators to set up and manage VPN software on all their mobile client laptops, home-office desktops, etc.  It was definitely a trade-off if all the users really needed to use the VPN for was Outlook.

The came RPC over HTTPS.  This technology lets MAPI RPC calls (the communications protocol Outlook uses natively until the 2010 version) to go over the public network in a secure manner.  Essentially, the Outlook 2003 or 2007 client will use HTTPS security – much like you would in a web browser to communicate with a bank or other secure website – but in this case it is Outlook talking to Exchange.  It is secure, reliable, and requires no other software on either server or client side.  It does require enterprise CAL’s in Exchange 2007, so keep that in mind, but it doesn’t need to have anything outside of Exchange Server 2003 or 2007 installed on the servers themselves.

With the advent of Exchange 2007, RPC over HTTPS became a more accepted part of Exchange and gained a formal name – Outlook Anywhere.  The system is simple. Outlook is configured to make a secure HTTPS connection to the Exchange Server or (in 2007) the Client Access Server/Hub Transport Server.  This lets the administrator strictly control access both via security certificates and limiting of what ports have to be exposed, but let end users function with just Outlook and no 3rd party or other VPN client.

To configure, you alter your Outlook Profile, under Account Settings|Microsoft Exchange account|Advanced Settings in Outlook 2007.  Once there, open the Connection tab and click the check box near the bottom to enable HTTP connections.  You will also need to click the button under the checkbox and supply the connection URL for your server. Typically, this is your Outlook Web Access URL, though you can configure a specific record if you prefer.

There are several settings that can help improve network function over slower links, but the defaults should be fine for most networks.  Note that you MUST have the ability to connect to webmail via SSL (in other words https:\\mail.yourdomain.com and not just http:\\mail.yourdomain.com).  Since the data needs to be encrypted, you have to have security set up beforehand.  Though, you can use a self-signed certificate, that will cause your end-users to have to click through a security warning when they log in, so obtaining a public SSL certificate is a good idea.

Once configured, Outlook Anywhere will allow normal Outlook functions to occur as if the users were on your corporate network, but with all information between them and your system secured and limited to avoid potential attack.  It is a great solution where setting up a VPN communication tunnel for each remote user just isn’t feasible or where the only reason to do so is for Outlook communication.

Microsoft has made a lot of good progress in helping secure an application platform that – by its nature – must communicate with the outside world in order to function properly.  Outlook Anywhere is one way that this type of communication can occur, and is a great way to allow your users freedom to get their work down without requiring specialized network technology to be put into play.  Anyhow, anyway, anywhere – a thought never more true for Exchange and Outlook.

Labels: , , , , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Wednesday, June 10, 2009

Avoid bumpy rides with Exchange Online

I’m posting from a hotel room in Hartford, CT, getting ready for a meeting with a client tomorrow.  Getting here reminded me of why you might want to choose to not try to go it alone when you set up Exchange Server for your organization.  More details on the trip later.

One of the biggest problems I see clients facing when they deploy Exchange Server is the simple fact that it’s a huge software package.  In reality, it’s more of a suite of tools than one application, and therefore requires either pre-existing expertise, or a very fast ramp-up to be able to properly install, manage and maintain the solution set.  Luckily, there are options today that were simply not available in the past, namely Hosted Exchange Services (a.k.a.. Exchange Online).

Hosted Exchange is – at its heart – renting space on a shared or dedicated Exchange Server that is managed and maintained by a 3rd party.  These are hosting providers vetted by Microsoft (or at least they should be) and skilled in creating, deploying and managing Exchange Server solutions. No hardware on-site, and no major management needed by your own tech people.  So what are the pros and cons of using a solution like this.

The major con is that you have to keep your data on another server system that doesn’t reside within your firewall and security network.  Though the reality is that anything which requires connectivity to the outside world is technically open to attempted attack, some companies may not be able to tolerate hosted data.  Either corporate or external compliance policies and laws may prohibit this, so be sure to check with your compliance staff to make sure it’s ok before you ship the email off-site.

Barring compliance issues, security may still be a concern.  Make sure you completely check out your hosting provider, make sure they are a Microsoft Partner and make sure to get references before you sign over your digital life.  It’s totally fair to put the hard questions to your hosting provider, as you’re trusting them with a tremendous amount of sensitive data.

Beyond those two potential cons, the pros are pretty deep.  Many small to mid-sized organizations may attempt to host an Exchange Server in their own network.  Due to inexperience or just plain lack of time, patches are missed, settings are mis-configured, security concerns are overlooked.  This leads to either a poorly functioning Exchange system, or worse, an attack against the organization using the messaging platform as the attack vector.  Larger organizations who have dedicated messaging staff can afford to have people who look after these details, but smaller shops can’t, and often the company infrastructure suffers because of it.  I’ve discussed a lot of potential pitfalls to running an Exchange environment – this is a well-rounded way beyond most of them.

As a matter of fact, when talking with Jon Orton – one of the TPM’s that works with Exchange Online for Microsoft – he related to me that “we’re seeing more and more people, especially in the “small Exchange deployment, not much expertise” category, signing up for Exchange Online and partner-hosted Exchange.”  By placing the infrastructure in the hands of a team of experienced Exchange engineers, you remove that burden from your IT staffers.  Don’t get me wrong, I believe anyone can indeed learn to manage an Exchange Server messaging and collaboration environment However, if you do not need to, then this is one thing you can get off your plate and off your mind – safely.

So, even though it might be very tempting to set up Exchange Server within your network, the facts that it is readily available for purchase and that server hardware is getting cheaper should not be the major factors in decision.  Hosted Exchange Services with a trusted provider are easier to work with and just as readily available, and with a little legwork ahead of time, will be a better solution for many small and mid-sized organizations.

Which leads me to my harrowing journey today.  When considering how to get to Hartford from my native New York City (Queens, to be exact),  I had a few choices.  All were pretty easy.  I could take a train to a mid-way city and hitch a ride with a co-worker going to the same meeting from there.  I could take a different train and then a quick shuttle here.  But, because it was readily available and easy to set up, I chose to take a bus directly out to Hartford.  Much as with the decision to leap before you look and set up an Exchange Infrastructure on-site, I nabbed the tickets and got on the bus without a lot of pre-existing experience with the bus route.  After getting bounced around the bus for about 3 hours, and nearly losing the sandwich I had grabbed at the terminal, I finally got off the bus from hell and collapsed into the hotel room.  Had I researched my options a little better – and sought out some experience from others – I would have realized that a little more legwork would have led to a much better experience for me.

So do a little legwork before you put in your Exchange Server.  Know what you’re getting into and know that there are great options for getting out of the situation.  Exchange Online with a trusted provider can offer a convenient, safe and workable option for those who are just not quite ready to roll their own.

Labels: , , , , , , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Wednesday, May 20, 2009

Outlook, can you hear me? Can you feel me near you?

Might be showing my age and/or taste in music with that particular title (and if you’re totally confused by it, check out This YouTube video), but I think that it’s a great way to describe an annoyance that can happen if you’re using versions of Outlook before Outlook 2007.  Since a large portion of the users of Office are on the 2003 version (and many even earlier than that), resolution to a new server in the event of a disaster recovery event is a subject that is just as confusing as the famous rock opera I’m making use of in my title today.

When Outlook 2007 was introduced to the world with Exchange 2007, a lot was made (and rightfully so) of the new AutoDiscover features that this platform brought into the Enterprise Email marketplace.  The long and short of the AutoDiscover solution set is this:

When an Outlook 2007 client cannot find its home server – either because it is a brand new install of Outlook or because the home server has moved or been replaced – the Exchange 2007 AutoDiscover system can help Outlook 2007 find its home.  If the Outlook client can see an Exchange Server (or be directed to one by Active Directory), the Server can tell Outlook where the mailbox information for the user’s profile exists, and direct Outlook to connect to the appropriate CAS or Mailbox systems and get connected.  All the user/Admin has to do is tell Outlook the user’s email address and password, and AD with Exchange 2007 will handle it from there.  So if you’re installing Outlook for the first time, you don’t have to manually configure the Profile anymore – a great boon to Admins everywhere.

This system also kicks in if you perform Database Portability during a disaster, and have replicated the database with SCR; or have used a 3rd party disaster recovery/availability solution (see disclaimer below for all my bias information on that one =).  Once the Exchange system is responding again, AD can ferry the Outlook 2007 client to the new home for that mailbox, requiring only that the end-user close and reopen Outlook to complete the process.

However, what many folks do not realize right off the bat is that this solution set is ONLY available if you have both Outlook 2007 and Exchange 2007 as your messaging platform.  All users who need to take advantage of AutoDiscover must be using that combination of tools, and no other.  As you might expect, POP3 and IMAP systems do not AutoDiscover, but the majority of my clients were unaware that Outlook 2003 and earlier also cannot take advantage of this system, even if you have upgraded to Exchange 2007 as the messaging platform of choice.  It’s also worth noting that AutoDiscover doesn’t officially work in Exchange 2003 – no matter what Outlook version you are on.  Before I get blasted by mail on this one, I know some folks have sometimes seen it to work on Outlook 2003 with Exchange 2007, but it bombs more than it works, and officially it’s not supported.  For proof, I direct you to this article by the MS Exchange Team.

Since the code to perform AutoDiscover wasn’t in Outlook 2003, users on that client software will not be able to dynamically re-link to the new Exchange server unless the original mailbox server is still responding.  If it is, then Outlook can find the new server via the original server and re-home itself.  If not, Outlook must be manually re-directed to the new server.

Of course, there are ways around this.  You could update DNS to re-direct anyone calling for “Server 1” to the IP Address of “Server 2” – effectively re-routing all client software including POP and IMAP.  Outlook 2003 will still need to be re-profiled unless you take over the Service Principle Name (SPN) of “Server 1” on “Server 2,” but it will be a smoother transition.  Using a 3rd party tool (see disclaimer below) you may have the option of automated DNS and SPN updates, which will allow even legacy Outlook clients to jump to the new server with no more intervention than is required on Outlook 2007 with Exchange 2007 – even if you’re whole system in on the 2003 versions of those software platforms or earlier.

So, you are not without lots of options if you have any legacy servers and/or clients – or non MAPI clients – in your environment. You just need to be aware that the Exchange 2007/Outlook 2007 solutions for AutoDiscover services are not backward compatible, and plan accordingly.  Right now it looks like Exchange 2010 will have AutoDiscover that is backward compatible to Outlook 2007 only, so this soon-to-be-released platform is not going to solve this particular problem unless you’re planning on upgrading everything else in the environment to at least Outlook 2007 first.

Since I like to let folks continue to discover on their own, here’s a link to the White Paper from MSFT on AutoDiscover.

Finally, Update Roll-Up 8 for Exchange 2007 is out there, which can make life easier if you’re doing a fresh install of Exchange 2007 and want to get up to date with patches and fixes post SP1 quickly.  You can get it at this link.

Labels: , , , , , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Monday, April 13, 2009

Public airing of Exchange laundry...

Last week we finished up talking about what happens to Private Mail Stores during Online Maintenance (OM) on your Exchange servers.  While most people really tend to focus on what happens in those Private Stores the Public Stores are just as important, especially if you're not on Exchange 2007 yet.

For all versions of Exchange, Public Folders experience most of the same processes that their Private Mailbox cousins do, with the Exchange system scavenging items that are marked for deletion and have passed deleted item retention to start.  The system will also get rid of expired folders - a similar process to deleted mailbox systems in the Private Mailbox Stores - and perform an online defragmentation of the databases.  General maintenance and cleanup for Public Folders should be considered to be the same priority as OM on your Private Mailbox Stores, even if you're on Exchange 2007.

With Public Folders in Exchange 2000 and 2003, and even in 2007 in some circumstances, there is another vital process that goes on each day. It is not technically part of OM, but should be considered on par with the OM process.

As many people notice, the first time you boot up a newly-installed Exchange server, Outlook will complain about not being able to find "a required file" when you do a send/receive operation.  This is because - unless you're using a native Exchange 2007/Outlook2007 environment - Outlook cannot find the Offline Address Book (OAB) which doesn't get created in the Administrative Public Folders until around 5am the morning after the Exchange server goes online.  While not officially part of the OM process, the creation and subsequent updates of the OAB do happen overnight - 5am by default, just after the OM process is typically completed. 

OABgen (the process that - wait for it - generates the OAB) should be considered part of your OM systems. If you do not allow this to occur regularly, your OAB doesn't get updated and therefore your end users don't have the latest information - causing no end of frustration for you and your technical staff.  You could manually create/update the OAB using tools inside of Exchange, but the automated process is still your best bet for making sure these critical systems get updated regularly.

And one final note.  For those who believe they can get away with no Public Folders and/or PF maintenance because you are on Exchange 2007, be aware of one very important caveat.  All Outlook clients must be on Outlook 2007, and no Entourage or other MAPI clients can be used. That's because all MAPI systems before Outlook 2007 required the use of Public Folders for administrative information, like the OAB and other components.  In Outlook 2007, that's handled by Active Directory and Exchange itself, but if there is even one legacy client in your environment, you'll still need at least one PF tree, and therefore need to perform regular Online Maintenance on those Public Folder Stores.

Next week, back to regular blog topics - and speaking of which, if you have a topic you'd like me to cover, go ahead and drop me a line at MikeTalonNYC@yahoo.com

Labels: , , , , , ,

Bookmark and Share
posted by Mike Talon at 0 Comments

Friday, February 20, 2009

Update now - no I mean it, NOW

Though I'm known for keeping a level head during these kinds of scenarios, there is an emerging vulnerability in both Exchange Server and Internet Explorer that you'll have to address immediately to keep your enterprise safe.  I wish I was kidding, but no, it's true.

The long and short of it is that specially crafted messages could be sent to an Exchange server that - even if only previewed by a user - can allow an attacker to take control of the Exchange server itself with full Exchange Admin privileges.  The details can be found at this link, but I'll summarize here.

If an attacker crafts a message in certain ways via TNEF (Transport Neutral Encapsulation Format), and that message is then either previewed or opened by an end-user (which is the point of email after all), then the attacker can gain elevated privileges on the Exchange server and wreak havoc. While that sounds like a major problem, there is good news.  The attack would require a sophisticated attacker creating just the right message and then finding a live mailbox to send it to.  Not only that, but it would need to get past the SPAM and CAPTCHA systems if you use them.  Finally, eventually the anti-virus vendors will jump in as well, scanning for messages crafted with the exploit.

The really bad news is that end-users do NOT have to open an attachment this time.  They can unwittingly infect the mail servers by previewing the message body or opening the message itself.  Since Outlook clients and now even Outlook Web Access both Auto-Preview by default, end-users can follow all best-practice safety protocols and still end up infecting the organization through no fault of their own.  Add to this that some anti-virus tools may use MAPI viewers to scan mail, which means that the system designed to shield you could accidentally infect you instead.  The same goes for backup agents that use MAPI clients to do brick-level backups.

There is one more bit of scariness to be told, though information on this last peice is more sketchy than the other exploit vectors. It would appear that the TNEF message may not need to be even previewed by an end user, but could in fact attack a server just be being received by the server itself.  Even until we know more for sure on this last point, I think the previous points - which are verified by this author and others - are bad enough that you should jump on this right now.

Microsoft has released a patch - also available via this same link, under "Security Update Deployment" and so you can protect yourself and your organization.  I strongly urge you all to do this immediately, and to have your end-users run Windows Update (Start|Windows Update on Vista, Microsoft Windows Update Online for everyone else) to get critical Internet Explorer patches as well.

Now, this is not only your Exchange server that you are protecting.  If an attacker gains privileges on your mail server, they can use it as a launching pad for attacking other servers with the same exploit or any other they'd care to try.  That means that if you don't patch your systems, you could inadvertently be responsible for attacks against other servers all over the net.

And so, I am asking my readers to protect the community at large as much as they can, by spending the time necessary to download and install the appropriate patches.  Yes, this will mean a maintenance window for a reboot.  Yes, it's annoying that we've gotten hit with yet another critical vulnerability.  But, yes, it is our responsibility to make sure that the attacks stop at our own borders, and that our own mail servers do not become the launching point for the next Code Red.

Labels: , , , , , , ,

Bookmark and Share
posted by Mike Talon at 0 Comments