The Exchange SP2 Hybrid Configuration Wizard simplified the Office 365 configuration steps massively, however it may not work behind a proxy server. The proxy server settings in Internet Explorer are often used by programs attempting to find a route to the internet; however this does not guarantee internet access to all installed software. Exchange 2010 very often assumes a "direct connection", which does not imply that Exchange is connected directly to the internet, but that it is able to connect without hinderance. Modern firewall software and proxy servers can very often accommodate this scenario, however this article deals with the scenario where this may not be possible at all, and the assumed connection fails outright. The Exchange SP2 Hybrid Configuration Wizard runs in the same context as the system and thereby assumes that it can connect directly to the internet, as well as blatantly ignoring all Internet Explorer Proxy Settings. The Hybrid Configuration Wizard does a number of things when it first starts up. First it generates a new Self Signed Certificate for the federation trust. No internet connectivity required there. All subsequent steps, including the creation of the federation trust to the Microsoft Federation Gateway fail immediatelly. Starting with Server 2008 a number of network configuration settings are resolved best using NETSH. The same applies here. NETSH is a command line utility able to modify a server or workstation network configuration, without requiring a GUI, and setting or resolving configuration items which cannot be set in a Windows GUI. NETSH may be run interactively or as a command line utility. From a command prompt type NETSH and hit Enter. The following commands run in sequence will show NETSH running interactively as well as displaying the systems proxy settings. netsh winhttp show Proxy 1 1 1 The same may be achieved using a one liner from the command prompt: netsh winhttp show proxy Setting the proxy server is just as simple as querying it. winhttp set proxy proxy.nbclabs.net:8080 <local> Adding the <local> parameter at the end bypasses the proxy for local addresses. If <local> is omitted, all calls are routed via the proxy, including local PowerShell. The internet Explorer proxy settings may be imported as follows: netsh winhttp import proxy source=ie Lastly proxy settings may be cleared using: netsh winhttp reset proxy Assuming the proxy settings are correct, the New Hybrid Configuration Wizard may be run again and connects to the internet successfully. I hope that this little piece of knowledge helps save you some time in troubleshooting your environment.
This post is the first in a series of diagnosing specific CAS issues. Today were going to take a look specifically at OWA site to site proxy issues.
Outlook Web App isn’t available. If the problem continues, please contact your helpdesk
While appropriate, this isn’t the most descriptive error message in the world. In order to demonstrate this scenario I build a lab with two Exchange Servers, both deployed on domain controllers in different AD sites. In this scenario, OWA is published to the internet in Site 1, however the user in question is trying to login to his mailbox, which is hosted in Site 2. Site 1 is internet facing and Site 2 is not. Both sites are running Exchange 2010.
Let’s look at what’s happening “under the hood”:
- After a user has authenticated to an internet facing CAS server, the CAS server attempts to locate the location and version of the users mailbox.
- If the user is local, the mailbox is rendered.
- If the user is NOT local, then use the AD Routing information supplied by the “Microsoft Exchange Active Directory Topology” service to locate a CAS server in the site hosting the user’s mailbox. If an external URL is configured on the CAS server in the second site, then silently redirect to the URL (available in SP2) or redirect the user to the link supplied. If the external URL is NOT specified, and an internal URL exists, AND the authentication method on the virtual directory is set to windows integrated, THEN proxy the request.
In the Exchange Management GUI, you should see the following, first the empty
Second, the authentication method is set to windows integrated:
However we’re still receiving an error.
Looking at the Active Directory event logs on the Domain Controllers in both sites, we may notice a number of Active Directory errors, including Inter Site Topology Generator errors. These are the clue that we need.
When we open the Active Directory Sites and Services administration tool, we would notice that the IP SITE LINK between the two sites is missing or misconfigured. Without valid site links, Exchange cannot proxy between sites and OWA fails.
Re-creating the site link, and waiting for replication and cache timeouts to take effect, (or restarting the “Microsoft Exchange Active Directory Topology” service) and OWA stops replying with an error message and renders the users mailbox.
Let’s recap quickly; our three areas for OWA site to site proxy failures are:
- Incorrect URL’s
- Incorrect authentication
- Incorrect site link definitions
The last one can be a bit tricky since it’s often unexpected, and most of us take for granted that AD is either designed and implemented correctly or at least is healthy.
So the stage is now set for a battle royale between the two behemoths of IT – it’s Google vs. Microsoft. Google, the cloud company vs. Microsoft, late in the game but determined to keep Google out of its primary real estate; the enterprise. Round One. ‘Ding!’
So Office 365 has finally launched. It feels as though it’s been a long time coming, perhaps because BPOS has been around for a while and the hype behind Office 365 has been the long drawn out kind of hype rather than a ‘big bang’. Having said that, though, the noise level has been stepped up significantly over the last two weeks, primarily as a result of Google’s spoiling tactics. In the past, Google has avoided this kind of ‘de-positioning’ and attempted to maintain a moral high ground against its biggest rival, but not this time. The Google marketing teams have been scouring the globe looking for big enterprise defections from Microsoft to Google in an attempt to undermine confidence in Microsoft’s cloud offering. They have found one or two, but goodness knows what it took to get them to switch. And on the eve of the launch, the Google Apps Product Manager Shan Sinha, has blogged ‘365 reasons to consider Google Apps’ (he only comes up with four, but point taken Shan).
Actually, for IT decision makers, the most prudent thing to do right now is pour a very large bucket of ice cold water all over the Google vs. Microsoft thing, because it isn’t very helpful.
A few important considerations now we’ve cooled off.
First; the cloud isn’t new. Google will tell you that, obviously, and it’s fair to say that this is a relatively new game for Microsoft. But for those of us who’ve built and sold multi-tenant software services for the last few years, we are way beyond ‘early adopter’. There are some very robust, enterprise-grade cloud solutions out there that are way more reliable, and way more secure, than anything you’d find on premise.
Second; the cloud isn’t flaky. Cloud outages get a lot of publicity. On premise ones don’t, for the simple reason that people dislike showcasing failures. And sure, a cloud failure is very public. BPOS has suffered some downtime in recent weeks, and the timing has been awkward with Office 365 about to be launched. Amazon’s much vaunted cloud infrastructure has gone down as (ironically) has Google’s. And not surprisingly, the media has jumped, and ‘the cloud’ – as if it’s one big amorphous blob – has come in for some stick. It’s important to keep this in perspective. Microsoft will learn from its lessons, and Office 365 starts with a clean slate. And there are third parties like Mimecast offering additional assurances on top of Microsoft’s off-the-peg SLAs.
Third; the cloud is not all or nothing. This is a story we’ve been telling for some time now. Many of our customers are looking to upgrade from old versions of Exchange at the moment, and Office 365 is a consideration. But it’s not a straightforward step to make if you have already invested in on-premise Exchange infrastructure. Gartner, as it happens, is advising its customers (who are all ‘enterprise’ customers) to carefully consider opting for one more generation of on-premise Exchange – ie, move to Exchange 2010 and allow Office 365 more time to prove itself. And certainly we are seeing large numbers of companies migrating to Exchange 2010, with Mimecast enabling them to run a very lean on-site infrastructure – we call it ‘Cloud-Ready’. They can move some or all their email to Office 365 when they are ready.
And perhaps that’s the key message here. In the consumer world, where Google has most of its traction, consumers don’t care about the cloud. If it works, they will use it. In business, the risks are somewhat greater, so ‘moving to the cloud’ becomes a major strategic decision.
The way we see it, the business world uses Microsoft Exchange, and very few of them want to change. Google for an enterprise is a protest vote. But given that more than 80% of the Exchange user base is on 2003 or 2007, migration is the order of the day. Google will try to pick up anyone who loses the faith, or feels bullied in one direction or another, and fair play to them if they do.
But the trick is not to see today’s announcement as a revolution in the world of Microsoft email, but an evolution. The cloud is there for you, and it’s there for you to run a leaner, more cost effective Exchange infrastructure that does not compromise on performance, security or reliability. You can embark on your journey to the Microsoft cloud at your own pace. I’ve mentioned ‘cloud-ready’ Exchange 2010 already. You can also go for Hosted Exchange if you want to move away from an on-site Exchange server. And Office 365 is one choice of fully hosted options, but again there are choices of third party suppliers to ensure that you get what you need from Microsoft’s cloud solutions.
The one thing all these options have in common is Exchange 2010 which, rumour has it, was designed as a cloud solution from the ground up. So let’s not get too carried away with Office 365. Exchange 2010 is the real agent of change here.
p.s. Here's a fun guide to Office 365:
So with all this choice and drive to push you to Cloud services, should you be jumping out of the plane without a parachute to get to the Clouds?
Confused about where to take your Microsoft Exchange architecture?
I mean let’s face it, it was less than year ago that Exchange 2010 SP1 came out and the Exchange world breathed a collective sigh and started upgrade planning. In that time we have seen the rise and replacement of Microsoft BPOS, a major increase in the number of Hosted Exchange providers and Microsoft's and shiny new baby – Microsoft Office 365 with Exchange Online. You also can't pick up an IT journal today without it being pasted full of talk about Cloud being "the future".
Obviously not (without your parachute), but some organizations will be able to transition all the way to Office 365 from their locally deployed Exchange 2003 deployment, while others will see the value and be tempted, but will not be able to migrate quite as easily. Don't forget there are also scenarios where a hybrid deployment that includes both on-premise and the cloud really makes sense. For example, users who previously didn't have email can now have corporate email for as little as $2.00 per user per month!
So there are lots of options, but also some pitfalls - so what to do?
Jack's beanstalk was the ultimate "Cloud Enablement Service". It got him off of the ground and to his destination in the clouds safely. Not only that, it was there to support him when he no longer wanted to be in the clouds. So is Exchange 2010 the magic beanstalk for our email Jack?
Exchange 2010 has a number of really nifty capabilities; among them is a native ability to be configured as a fully local, or part local - part Cloud (hybrid) deployment. There is still some heavy lifting to be done, however, to get to this utopia…
Firstly with data: moving large mailboxes around takes time and effort. We have come to a school of thought that says the data should be archived before you migrate, so that hardly anything needs to be moved; and that applies to a migration from an older version of Exchange to Exchange 2010 as well. The less data you move, the more you reduce the time the migration takes, the risk involved in the process and the potential of unplanned downtime.
Secondly, with routing: out of the box the routing capabilities in Exchange 2010 are excellent and numerous, but it still relies on having emails routed to an Exchange Server, either on premise or to Exchange Online. In an ideal situation, you want the right email delivered to the right location, without having to route traffic over WANs to the right location. In addition, a lot of people want to apply consistent security policies, inbound and outbound, to ensure their compliance and security requirements are being met.
Thirdly, continuity: hey we're biased! But seriously - nobody wants email to go down… it's always the nightmare scenario! Provisioning real time Cloud based continuity enables the IT admin to remain fully in control of the uptime across their email estate, be that Cloud, On-Premise or Hybrid.
After these points it becomes clear that Microsoft Exchange is Jack's house, the Giant's castle is Office 365 and Mimecast is in fact the magic beanstalk! An infrastructure that is architected to be as flexible as possible without exposing risk is what IT departments so desperately need, and the Cloud is an excellent way to deliver just that.
There are already ways to leverage the Cloud to deliver more flexible, responsive messaging architectures, even if you don't want to put all your mailboxes there right away.
Don’t wait until the giant has built higher walls. Plant your beanstalk today!