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.

HTC Magic and ActiveSync?

Android (Google’s Smartphone platform) has shown itself to be quite a popular solution set for geeks all over the world.  The one thing it really didn’t have that it really did need was Exchange ActiveSync support.  Without it, corporations couldn’t sync email down to the device with a push-style system.  Granted, 3rd-party software can (mostly) reproduce the effect of ActiveSync, but without a native solution, there will always be supportability issues when Exchange is updated, you switch to a new version of the Server, etc.

So, it was a bit of a shock to hear the rumors about T-Mobile’s new Android-based phone (the HTC Magic) would support Exchange sync natively.  After all, Google has officially stated that Android does not support Exchange ActiveSync, and so the Magic should have not had this functionality.  Plain as day, though, there are multiple photos of the HTC Magic with the Android OS, but clearly showing that it could be set up to perform Exchange syncing.  So what gives?

The short answer is that Google isn’t the one who built the functionality into that particular phone.  While it is based on Android, it is not a “Google Experience” phone. In other words, HTC opted to forgo the logo certification on that device, in order to put in their own software layered on top of Android.  That means that among other stuff, ActiveSync is now part of that build.

In the Windows Mobile world, this isn’t unusual.  As long as the base configuration is logo-certified, the vendor (and the service provider, for that matter) can jam in any other feature sets that they want.  For example, the HTC S743 comes pre-loaded with a few HTC-only apps that add some nifty interface enhancements, and the Sprint version of the HTC Smartphones comes with so much stuff pre-loaded that it hardly looks like Windows Mobile anymore.

In the Android world, this is apparently not a normal thing. I personally do not have a lot of experience with Android, but from what I have seen, if you alter the base image too much, you risk losing the little “Google Experience” tag.  HTC and T-Mobile previously didn’t alter all that much, which is why a T-Mobile Android phone looks about the same as any other. For the Magic (or 3D), the alterations were enough to get the logo pulled, judging from the publicity photos.

So it’s a trade-off, either you go fully logo-compliant, or you get enterprise email and messaging.  If Android is really aimed for the enterprise market, I’d go with the ActiveSync technology.  Google and Microsoft have not always gotten along, but then again neither did Microsoft and Apple, but it didn’t stop them from getting ActiveSync on the iPhone.  C’mon Google, let ActiveSync in (officially) and let the corporate world run with the Android platform.

Diversity takes another one for the team

Belts are tightening everywhere – and though it appears that budget freezes might be thawing out slowly over the next 6 months or so, there are cost-cutting measures all over that are still being brought to bear.  One of the more interesting ones (that wasn’t in my company, that is) was the report that Microsoft was going to be ending its policy of letting employees expense fees for any Smartphone besides Windows Mobile devices.  So no more Pres, no more BlackBerries and no more iPhones.

You can read a blurb about it in this Network World article

These are tough times, and I will not fault any company for tightening the expense account reins.  Standardizing on one mobile technology is a fairly common practice for most companies, and not paying for other technologies is also normal in the business world. So, I’m not quite upset that MSFT has decided to only reimburse for WinMo devices.  Even so, part of me is a bit miffed on reading this one.

MSFT isn’t like other companies – in so many ways.  Specifically here, they make a product line (Exchange Server) that interacts and interoperates with iPhones, BlackBerries and other mobile devices either directly or indirectly.  The diversity of devices that their previous policies made possible was a boon to developers internally who needed to make sure that the latest changes to the Exchange line allowed the more popular devices to continue working correctly.  It’s much easier to see that Exchange Active Sync broke when the guy next to your cube suddenly finds his iPhone stops getting email.

Since real-world businesses are adopting devices like the iPhone and new new Palm Pre (at least if you listen to Palm they are), knowledge of how those devices interop with Exchange Server is critical.  MSFT would be technologically better off having folks using those devices every day right there in Redmond.  The easiest way to ensure that happens is to make them fiscally available to employees.

Granted, when push comes to shove, cost cutting is cost cutting.  Sometimes it’s just necessary to hold back on expenses in order to keep everything else running smooth.  So I do not fault MSFT for making this policy and putting it into effect.  I think that it may have a larger impact than just bottom-line savings, but it is a responsible, viable method for holding back costs while not resorting to more layoffs.

As we put notch after notch in our belts, and as we shakily get back to our financial feet again, there will be more of these cost cutting measures.  A lot of them will be much worse than this, but most will not have such a direct impact on the development of a product platform.  So, hopefully the Exchange team will continue to have Pres and iPhones and BlackBerries running around, even if the company doesn’t officially subsidize them anymore.

Article of mine on EBizQ.net

Hi folks, I got an article on DR solution sets (see disclaimer below).

You can find it here.

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.

Exchange gets tired.

I’m not talking about getting old here, but rather about exhaustion, which can happen in even newer versions of Exchange Server. Checkpoint exhaustion is a function of the ESE database system set used in Exchange, and designed to stop the system from corrupting itself if too many database transactions get held up in a log file by anything.

The normal sequence of events is well known for most relational databases.  Information added to a database is sent to a so-called Lazy Page Writer to minimize disk access by aggregating I/O operations.  When this process happens, a write-ahead logging system tracks the operations, so that if they need to be replayed, they can be safely re-generated if the Lazy Writer data is lost.  As the transactions are committed to the database itself, the log systems note this by checkpointing those transactions, essentially noting that they’ve been safely committed to the database.  For most versions of Exchange Server this happens every 20MB or so (that’s 20MB of log data, not database writes).

When things do not go according to schedule, the logging systems can recover data that was in the Lazy Writer but not yet committed to the database with emergency systems.  Some, like the normal startup process for an Exchange database, are done automatically.  Others, like ESEUtil rescue operations are done manually, and hopefully avoided entirely.  But, the point at which the logs logjam up so much that the system forces emergency procedures can be more difficult to explain.

The short answer is that Exchange can log up to 1,008 transactions before Checkpoint Exhaustion hits.  This is the point where Exchange can no longer just keep writing to the logs and still know that those transactions can be safely recovered even if the Lazy Writer doesn’t have the transactional data anymore.  If the system sees that the logs are tracking more than 1,008 transactions that have not yet been checkpointed, it will forcibly dismount that database – in this case Storage Group and related Stores.

Now, when does Checkpoint Exhaustion happen?  That’s a bit trickier to explain, but there are a few definite times you might see it.

1 – The system is horrifically under-powered in terms of how fast it can get data out of the Lazy Writer and onto disk.  This is rare, but can happen if there is a failing RAID controller or other disk-device.

2 – Something has placed a lock on log files or databases.  In this case, the offending application is stopping Exchange from writing to either a log or database, or at the very least stopping the checkpointing process from happening regularly. Since this means that Exchange cannot successfully checkpoint the database, logs continue to build and build without being “caught up.” This is also not common, but can occur with management tools that go awry.

3 – Backup systems don’t work as expected.  With most Exchange-aware backup tools, the backup system prevents Exchange from checkpointing during the backup operation.  Normally, this is a good thing.  Checkpoint prevention means that no new data will be officially committed while the backup is in the process of…well…backing up.  This means that a point-in-time tape or disk backup can be transactionally intact, even if it cannot maintain strict write integrity native to the backup solution.  Since the Lazy Writer and the log files both have copies of the information, as long as the block is lifted at the end of the backup, all is safe and all is well.

However, if the backup barfs and never lifts the lock, you could have a major issue.  Since no new checkpoints can be set, unchecked log data starts piling up, and eventually you’ll hit the 1,008 transaction limit and see a forced-dismount happen on that Storage Group.  Luckily, restarting the Exchange services nearly always clears this problem, and since the logs still have a copy of all non-checked data, you’re not going to lose anything but time.

Checkpoint Exhaustion was built to solve a particularly thorny problem.  The earlier versions of Exchange Server that are still supported had a hard-coded limit to 1,024 transactions before the database would fault (not just go offline).  That meant that if the Checkpoint Depth hit that level, you could lose data.  So the exhaustion systems allow the database to safely shut down without losing track of any data – which is a not-so-great but definitely better than data loss type of solution set.

So, to avoid exhaustion, there are several things you can do.

1 – Make sure you’re not overloading your Exchange Servers.  Stay within best-practice guidelines for Microsoft Exchange versions, which can be found on TechNET. and be sure you periodically check for hardware issues.

2 – Try to minimize the use of applications that could lock the Exchange Server file sets.  3rd-party non-Exchange indexing for example

3 – Make sure your backup runs are completing properly. One bad run that never got caught can snowball into an exhaustion situation easily.  If you do have a bad backup run, declare a maintenance window of 20-30 minutes and restart the Exchange services, or even gracefully bounce the box.

 

Don’t forget, if you have an Exchange related topic you’d like to ask about, drop an email to miketalonnyc@gmail.com .  Next update should be on Monday or Tuesday of next week, back to my usual schedule. 

A special hello to Larry Meister at Mercury Networks in Rochester, NY, thanks for inviting me to speak at the White Hat Security Day conference.  It was a great event, as usual!  If you’re looking for a partner for your IT needs in Western NY State, Larry is your guy.

New Post on Friday

Hi folks, I’m presenting tomorrow at the White Hat Security Day conference in Rochester, NY.  Since I’ve been on the road, the blog entry for this week has been delayed. You’ll have one  on Friday though!

Meanwhile, you can follow me on Twitter Follow TalonNYC on Twitter!

And you can send your suggestions for future BeingExchanged topics to miketalonnyc@gmail.com

Check back Friday for this week’s post.