All posts tagged Exchange 2010

By on May 22, 2012

Exchange SP2 Hybrid Configuration Wizard and Proxy servers

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.

Add your comment (0)

Messaging Architect
NB Consult

Article Tags

, ,

By on April 27, 2012

OWA proxy diagnosis

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 External URL

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.

Add your comment (0)

Messaging Architect
NB Consult

Article Tags

, ,

By on June 28, 2011

Office 365 Finally Gets its Wings – So what now?

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).

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!’

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:

Add your comment (0)

Chief Strategy Officer
Mimecast

Article Tags

,

By on June 7, 2011

The Magic Beanstalk and Exchange 2010

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“.

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?

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!

Photo CC via o0bsessed and ïCliff on Flickr

Add your comment (0)

Advocacy Development Director
Mimecast

Article Tags

, ,

By on May 20, 2011

Microsoft Office365 Migration doesn’t have to be scary

New Flexible deployment and migration options with Exchange 2010 Service Pack 2

On Tuesday the Exchange team announced the impending release of Exchange 2010 Service Pack 2 and gave us all a sneak peek into what is being included in this pack.

As with Service Pack 1, it doesn’t disappoint and the list of goodness will make many users of Microsoft’s messaging platform very happy.

For me however, the most exciting bit of news is that the “Hybrid Configuration Wizard” is to be included.

Hybrid Configuration Wizard: Organizations can choose to deploy a hybrid scenario where some mailboxes are on-premises and some are in Exchange Online with Microsoft Office365. Hybrid deployments may be needed for migrations taking place over weeks, months or indefinite timeframes. This wizard helps simplify the configuration of Exchange sharing features, like: calendar and free/busy sharing, secure mail flow, mailbox moves, as well as online archive.

The ability to co-exist with other versions of Microsoft Exchange has always been incredibly important for customers who have to upgrade. This is especially true for so many customers that like to skip releases in order to maximize their investment in a particular version who then end up not being able to perform a direct migration to the latest version!

The Exchange Server Deployment Assistant has already been around for some time, providing customers with valuable information on what they have to do in order to migrate to new configurations and has included advice on how to set up co-existence between Office365 and earlier versions of Exchange.

This is an example image from the Exchange Server Deployment Assistent when selecting cloud and on-premises co-existence

This is brilliant news for Exchange Administrators looking at all the available options for deployment. It lays out clearly the options and in detail what needs to be done to achieve each of the architectural options available. Unfortunately- there’s no such thing as a free lunch, so there’s still plenty of configuration work to be done, but there could be some valuable upside in mixing Cloud and on Premise to produce Hybrid deployments. One scenario in particular I really like is the kiosk workers- previously they didn’t have corporate email and with Office365 they can have email from $2.00 per month.

We think it’s really important that IT can finally start making informed decisions on moving users to the cloud in careful controlled ways, that make sense to them and utilise the skills and experience they have. We’re helping our customers do this with our intelligent gateway services to swing selected users from one system to another without any impact on other users. This means that they can truly test the Cloud and assess all the softer things like network impact of running users in the cloud, latency and, most importantly, user experience before going “all in”.

This new wizard will hopefully go a long way to simplify the process of setting up co-existence and could well be the tool that causes organizations to dare to dip their toes in the water of Microsoft’s Office365 solution.

I can’t wait to see how much this Wizard manages to accomplish as it is about time it wasn’t only Mimecast advocating organizational flexibility.

Add your comment (2)

Advocacy Development Director
Mimecast

Article Tags

,

By on April 18, 2011

Complexity fears holding back Exchange 2010 upgrade?

In the last blog post of my Microsoft Exchange mini-series I suggested the idea that the complexity that surrounds a core Microsoft Exchange server might be what is causing some trepidation when it comes to upgrades.

By complexity; I mean the tangle of technology that has grown up around the Exchange server – all of those point solutions that have been added over the years to solve individual problems. All of the extra email management servers, the blinking lights, content filters, archives, disk arrays, AV/AS boxes, email encryption applications and other bells and/or whistles that are needed to keep the Exchange server up, running and efficient.

I understand that my post might have caused some alarm: In fact one IT manager emailed me to say he had never really considered all of those other solutions as a collective complex problem. He told me that each point solution was managed by different members of his team, and even other departments in some cases (like legal and professional standards for example), and that everyone just got on with the job.

Is there a collective noun for email management applications and tools? If there isn’t I’d like to suggest a a few; a “Hectic” or perhaps a “Chaos”, or maybe a “Delicate”? Answers on a post card please – the best suggestion wins a Mimecast complexity monster t-shirt.

This complexity we’re talking about is a bit of an old money solution isn’t it? I often ask CIOs what they would do if they were setting up a greenfield site; would they replicate what they’ve got or would they do it differently? They usually say something along the lines of; if only I knew then what I know now, when referring back to the problems they’ve had to patch up over the years. Of course with hindsight we wouldn’t re-create the past.

The complexity problem is one that affects many businesses.  Very few IT departments can really say they have designed out all their complexity. Upgrading central pieces of infrastructure, like Microsoft Exchange is undoubtedly an ominous task when you’re surrounded by stacks of supporting applications. Perhaps as you consider a Microsoft Exchange upgrade, hopefully to Exchange 2010, you’ll take a look at all those point solutions in your network; the vast array of blinking lights on that complex email management infrastructure and you’ll think that there must be a better way of doing this.

Maybe you’ll take this as the best opportunity you’ve got to ‘toss out the tin,’ get rid of those point solutions in an effort to iron out the complexity that has been handed down from generation to generation. The complexity problem isn’t one that is going to go away on it’s own, in fact the more patching, upgrading, installing and problem solving that goes on – the worse it will get and the larger that sprawl will become.

Now is the time to take a step back and look at what’s ‘become’ – then really & honestly decide what you can do to remove that complexity. What have you got to lose, apart from those pretty blinking lights – the blue ones were my favorite.

Add your comment (0)

CISSP, CCSK
Mimecast

Article Tags

, ,

By on April 11, 2011

Exchange 2003: What’s taking you so long, upgrade already!

In some ways, I’m quite surprised to hear IT managers and CIOs tell me they’re still running Exchange 2003.  But perhaps I shouldn’t be.  After all, more than a third of the Exchange customer base is flying this old bird.

Exchange 2000 and 2003 were big steps up from Exchange 5.5.  For most the upgrade meant new hardware, OS licenses and OS server version. Around that time I was involved in many infrastructure projects and noticed a definite buzz around the IT departments, like an excitement to be getting Exchange upgraded at last.

The leap from Exchange 2003, to Exchange 2007 or even 2010 is similarly exciting; but I’m also seeing a degree of caution this time too. Maybe it’s because the addition of 64bit hardware means another infrastructure upgrade, or maybe it’s something else?

I’m talking to CIOs almost daily, and the large percentage that have active Exchange migration projects generally say the same thing. The story usually goes like this:

Years ago when I had our first Microsoft Mail server and a windows 95 network – NT if I was lucky – everything was simple, relatively speaking. The mail server was attached to a modem which used to dial-up to the ISP and we’d send and receive our email in big batches. When ISDN arrived we really thought we were living in the space age.

Our early mail server, even up to Exchange 5.5, simply dialed up to the Internet and downloaded our email, the only problems being usually related to large attachments. Life was good, users didn’t complain, most of them didn’t really know much about this new email tool, let alone the Internet. My biggest headache was running out of paper rolls for the fax machine.

Somewhere in the middle of the 90′s I remember things getting a little more complicated. My staff started to complain that they were being sent emails about degree qualifications or heraldic titles, things they hadn’t asked for. Not long after that the first mass-mailing email worms made an appearance. Of course then my server room then started to fill up; a firewall and an anti-spam solution here, and anti-virus solution there, ISDN turned into an always on broadband connection. The millennium bug kept me awake for months.

The addition of those point solutions continued, and still continues today. I’ve added an email encryption box, an archive with a load of disk space attached, a DLP solution, a footer and disclaimer box, a RAS box (remember those?) which is now a VPN box, a BES server and now I’m being told I need to make all of this resilient to the same extent as dial tone.

And now you want me to strip out and upgrade the one platform all of this sprawling technology supports? Phew!!

I think that this buildup of point solutions in the email management environment has created a mountain of technology that sits at the heart of the concern our CIOs have today. Upgrading any core application of service inside a business is going to require some careful planning and consideration, and there are clear benefits of upgrade Exchange to the latest version. Many IT departments are passing on those benefits to the staff right now, but I think what slows down the process is all of this peripheral complexity.

Finding a way not to fear that complexity, or even better doing away with it all together, is going to make this Exchange upgrade, and the next few that are coming down the pipe, a lot more palatable. Don’t hold back, give your users what they want and modernize – if this means stripping out some of those bits of tin in the network, then now is as good a time as any.

Add your comment (0)

CISSP, CCSK
Mimecast

Article Tags

, ,

By on December 6, 2010

Exchange 2010 Migration Survey: Complexity, Clouds & Silver Linings…

We ran a survey of 590 IT Professionals at Exchange Connections 2010 in Las Vegas last month, from organizations of all sizes and sectors, asking them about their Microsoft Exchange Infrastructure and their plans to upgrade to the Microsoft Exchange 2010.

Exchange 2010 brings important advances to the email infrastructure and many organizations are looking forward to upgrading as soon as they can. Even with these new features the results of our survey show that overall email management remains a complex and resource intensive task and that could be holding up one of the most significant Exchange releases in a number of years.

Just 20% of IT Administrators surveyed have adopted Exchange 2010 to date- is that a really low number considering how long it has been released?

Although 51% are planning to upgrade to Exchange 2010 in the next 12 months, many people are still unsure what the real benefits will be. Just over 8% believe that its most valuable benefit will be simplified compliance.

From what I’ve seen of Exchange 2010, the rest of you are in for a pleasant surprise.

(The full survey results and analysis can be found here- registration required)

The results in more detail

Surprisingly spam and email security remain the biggest problem, even today when we largely think that spam is an old and well understood. As a result 50% of respondent organizations said they had at least two solutions for email, 20% said they had at least three. So are we really still dealing with the age-old problems?

The good news is that some 68% of you plan to upgrade to Exchange 2010 within the next two years, and around 51% within a year. That’s accelerated- about 13%- from our earlier Exchange Adoption report (registration required). However it looks like many people are worried about the resources required to achieve this.

We found that just over 25% of respondents said they didn’t have enough IT resources to tackle the migration.

The key question surely must be: have messaging architectures become too complex to adopt new technology with the resources available in house? This research certainly suggests things have become that way.

And in our day to day work  helping customers with Exchange, we often find that it’s the multitude of systems added to Exchange over the years, to solve single issues such as security or archiving, that create the complexity.  And the net result of all these additions is an architecture that is brittle, and is not resilient to change.  Administrators cannot be certain of the knock-on effects of one change to the rest of the systems, and are then faced with an impossible dilemma – upgrade at the potential cost of downtime or disruption, or stay put.   Their hands are tied by complexity.

Can you see why we’re obsessed with helping IT admins chase complexity out of their email systems?

Looking forward to Exchange 2010, we see that the most anticipated benefit of 2010 is the Enhanced Availability thanks to the new storage architecture of DAG’s etc. Yet this is in contrast to the 12% of respondents that told us that continuity was the most significant email challenge. Luckily those of you who had migrated agreed with us, the enhanced availability was the biggest bonus. I wonder why continuity is far down the list of proposed improvements yet top of realised improvements? One for another post I think.

So what next?

What are the ways of maximizing the investment in Exchange 2010?

  • Look for ways to simplify your messaging architecture to enable you to adopt new technologies faster, be more agile and deliver more value. Chase complexity out of the system- not introduce it.
  • Before migration is the time to get rid of any complexity that could cause downtime during a migration. Getting your mail architecture lean and mean before tackling the migration will reduce opportunities for disruption. For example Exchange MVP Nic Blank says: “Archive before you migrate”.
  • In the same vane- make email system integration a priority. Review your policies and procedures, take the opportunity of upgrading to Exchange 2010 to review more than just the application or OS. Bring everything together to reduce risk and dissolve complexity.
  • Consider leveraging the cloud for more than just storage. And the Cloud is not an all or nothing move either- there are ways to use Exchange 2010 on-premise, hosted or BPOS with Cloud services to extend its functionality and reduce cost- such as Continuity and Archive.

Add your comment (0)

CISSP, CCSK
Mimecast

Article Tags

, ,

By on November 2, 2010

Nic Blank Guest Post: Setting up CAS servers #HowTo

Guest Blogger Nicolas Blank is an Exchange MVP and  Microsoft Infrastructure Architect specializing in Exchange, Active Directory, architecture, systems management, migration and scripting. Nicolas spends what spare time he has writing, blogging and talking about Exchange and associated technologies. His blog can be found at: http://itproafrica.com

CAS Array’s may be a bit confusing…

  • What are they?
  • What do you call them?
  • Do CAS Array names need to be included in your certificate names?
  • What about load balancers?

What are they?
A CAS array is a logical Grouping of CAS servers within an AD site represented by a single DNS name, and not much more. Creating a CAS array doesn’t switch on a bit of magic and client requests stat heading to the CAS array automatically – what it DOES do, is create a logical – note logical – grouping of CAS servers – the physical grouping still needs to be achieved using a load balancing mechanism of some sort.

What do you call them?
It depends. You don’t want to call you array a name that you can reach from the outside – like mail.company.com – why? Outlook will expect to create an RPC (MAPI) connection to mail.company.com and fail. CAS Arrays don’t have much significance in your name space planning from the outside, so call them something that makes sense from a  name space perspective from the inside.

What about names on the certificate?
So you’ve created your CAS array, and now you want to rush out and buy a certificate for it. But why would you want to do that? MAPI doesn’t require a certificate. If you have internal services like OWA or OA (RPC over HTTP) that connect via an internal load balanced name, then it may make sense to add the name on a certificate, however that may be an internally trusted (note I didn’t say Exchange self signed certificate) certificate, and as such doesn’t need to reflect on your external certificate.

What about load balancers?
What about them? lets go back to the previous point. If you understand what protocols you’re publishing and where you’re publishing them to then understanding if you need a load balancer or not becomes easy. Lets look at MAPI and HTTP protocols:

IF you have a CAS array, then you’re probably using internal MAPI clients to over several CAS servers. You need a load balancing mechanism.

If you’re publishing HTTP based protocols to the outside (EWS,  OWA, ECP, OA, etc) then you may be publishing those protocols and load balancing via ISA/TMG/other (“other’s” always an interesting discussion :)  )  There’s a few ways of satisfying the load balancing requirement depending on which client you’re balancing.

Should HTTP based clients feature in your certificate naming?
Yes they should, but remember what you’re publishing and where to (inside/outside) and your certificate names may become a lot more obvious.

In summary
If all you’re doing with your CAS arrays is providing  MAPI, then you don’t need a certificate, however if you’re doing ANYHTING else, like OAB, EWS, Availability Service (AS), etc, then:

yes – you should have a certificate for those name spaces

no – that certificate doesn’t have to be an externally sourced certificate, but it may well be if it makes your planning easier.

So to answer the question – should your CAS array name reflect on your external certificate ? If you don’t want to roll out internal PKI (certificate) infrastructure, and you only have one site and that site is internet facing and you’re publishing http based name spaces then the answer may well be yes.

If you have more than one internet facing site, or have several load balanced names or have your own PKI, or don’t want to give away your internal name spaces – then the answer is – it depends. If the answer isn’t immediately obvious, then you may want to start by:

  • understanding the name spaces you want to address
  • understand which protocols you’ll use in those name spaces
  • understand if they’re internal or external facing or both

and take it from there.

Add your comment (0)

Advocacy Development Director
Mimecast

Article Tags

, ,

By on October 26, 2010

How to set the Exchange 2010 Database Size

Lots of people have been asking what the default size limits for Exchange 2010 databases are so I thought I would drill into that a little for you.

In Microsoft Exchange Server 2010 Standard Edition, there is a default “soft” database size limit of 50 GB. This can be increased as is required.

In Microsoft Exchange Server 2010 Enterprise Edition, there is no default limit configured.

To adjust the soft limit in Standard Edition, you’ll need to make a registry change and then restart the information store. The registry change is outlined in this article:

http://technet.microsoft.com/en-us/library/bb232092.aspx

PLEASE Note that the change is case sensitive.
If you do copy directly from the TechNet article, please watch out for a trailing whitespace as this can cause you some unlooked for pain…

Once you have the registry key set correctly and have restarted your information store, you will see the following event log entry: -

Log Name: Application
Source: MSExchangeIS Mailbox Store
Date: 25/10/2010 16:07:52
Event ID: 1216
Task Category: Storage Limits
Level: Information
Keywords: Classic
User: N/A
Computer: srv.domain.local
Description: The Exchange store Mailbox DB1 is limited to 75 GB. The current physical size of this database (the .edb file) is <1 GB. If the physical size of this database minus its logical free space exceeds the limit of 75 GB, the database will be dismounted on a regular basis.

As with Exchange databases since 2003 SP2, when the limit is reached, the database will be dismounted. It can be remounted again immediately but will be dismounted again as soon as the limit is checked.

Whitespace in the Exchange database is still taken into account when the size is calculated and is referred to as “logical free space” in the event log.

Add your comment (0)

Advocacy Development Director
Mimecast

Article Tags

, , ,
Previous Posts