All posts in Technical

By on August 17, 2011

Cloud based continuity insures against migration mishaps

Exchange migrations tend to be complex.  Even smaller organizations running Small Business Server with less than 75 users, may take a week or more to plan, prepare and execute their email migration.

Any business that’s been through a migration at least once will remember that most of the migration effort was spent in planning. Otherwise they may remember the large mop-up operation and the time spent visiting desktops, recovering mail and rolling aspects of the migration backwards and forwards.

Data loss (what PSTs?), client upgrades and wrongly migrated data tend to come to mind when thinking about what can go wrong, as well as the mail server that crashed during the migration. During a migration a fair amount of change is introduced and additional processing is forced onto both the source and target Exchange platform. For an older platform at the limits of its lifespan or operational capacity, the extra overhead an email migration introduces may be the straw that breaks the camel’s back.

Cloud based email continuity may act as insurance in this regard by enabling client continuity and transactional continuity in case the migration wobbles or breaks. Let’s explore that in a bit more detail.

Migrations are heavily process driven. In order to migrate, a fair amount of surveying, planning, lab testing, etc need to be accomplished. It makes sense to use the desktop visit of the plan/survey component to introduce the agents required onto the desktops in order to make client continuity possible.

If an Exchange server in the source or the target organization were to fail during the migration, Outlook clients would be redirected to the cloud, with little or no disruption to service or – crucially – the user experience. This allows the outage to be addressed, mail flow and client mail service to be restored without the pressure of fighting two fires concurrently – ie, a broken environment and a broken migration.

Cloud based email continuity allows you to benefit from the scale of the cloud as a side effect of leveraging continuity in the cloud, provided of course your users have the  required network or internet connectivity to beat a path to the cloud.

In our day to day lives we’re generally quite comfortable accepting the argument of personal insurance, which guards us against any number of possible scenarios, such as breaking a leg while skiing, medical insurance, insurance against theft, and so on. All of these boil down to paying a small amount of money to a much larger entity and thereby being guaranteed the benefit of that entity’s scale and reach in the case of something unfortunate happening.

As the idea of cloud on demand becomes more pervasive, insuring your migration in the short term against loss of email continuity makes as much sense as taking out insurance on your car before you take it on the road.

Add your comment (0)

Enterprise Consultant
Mimecast

Article Tags

, ,

By on August 4, 2011

The Eerie Quiet of your Junk Folder

Spam volumes on the Internet are down on this time last year. Great news, we can all relax and stop worrying about our Junk or Quarantine folders or that missing million dollar order that might he hiding therein.

Brian Krebs wrote a great piece on the take down of the most prolific botnets, which is thought to be the main cause of drought in spam. It’s certainly true to say that since the likes of Spammit, Rustock, Coreflood, Pushdo and Bredolab have been knobbled the output of spam has been noticeably less.

Less spam is great news, but I’m worried. I suspect this eerie quiet in our spam and junk folders is a false sense of security, and one that is waiting to draw us into a more evil and harmful place.

Think about it this way. You’re a spammer…

Imagine you’ve been spamming people since 1997, persuading them to buy penny stocks, herbal enhancements and more recently fake AV products. You’ve been getting frustrated at the shrinking rate of return on your efforts, for the billions of spam messages you send you’re only seeing a 0.002% return or even less; mind you, at $30 for a bottle of those fake-little-blue-pills that’s still a few million dollars.

Why the decline? Well because we the vendors, are doing a better job of detecting and dealing with spam. Giving customers a 98% anti-spam SLA means we’re confident we can keep that junk and rubbish out of their inboxes. The same is true for personal or webmail accounts, providers are simply getting better at protecting users.

Then just when you thought things couldn’t get much worse someone shuts down your botnet, or the FBI takes away you hosting provider. Bad day at the office?

This is why I am worried…

Given the business challenges the spammers face today it’s no surprise we’re seeing a decline in the volume of spam. But are we? The figures we’re looking at here are related to spam volumes delivered over SMTP based email, and those have been on the wane for some time. The recent precipitous drop makes me feel uneasy about the spammers new business models. You might be surprised I’m using the word ‘business’ in relation to spammers – don’t be; this is their business, they have offices, employees, health-care plans, support lines and staff retreats just like everyone else.

These business models embrace all the latest social media trends. Spammers are simply jumping on the new mechanisms we’re using to communicate, social media gives them everything they need and in many cases an even more targeted audience who are trained to ‘like’ the same things their peers do.

The deeper impact of this switch to less well evolved communication channels, is that the classic AV and AS protections deployed at the corporate gateway are fast being made redundant. Their rules unenforced, their quarantines empty. The threats they protect against are getting onto the network via other means that in many cases are far less well protected. The point is that the spam isn’t going away, it’s just changing and adapting to the marketplace; the users might be breathing a sigh of relief when they look at their inboxes, but I can guarantee you they’re not doing the same elsewhere – Try tweeting the word mortgage or loan and see what happens.

The old money was SMTP email based spam, but just like everything else in corporate IT consumerization is taking over; spammers & scammers are simply keeping up with the trends.

 

 

 

 

Add your comment (0)

CISSP, CCSK
Mimecast, North America.

Article Tags

, ,

By on August 1, 2011

Simplify your Cloud Migration

Migrating to the Cloud at the moment? Or at least planning to sometime soon? Lots of businesses are either moving key IT services out to the Cloud right now, or are planning to in the near future. Many organizations have adopted the “Cloud First” ethos, of procuring Cloud solutions for new platforms, rather than on prem.

Most IT departments I talk to have a solid plan for these migrations, a plan that’s been well thought out and even tested; but I think it’s fair to say some don’t. The latter is usually found when a C-level manager has dictated the use of a Cloud solution in a “get it done and don’t bother me with the details” type of management style. Very 1997 I know – I thought those days were over, Mr Gekko?

IT departments are unlikely to declare IT Bankruptcy and ship everything out to the Cloud over the next long holiday weekend, even if there is pressure from the C suite to get ‘Cloud first’ apps in place as quickly as possible. Migrating systems to the Cloud, needs careful planning and consideration, not just the move itself but an understanding of the data, processes, policies, APIs, people, & supporting platforms involved. In other-words, the details.

Take a move to the latest version of Microsoft Exchange for example. Of course I mean Office 365, but many businesses are still thinking about how best to get to Exchange 2010; you see they’re still lingering on their trusty Exchange 2003 infrastructure. We have spoken before about the complexity of the peripheral applications that surround the Exchange Server being a hindrance to a migration project, and how dealing with this complexity makes you and your business ‘Migration Ready‘. Most of the careful planning and consideration has to take into account all those peripheral applications and services first, extending the scope of the project into, perhaps, much more than was first considered. Hardly surprising we lose track of the details and start to focus on the final outcome.

So let’s stick with Microsoft Exchange as an example: How about this as an alternative strategy to get your business to the cloud. At Mimecast we often talk about a strategy called “Just Enough on Site” which is about finding the balance between on-site and Cloud. You’re augmenting your network with Cloud. Exchange 2010 is an on-ramp to Office 365 Exchange Online – what do I mean by that? Well, rather than try to move everything and everyone to Office 365 Exchange Online now, simply take your time. The Exchange 2010 migration should be a focused move to a platform that will allow you to introduce the Cloud into your business in small well planned steps.

Jumping into standing up cloud instances all over the place might work, but it’s far better to take your time to sweat the details for a while, and think about how you and introduce the cloud to the network over a number of smaller migrations rather than one great big one.

As they say round here – “Let the network see the cloud”.

Add your comment (0)

CISSP, CCSK
Mimecast, North America.

Article Tags

, ,

By on July 29, 2011

Happy SysAdmin Day!

Today is the 12th annual Systems Administrator Appreciation Day and everyone here at Mimecast wants to send a shout out to the techies who diligently serve their colleagues, customers and families, doling out their skills and time to make all of our lives that little bit easier.

We are also very interested in all things Microsoft Exchange related and as such to celebrate SysAdmin Day we have put together a little competition to give away a £50 worth of iTunes vouchers every week to SysAdmins that tell us a little about an experience that they had when migrating their users to a newer version of Exchange. The best story each week will get the voucher… sorry it won’t be everyone! We’re also asking everybody to share their story via twitter using a hashtag (#Migrate) so we can track and count the number of times your story gets mentioned. On September the 13th we will take the story with the highest overall number of retweets and that person will be given a cool new iPad 2!

So come on, join the fun, tell us about the pain, the misery and the joy of pulling an all weekend shift to get your users working fine first thing Monday morning!

For myself personally, my best/worst migration was one where I had to move a user base from Exchange 2000 to Exchange 2003…

Not a difficult task, just a very, very lengthy experience. Many hours spent watching exports and backups take place, waiting for mailboxes to be moved to the new server. That was a full weekend of waiting with only a few hours of real interesting work though without my active monitoring, things could easily have gone pear shaped. That was the first time I ever heard the term “the only difference between running a backup and watching paint dry is that paint doesn’t tell you how dry it is…”  I call this my best/worst because all the waiting drove me insane while I knew all my mates were off having a blast on their weekends, but it was one of my best experiences because it went through smoothly with no major hiccups and NO OUTSIDE HELP… Thanked my lucky stars that weekend for the good fortune of being supremely paranoid and in control of all the elements that I had to touch on to get the job done. AD, Firewalls, switches. A one man job well done…

Spread the SysAdmin love – I know at least three albums I would buy with that £50 but would certainly have fun deciding what else to get considering all the bands currently on tour…

Go to this page to submit your entry now!

Add your comment (0)

Enterprise Consultant
Mimecast

Article Tags

, ,

By on July 13, 2011

Demazter’s Migration Tip #3 – Preparing for Live Migration

Another in our series of Guest posts by Exchange specialists is Glen Knight, aka Demazter. Glen is tackling a tough topic- preparing your environment for a migration- essential for keeping the migration free from additional Costs, Risks and potential Downtime.

Glen Knight is the founder of Demazter IT Services, a UK based IT consulting company which specialises in installation, support and maintenance of secure environments based on VMWare and Microsoft technologies. He has been working in the industry for the past 14 years providing support, installation and consulting services for all sizes of businesses working with all versions of Windows, Microsoft Exchange and Small Business Server, including large scale Active Directory design and maintenance.

Glen also has a blog: http://demazter.wordpress.com and very active in one of the leading technical community sites - Experts-Exchange.

Welcome to my series of short tips on migrations. Whilst based on Microsoft migrations the same principles can be applied to any type of migration.

My first tip Migration Tip #1 – Source Server Health can be found here.

My second tip Migration Tip #2 – The Practice Run can be found here.

So, we now have a healthy source server and you have practiced until the match sticks snap, what next?

My third tip is about making sure you are prepared for the task ahead. Any type of migration needs to be taken seriously, it is a business critical operation you are about to embark on. If you are in any doubt about it at all, now is the time to say so, and if necessary call in help.

If you are happy with the process and confident you are able to complete the steps to achieve your goal then the next thing we need to do is plan a time to do it.

Most migrations are not time limited other than SBS to SBS migrations that have a limit of 21 days where both SBS servers can co-exist at the same time.

Make people aware of what you are doing, involve them, explain that you are expecting to have teething problems but would prefer if they collated them and then passed them to you when you ask for them. The last thing you want is to try trouble shooting whilst trying to complete a migration.

Find out if there is anything business critical happening (a big bid/contract etc that needs to be out just when you take the mail system offline) that could be delayed by the work you are carrying out, and if so, delay your migration. Talk to absolutely every member of staff. Manage Expectations.

In reality, if you get it bang on, the end users shouldn’t even notice and I would say 99% of the migrations I have done this has been the case. But there is always the odd one.

Have a recovery plan, know how to back out of what you are doing if it does go pear shaped. If you need to lock and migrate huge amounts of data then make sure you plan this stage of the migration for when people aren’t going to be using the system as heavily.

Document what you are doing, make notes of which stage you have got to and what action you have just taken.  This might seem like a waste of time, but take it from someone who has picked up a few failed migrations from people, it’s not.  Knowing exactly what stage you are at will help a consultant very quickly get to grips with the situation and this means a faster resolution.

And, most importantly of all, make sure you have backups! Take more than one, take one off-site, and do it different ways. I like to have a backup on either removable storage so I can access it quickly but also on tape just to be sure.

Watch out for tip Migration Tip #4 – The Migration

Add your comment (0)

Cloud Strategist
Mimecast

Article Tags

, , ,

By on July 11, 2011

Demazter’s Migration Tip #2 – The Practice Run

Next in our series of Guest posts by Exchange specialists is Glen Knight, aka Demazter. Glen is tackling a tough topic- preparing your environment for a migration- essential for keeping the migration free from additional Costs, Risks and potential Downtime.

Glen Knight is the founder of Demazter IT Services, a UK based IT consulting company which specialises in installation, support and maintenance of secure environments based on VMWare and Microsoft technologies. He has been working in the industry for the past 14 years providing support, installation and consulting services for all sizes of businesses working with all versions of Windows, Microsoft Exchange and Small Business Server, including large scale Active Directory design and maintenance.

Glen also has a blog: http://demazter.wordpress.com and very active in one of the leading technical community sites - Experts-Exchange.

Welcome to my series of short tips on migrations. Whilst based on Microsoft migrations the same principles can be applied to any type of migration.

My first tip Migration Tip #1 – Source Server Health can be found here.

My second tip is about making sure you are familiar with the technology you are migrating to.

For many people, migrating to a new technology will be the first and only time they perform this task. So, it’s always a good idea to familiarise yourself with the setup process before you do it for real.  With the use of virtualisation technologies we can install and test new products without the need for new hardware and without the possible impact on our live environment.

There are a number of virtualisation products that will allow you to do this on your desktop/laptop computer. You need to consider that most new products (if not all) will be based on x64 bit architecture. This does limit the virtualisation technologies that you can use on the desktop. Some of my favourites are listed below.

  • VMWare Workstation, this is a paid product but worth its weight in gold
  • VMWare Server, this is free for use and technically should only be used on a Server Operating System, but it does work on Desktop OS for testing purposes.
  • Virtual Box

Whichever technology you use, virtualisation will allow you to install the new software in a test environment, and keep installing it until you are happy with the process. Run through it 2, 3 even 4 times. Make sure you are familiar with the screens and what answers you are going to provide to the wizards. Take notes, even write a step-by-step of what you encountered and when you encountered it. Remember, the more you do now when you are in a safe “sandbox” environment, the easier and less pressurised the real thing will be. Don’t pay too much attention to the actual data you are entering as some of this will change when you do a migration as opposed to a new installation.

For the actual Migration Pick a migration guide for your technologies, it’s always best to use one that’s recommended by others and they have had good success with.  You will find my migration guides here. I use my guides in my own migrations and update them with any changes as often as possible.  Read the guide thoroughly before you start the migration.   It’s easier to get answers when you are not under pressure to fix things.

If you have the time and the inclination I would also suggest that you convert your physical source server to a virtual one. This will allow you to do a test migration with your actual source server. There are many tools for performing the capture and they depend on the virtualisation technology you are using and whether you want a free or paid product. Some examples of methods that can be used to convert physical machines to virtual ones can be found here.

Doing a virtual migration with a virtual copy of your actual source server is a great way to identify any problems you may encounter during the real live migration. You then have the opportunity to rectify these issues and then try the migration again. Once you are happy the migration has worked you are then in a position to do the live backup. I would be doing 3 to 4 virtual migrations just to be absolutely sure.

Watch out for tip Migration Tip #3 – Preparing for Live Migration in the next day or two.

Add your comment (0)

Cloud Strategist
Mimecast

Article Tags

, , , , , ,

By on July 7, 2011

Guest Post: BPOS to Office 365 Migration- Managing Without Mimecast (or not)

This is a Guest Post from a prolific blogger- Andy Kemp who has recently moved from a long standing customer of Mimecast and moved to a Microsoft Gold Partner UniTech, one that doesn’t have Mimecast in place but excited about what the toolset could do for them. One of the recent things he’s been tasked to do is their Migration from BPOS to Office365 both internally and for a number of serviced clients, and it’s interesting to see what life without Mimecast is like…

I have used Mimecast in the past for several reasons, email archiving, antivirus and malware protection, business continuity and compliance. These are all great reasons for using it but one other is for email migration. In the past when I have done system upgrades it has been pretty painless and stress free, moving from Exchange 2000 to Exchange 2003 for example.  However I think that now it is a completely different ball game as the Cloud is involved.  Moving to the Cloud is again relatively painless (just a different approach), at least from a technical point of view; politically it can be very stressful.  But moving from Cloud to Cloud for me at the moment is proving a bit of a headache.

I’m in the process of moving from BPOS to Office 365, and you would think that this would be a pretty straightforward migration moving from one Microsoft Online Service to another.  Is it straight forward? No! As a Microsoft Gold Partner and one of Microsoft’s Cloud Partners we were an early adopter of Office 365 closed beta and I was getting to like it more and more the more I used it throughout the testing.  However, when it came to domain migration I started to like it less.

The main issue for me migrating from BPOS to Office 365 is migrating your domains from one to the other. It can take anything up to 48hrs for the domain to be removed from BPOS and FOPE (Forefront Online Protection for Exchange) and only then can you add the domain in to Office 365. Then if something had gone amiss and you needed to remove the domain from Office 365 (like I had to) you would have to wait for anything up to 24hrs. It turned out my problem was that the domain had not been fully deleted from FOPE on the BPOS side.

All this time means that your email might well be unavailable (more than likely to be honest) and could have serious knock on affects to your business as email is now treated as one of the most common ways in which we communicate with our customers.

The main drive for using Mimecast in my previous place of employment was to ensure that email was accessible at all times, even when the in house exchange servers were unavailable. This could also mean when you are migrating from one service platform to another, and I would say that the same principle could be applied to a hosted email service.

Through using Mimecast you could very easily remove the headaches from your migration from one service to another as the continuity that Mimecast offers would provide you with email delivery during the process of the migration. You’ll effectively be using Mimecast as a pivot I guess for the transition.

My migration from BPOS to Office 365 has been in process for four days now.   Fortunately it is a non-critical domain I am testing with, but if this was a live email domain that I relied on for business my customers would be receiving NDRs for every email that is sent in to me.  This could well be avoided by having Mimecast in the equation as email would be delivered through Mimecast to your email service, regardless of it being on premise or hosted.

Moving email platforms is something that you do not want to do or need to do on a regular basis but if you do need to migrate your email then you will find that having something like Mimecast will make the migration even simpler and reduce your down time to a bare minimum if any.

Even if you are doing a simple email migration/upgrade you’re at risk.  Sure you will have a full backup of your server to revert back to if the migration/upgrade were to go pear-shaped –  if you did have to do a restore how long would that take you? An hour? A day? A week? I previously worked for a law firm and lawyers like to hold on to their emails; I had mail stores in the excess of 150GB, mailboxes of 15GB and over! The restoration of the email data would take about a full day (in the excess of 400GB Email data) but once the stores were restored I would then have to do an offline defrag on each mailstore db which could take anything up to 8 hrs per mail store meaning email would be down for a week. With Mimecast you could work on your exchange servers for that week and still be able to send and receive email, even by using outlook on the user’s desktop.

How long could your business survive with email down time? I guess in all honesty not very long.

I eventually got the domain working fully in Office 365 after a few calls to Microsoft and a few days of waiting! Email was being delivered to the right domain in the right service, finally!

It was a good learning curve (which is why we did it with a test domain) so when it comes to moving the live production email domain we know exactly what to do and what to expect. I am hoping that the production migration goes a bit more smoothly now! Mimecast will not take every risk out of email migration, but it will certainly give you a great level of continuity if you did face any problems when it comes to email migration.

 

Add your comment (0)

Cloud Strategist
Mimecast

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)

Communications Director
Mimecast

Article Tags

,

By on June 21, 2011

Demazter’s Migration Tip #1 – Source Server Health

Fifth in our series of Guest posts by Exchange specialists is Glen Knight, aka Demazter. Glen is tackling a tough topic- preparing your environment for a migration- essential for keeping the migration free from additional Costs, Risks and potential Downtime.

Glen Knight is the founder of Demazter IT Services, a UK based IT consulting company which specialises in installation, support and maintenance of secure environments based on VMWare and Microsoft technologies. He has been working in the industry for the past 14 years providing support, installation and consulting services for all sizes of businesses working with all versions of Windows, Microsoft Exchange and Small Business Server, including large scale Active Directory design and maintenance.

Glen also has a blog: http://demazter.wordpress.com and very active in one of the leading technical community sites - Experts-Exchange.

Welcome to my series of short tips on migrations. Whilst based on Microsoft migrations the same principles can be applied to any type of migration.

My first tip is around source server preparation.

No migration is an easy migration, there is always potential for something to go wrong. All we can do is try to minimize this risk.

The biggest risk comes from the system we already have in place, the integrity of this system is paramount in ensuring a successful migration.

Making sure your source system is healthy and configured correctly will go a long way to ensuring you have a smooth migration.

Use analyzers and health check tools that are available from the vendor. Microsoft, for example, have a number of best practice analyzer tools. These can be used to identify any problems the system may have and provide advice on how to resolve them. Some of the ones I use regularly are listed below:

In a Microsoft migration I will use tools like DCDIAG, NETDIAG, REPLMON and REPADMIN to check for errors, even if it’s a single server. You would be surprised how easy it is to misconfigure a single server. Further details on the usage of these tools can be found here:

Make sure the source system is up-to-date. All updates, service packs etc need to be applied. This may seem like a waste of time on a system that you are soon to be migrating out of your network but really it isn’t. New products from the same vendor normally rely on the source system being up-to-date. I have been known to spend hours installing service packs and updates on a source server.

It’s worth spending the time getting this part of the migration perfect. There are no timescales in play here you can take your time, once you start migrating there are pressures at play that will make the slightest hiccup seem like your whole world is imploding. I would consider this part of the migration process the most important, and therefore if you are not comfortable with this process, hire someone who is. Buying in consulting services to make sure the server is healthy can save you a lot of money.

Watch out for tip Migration Tip #2 – The Practice Run in the next day or two.

Add your comment (0)

Enterprise Consultant
Mimecast

Article Tags

, ,

By on June 14, 2011

Guest Post: Migrating between email servers- SMTP Namespace Sharing (Part 2)

Fourth in our series of Guest posts by Exchange MVP’s is Clint Boessen, in the last post he explored the complexities of sharing an email domain- known as a SMTP namespace- essential when migrating between servers or running multiple mail servers. In this post he walks you through the technical steps needed to achieve this when migrating from 2003 to 2010.

Clint Boessen is an Exchange MVP from Western Australia focusing on Microsoft Business Productivity solutions.  Clint works for 4Logic Pty Ltd, an Information Technology and Consulting Company who is a Microsoft Partner predominately focusing on Microsoft.  Clint has a diploma in Network Engineering, an MCSE, MCITP and is currently working towards his MCM in Exchange Server. Clint maintains his own blog containing lots of hints, tips and tricks for IT Professionals which can be viewed at http://clintboessen.blogspot.com.

Part 2: Configuring SMTP Namespace Sharing between Exchange 2003 and Exchange 2010 organizations

Welcome to part two of this three part series on SMTP Namespace sharing. In part one of this series we had a look at what SMTP Namespace sharing is and how it can be configured across multiple email systems. If you missed part one of this series you may view it here Part 1: An overview on SMTP Namespace Sharing.

In part two we are going to look at how to configure SMTP Namespace Sharing between two Active Directory forests. One forest will run Exchange 2003; the other will run Exchange 2010. I have created a lab environment for our two forests which I have used to document the configuration steps. SMTP Namespace Sharing will be setup for @contoso.com.

SMTP Namespace Sharing on Exchange 2010

The first thing we need to configure in Exchange 2010 for SMTP Namespace sharing is the accepted domain. Accepted domains are any SMTP namespace for which an Exchange organization sends and receives e-mail for a given SMTP Namespace. Accepted Domains can be configured in one of 3 ways:

  • Authoritative Domain To specify that e-mail messages are delivered to a recipient that has a domain account in your Exchange organization, select this option.
  • Internal Relay Domain To specify that e-mail messages are either delivered to recipients in your organization or relayed to a server outside your Exchange organization but still under the authority of your company or IT department, select this option.
  • External Relay Domain To relay e-mail messages to an e-mail server outside the Exchange organization, select this option.

To configure SMTP Namespace Sharing for @contoso.com we must setup @contoso.com as an Internal Relay Domain.

Now that Exchange 2010 is able to accept email for @contoso.com provided we have our Receive Connectors configured correctly. Now we must create a Send Connector to route the email to the Exchange 2003 forest for any unresolved recipients. Follow the below steps for setting up the Send Connector:

Note: To achieve the correct routing behavior, you must specify a Hub Transport server as the source server for the Send connector. If the Edge Transport server is specified as the source server for the Send connector, a routing loop will occur.

  1. In Exchange Management Console under Organization Configuration à Hub Transport click New Send Connector on the action pane.
  2. Provide the Send Connector a descriptive name. The usage type determines the default permissions sets that are assigned on the connector and grants those permissions to the trusted security principals.
  • Internal Select this usage type if the e-mail system with which Exchange 2010 shares an address space is another Exchange 2010 organization
  • Internet Select this usage type if the e-mail system with which Exchange 2010 shares an address space is a third-party e-mail system.

Select Internet as the foreign email system is Exchange 2003.

  1. On the Address space page, click Add. In the SMTP Address Space dialog box, enter the domain name to which this connector will send mail, for example, contoso.com or *.contoso.com. You may select the Include all subdomains check box to use this connector to send e-mail to all subdomains of the address space. If necessary, you can also provide a specific cost for this connector. When you’re finished, click OK. Leave the Scoped send connector check box cleared, and then click Next.

  2. On the Network settings page, select Route mail through the following smart hosts. Click Add.
  3. In the Add Smart Host dialog box, select IP Address or Fully qualified domain name (FQDN) to specify how to locate the smart host. If you select IP Address, enter the IP address of the smart host. If you select Fully qualified domain name (FQDN), enter the FQDN of the smart host. The sending server must be able to resolve the FQDN. When you’re finished, click OK. To add more smart hosts, click Add, and repeat this step. If you want to use a specific list of external DNS servers instead of the DNS servers specified in the adapter settings, select the Use the External DNS Lookup settings on the transport server check box. When you’re finished, click Next.

  4. On the Configure
    smart host authentication settings page, select the method that’s used to authenticate to the smart host. The following smart host authentication methods are available:
  • None
  • Basic Authentication
  • Basic Authentication over TLS
  • Exchange Server Authentication
  • Externally Secured (for example, with IPsec)

Exchange 2003 by default automatically allows Anonymous email from all IP addresses on its internal subnet. As a result choose None under Authentication type.

Note: It is recommended to configure Basic Authentication over TLS in production environments.

  1. Click Next.
  2. On the Source Server page, click Add to add a source server. By default, the Hub Transport server that you’re currently working on is listed as a source server. In the Select Hub Transport or Subscribed Edge Transport dialog box, select the Hub Transport servers that will be used as the source server for sending messages to the shared address space. When you finish adding source servers, click OK. Click Next.

  3. On the New Connector page, review the configuration summary for the connector. If you want to modify the settings, click Back. To create the Send connector by using the settings in the configuration summary, click New.
  4. On the Completion page, click Finish.

SMTP Namespace Sharing on Exchange 2003

Configuring Exchange 2003 for SMTP Namespace sharing is very different to Exchange 2010. Exchange 2003 must be authoritative for the primary SMTP address space that is specified in the default recipient policy. Exchange 2003 does not have to be authoritative for any other SMTP address space configured on the default recipient policy. To configure SMTP Namespace sharing we must ensure Exchange 2003 is not authoritative for @contoso.com as this will not allow Exchange 2003 to forward unresolved recipients for @contoso.com to Exchange 2010. As Exchange 2003 must be authoritative for the primary SMTP address specified in the default recipient policy we must create a second recipient policy to set @contoso.com as primary and then click to clear the This Exchange Organization is responsible for all mail delivery to this address check box in the SMTP Address Properties dialog box. This creates the same effect as configuring “Internal Relay Domain” on an Exchange 2010 Accepted Domain shown above.

Currently my Exchange 2003 server has @contoso.com setup as my primary SMTP Address on my default recipient policy. As you see I am unable to unselect This Exchange Organization is responsible for all mail delivery to this address as it is the default policy.

We need to share the @contoso.com SMTP address space which is specified as the primary SMTP address space in the default policy. As a result we must create a new SMTP address space in the default recipient policy. The new primary SMTP address space that you create does not need to be valid in the Internet DNS. You can use a private SMTP address space such as @localhost or @example.local. In this lab environment we will be using the address space @source.local which Exchange 2003 will use to route internal e-mail messages.

Perform the following configuration on your default recipient policy.

  1. Start Exchange System Manager, click Recipient Policies, right-click Default Policy, and then click Properties.
  2. In the Default Policy Properties dialog box, click the E-Mail Address (Policy) tab, and then click New.

  1. In the New E-mail Address dialog box, click SMTP Address, and then click OK.
  2. In the SMTP Address Properties dialog box, type the SMTP address space for which you want Exchange to be authoritative.
  3. Click to select the This Exchange Organization is responsible for all mail delivery to this address check box, and then click OK.

  4. Click the new SMTP address that you created, and then click Set as Primary.
  5. Remove the SMTP address that you want to share from the default recipient policy. To do this, click the SMTP address that you want to share, and then click Remove.

Now create a new recipient policy to be used for SMTP Namespace sharing.

  1. Create a new recipient policy for the shared SMTP address space. To do this, right-click Recipient Policies, point to New, and then click Recipient Policy.

  1. In the Properties dialog box, type a name for the new recipient policy, click Modify, and then click OK.

  2. Click the E-Mail Addresses (Policy) tab, and then click New.

  3. Click SMTP Address, and then click OK.
  4. In the Address box, type the SMTP address space that you want to share. For example, type @example.com, or type @microsoft.com. In this lab we used @contoso.com.
  5. Click to clear the This Exchange Organization is responsible for all mail delivery to this address check box, and then click OK.

  6. Click the new SMTP address that you created, and then click Set as Primary.

  7. Click OK, and then click Yes when you receive the following message:

    Note: If you use the above procedure and update user SMTP addresses using a recipient update policy, ensure a system state backup of Active Directory is performed on a domain controller before commencing the changes. ADModify.NET is an alternative way for updating user SMTP email addresses if the recipient update service is disabled. This is often the preferred way of performing the task as ADModify.NET allows you to revert changes.

After you configure the recipient policy for SMTP Namespace sharing, you must specify the means for Exchange to determine where to route messages that do not resolve to an object in Active Directory. To do this, create an SMTP connector that has the shared SMTP address space in the Add Address Space dialog box of the connector object. If you do not add the SMTP connector with the shared address space, any incoming e-mail that is destined to the shared SMTP address space is interpreted as an attempt to relay. In this situation, Exchange does not accept the incoming e-mail. Additionally, you must specify a server to which Exchange will forward unresolved e-mail. You can specify this destination server by using its host name or by using its IP address.

Perform the following steps to create the SMTP connector.

  • In Exchange System Manager, right-click Connectors, point to New, and then click SMTP Connector.

  • In the Properties dialog box, type a name for the new connector in the Name box.
  • Click Forward all mail through this connector to the following smart hosts, and then type the host name of the destination computer or the IP address of the destination computer. You must type square brackets ([ ]) around the IP address. For example, if the IP address of the destination computer is 192.168.1.10, type [192.168.1.10]. In this lab the destination smart host is Ex2010.destination.local. Hostnames do not require brackets around the name.

    This computer will receive all e-mail that is not resolved to objects in Active Directory.

  • Click Add, click an Exchange server in the Add Bridgehead dialog box, and then click OK.

  • Click the Address Space tab, click Add, click SMTP in the Add Address Space dialog box, and then click OK
  • In the Internet Address Space Properties dialog box, type the shared SMTP address space in the E-mail domain box. When you type the shared SMTP address space, do not include the at (@) symbol. For example, type example.com in the E-mail domain box. Then, click OK. In the lab environment we added contoso.com.
  • Click to select the Allow messages to be relayed to these domains check box. Because Exchange must also receive messages for the shared e-mail address space, you must let Exchange relay messages to this domain. This setting let’s all the SMTP virtual servers that are listed under Local bridgeheads on the General tab accept messages for the shared e-mail address space.

  • Click OK.
  • This email will be coming into Exchange 2010 from anonymous. A receive connector needs to be setup on the Exchange 2010 server to allow anonymous emails to come from the IP addresses of the Exchange 2003 servers in the source forests. For information on how to do this please see:

    http://clintboessen.blogspot.com/2009/07/allow-network-applications-to-relay.html

SMTP Namespace sharing is now configured between both Exchange 2003 Active Directory and Exchange 2010 Active Directory forests. There is another method for configuring SMTP Namespace sharing on Exchange 2003. This method involves modifying the SMTP virtual server under “Forward all mail with unresolved recipients to host”.

I do not recommend this method for two reasons.

  • It does not stamp the message header which can result in mail loops.
  • If you have any users accounts in the Exchange 2003 forest with the Exchange attributes associated to the account but no mailbox, whenever a user in the Exchange 2003 forest sends an Exchange enabled user account an NDR will be generated stating “A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator“. It is not smart enough to realise the user does not have a mailbox and to forward it to Exchange 2010. In Exchange users that have Exchange attributes enabled but no mailbox are known as “Mail users” whereas users that have mailboxes are known as “Mailbox users”. There are times you want Mail users and not Mailbox users. When we perform cross-forest mailbox migration the source user account will revert to a “Mail User” and will still contain the Exchange 2003 attributes. These attributes and SMTP email address are important for keeping the GAL (Global Address List) populated in the source domain.

This concludes part two of this three part series. In part three we will be setting up SMTP Namespace Sharing between Exchange 2010 on-premises and Office 365 in the cloud.

Add your comment (1)

Cloud Strategist
Mimecast

Article Tags

,
Previous Posts
Newer Posts