Category: Exchange Server 2007

Upgrading from Exchange 2003 to 2010? Plan for These Changes

Among our Exchange 2010 upgrade projects, we encounter a few more clients still using Exchange 2003 than we do on Exchange 2007. We also see a lot of the 2003 clients struggle following a 2010 upgrade.

The differences between Exchange 2003 and 2010 are more severe than those between 2007 and 2010. Clients jumping from Exchange 2003 are faced with differences in administration, potential for backwards-compatibility issues, etc. For 2003 admins, it's like getting out of an SUV and getting into a racecar – some adjustment is needed!

Last week I came across this TechRepublic article. It lists 10 reference points for those moving up from 2003 to Exchange 2010:
10 Things to Consider Before Transitioning from Exchange 2003 to 2010

I wanted to highlight this for our blog audience, so future clients have some advance notice on changes they'll have to make.

In particular, I wanted to emphasize these points:

  1. Exchange Server 2010 is 100% 64-bit. 32-bit servers (such as those used by Exchange 2003) will not work.
  2. Your admins WILL need retraining. The difference in server roles between 2003 and 2010 alone merits it. Not to mention the new Exchange Management Console.
  3. In 2010, OWA is now located on the Client Access server. Setting up OWA is not required at first; setting up a Client Access server is.
  4. Plan to keep your 2003 Exchange servers active until the 2010 transition is made completely. If you remove the 2003 servers too early, users with Exchange 2003 mailboxes may not be able to get their email.
  5. And one point partially covered in the article: If you're running Windows Server 2003 or SBS 2003 and want to move to Exchange 2010, upgrade your primary servers too. 2008 versions of Windows Server and SBS are out; a clean upgrade on both sides is easier. And doing both at once just makes sense – saves you additional headache later.

This is a free warning from us ahead of time. Exchange 2010 is a big step ahead in terms of Unified Communications, new capabilities like Auto-Archive, etc. It just has a learning curve,like all rebuilt software.

Facebooktwitterlinkedinmail

A Basic Plan for Unified Communications User Adoption

Last week I said I'd go into more detail about UC user adoption. In keeping with that, I thought I'd write out an adoption plan from some of our OCS/Exchange deployments.

As you probably know by now, user adoption is the other half of a successful server installation. It”s one thing to get new systems up & running. And another thing entirely to convince/persuade/poke people into using them.

One way to push user adoption is, as I mentioned last time, to take away the users' existing option. I discuss this in Step 6 below. But if you do that, you have to give them something else. (It's kind of required.) That's what the rest of this plan is for.

Note: Technical specifications on implementing UC components (Exchange 2010, OCS 2007) will not be included here due to their length. Full implementation processes can be found in the following Microsoft resources.
Deploying Exchange Exchange Server 2010: http://technet.microsoft.com/en-us/library/dd351084.aspx
Deploying Office Communications Server 2007 R2: http://technet.microsoft.com/en-us/library/dd425168(office.13).aspx

Step 1 – Sketch out implementation plan.

Essentially, “plan out Steps 2-6 ahead of time.” Also, consider file transfer times. Factor out any offline time needed to build the new UC servers. Check on the Web for any possible hardware issues before and during implementation.

Step 2 – Determine a Switchover Point. Announce it.

Send 2 emails and make an internal communications post (forum, intranet, whatever you use). Announce a point at which the company will switch to Unified Communications. Make this unavoidable. (Someone WILL claim they didn't hear about it when it's too late.) Provide a brief how-to and benefits statement, so they know they're getting something good out of it.

Step 3 – Implement UC technology at server-level.

Self-explanatory. Refer to the above URLs for documentation.

Step 4 – Invite a group of users to test it.

Deploy all UC tools to a select group of people who are technically savvy. Preferably people from multiple departments and/or branch offices. Having them test for system errors accomplishes two things.
One,it tests the UC technology in real-time from different physical locations.
Two,testing creates a small group of advocates within the organization. (Make sure to tell the group ahead of time that people may ask them for assistance during adoption. And get their OK.)

Step 5 – Furnish all users with a training kit.

Instruct them to familiarize themselves with the new UC interface. Here's an OCS 2007 R2 Adoption and Training Kit from Microsoft. You'll probably want to add information about your organization's specific setup to this too.

Step 6 – Evaluate alternatives.

I refer to two things here when I say “alternatives.” One is your existing communication options. Which of these options should you phase out? When should you do it?

The following can usually be phased out following Unified Communications implementation:

  • Non-OCS desktop phones
  • Third-party IM clients
  • Fax machines
  • Voicemail systems
  • Third-party conferencing solutions

Two is Communicator Web Access (CWA). Will you need to implement CWA? I would say yes, as it makes a good backup when someone can't access their own system or is having trouble connecting with Office Communicator. CWA should be in place at switchover.

Step 7 – Remind users of Switchover Point.

Email all users again. Make it a short interval – 7 days, for example. Mention your advocates as people to ask if someone has a quick question. (This way people don't all hound one person–namely you.)

Step 8 – Switch Over to UC!

On the appointed day…
–Deploy the Unified Communications technology for all users.
–Deactivate the communication options being phased out. See previous post.

And prepare for the inevitable grumbling that comes with change.

Have you used a user adoption plan like this? Planning to use this one in future UC upgrades? Please let a comment and let us know. Same if there's something you think should be added here. I have an Edit button and everything.

Facebooktwitterlinkedinmail

Hosted Exchange VS. Google Apps: Which Works Better for Small Business?

I saw a great discussion thread on LinkedIn today (view the thread here) – about whether a consultant”s client should move to Hosted Exchange or Google Apps.

The replies leaned a bit more toward Google Apps than Exchange. Many good points about how much IT help is available/budgeted, “getting what you pay for,” simplicity of Google, familiarity of Exchange/Outlook, etc.

You'd think I would weigh in on the side of Hosted Exchange. It is one of our services (and a very popular one at that), but even we recognize that at times something simpler, like Google Apps, makes for a better solution.

See, when we get a client who wants to move to hosted services, there's a lot of factors to consider. Many of them are addressed in the thread: mobile users, growth potential, available budget,available IT expertise/extra support hours needed,and the client's needs for the service.

We weigh these between two prime factors: The size of the business, and what their day-to-day practices are surrounding email.

Can A Business Outgrow Google?

Let's divide up some factors between size and daily practice here. Under size, we can list things like:

  • How many mobile users a company has – iPhones, Blackberries, Android, etc.
  • How many Outlook users there are (and how often they use it).
  • What amount of on-site IT is in place, or do they rely on contracted IT support?

Both systems – Google Apps and Hosted Exchange – can sync with iPhones and Blackberries. (Androids MIGHT prefer Google, but I can't imagine why.) Outlook however leads more people to Exchange than away from it. One big intangible with email is how many users “live in” Outlook. True, Google Apps Premier Edition will sync with Outlook, but the difference is that those Apps accounts are on Google's servers, not hosted servers you contract. Which leads to the question of IT support. Who do you want to support your email? How fast of a response time do you need?

Under day-to-day email practices, we'll put these factors:

  • What are users' preferred communication methods?
  • How much email storage is needed?
  • How often do users share calendars?
  • Who's administering?

If email is the big communication tool (and it is for most businesses), then even a smidge of downtime is potentially catastrophic. We admit it, Exchange isn't perfect here…but then, nobody is. Google Apps does beat Exchange on default account space (25GB against 5GB). But shared calendaring brings us back to Outlook and its rich invite features.

We're back at the administration question. Many LinkedIn posters recommended contract IT support, especially if you're a smaller company. Of course Google provides support for Apps…but interfacing with other systems? Not so much.

What's the Verdict?

So where did we end up? When is Hosted Exchange a good choice, and when is Google Apps better? I'll give my answers in terms of the two prime factors I mentioned.

IN TERMS OF BUSINESS SIZE: For startup-level businesses, Google Apps makes more sense. Little infrastructure is needed, and it”s easier for a few people to adapt (they probably use Google already). Generally, the larger the business, the more likely Exchange will better suit them.

IN TERMS OF DAY-TO-DAY EMAIL PRACTICES: If a company already uses Outlook, we recommend they go Hosted Exchange. If they have an IT department already, so much the better. If not, and they don't want to spend much, then go Google Apps and get some local support in case integration hits a snag.

Of course, this is just one blog post. Do your research before contacting suppliers.

Which do you use, Google Apps or Hosted Exchange? Let me know in the comments.

Facebooktwitterlinkedinmail

Top 3 Questions People Ask Us Re: Exchange 2010

Sorry about not posting this yesterday. We”re embroiled in a big new client website (yay for that!).

Last week I blogged about the 3 most frequently-asked questions we get on OCS 2007. I promised I”d do the same for Exchange Server 2010, so here you go. We get easily the same amount of questions on Exchange 2010 as OCS. More sometimes. But far and away, these are the most common.

1. Is it out yet?
Yes it is. Exchange 2010 has been available in full release since November 9th. The RC has been out for a while now; if you run it, best to switch to full version ASAP. (Luckily the RC can auto-upgrade to RTM.)
Here”s Microsoft”s Licensing and Pricing FAQ for some help on that.

2. Does the Exchange 2010 Standard Edition support Archival and discovery?
It”s recommended that you use the Enterprise Edition if you want Archival and discovery. Archival for Enterprise has been delayed until Q1; I believe to test some additional workloads. But once it”s finalized, that”s a more secure, better-running bet.

3. What do we need for the upgrade?

  • A 64-bit-capable server. If you don”t already have one, that is.
  • Windows Server 2008 (or 2008 R2).
  • Backups of your existing mailboxes.
  • A day or two. (Really; it”s a fast upgrade.)

Pretty simple huh? All too often we skip over simple things though, assuming everyone else “gets it” right away. Dangerous assumption. Someone else may be distracted, or too busy, and they miss the obvious. So it pays to remind.

(By the way, another reminder – Exchange 2010 also works great as a hosted option. Email me if you want to hear about that!)

Next week, Top 3 questions we get on VoIP.

Got a question of your own on OCS 2007 or related technology? Leave a comment or email me.

Technorati Tags:

Facebooktwitterlinkedinmail

If You Use OCS 2007, SQL Server or Windows Server 2008, Get the Latest Patches

Yesterday Microsoft released a big group of patches. 34 of them in fact; Microsoft”s biggest Patch Day ever.

As far as I can tell, this update does not include patches for OCS. But it does patch Windows XP/Vista, Windows Server 2008, SQL Server, and Internet Information Server (IIS). All of which are important to OCS 2007”s function. So I definitely recommend patching ASAP if you use OCS. Or even if you don”t.

The Security Bulletin is available here: http://www.microsoft.com/technet/security/bulletin/ms09-oct.mspx
With full details on what software is affected, why, and how critical the patch is.

All of the patches are available on Microsoft Update. If you want to download them directly, you”ve got a few options:

  • Click the “Affected Software and Download Locations” subhead for a categorical listing. It”s divided up by Windows System, Office Suites, Server Software, Developer Tools & Security Software. Locate the software you want to patch under its appropriate category and click the download link.
  • Click the “Detection and Deployment Tools and Guidance” subhead for links to two more options – the Download Center & the Update Catalog.
    • There”s guidance on updating servers under here too.

Chances are if you use Microsoft servers, you already knew about this batch of patches. I highlighted it just in case it got lost/delayed in the shuffle. Server and database patches can prevent a lot of nasty things – like the server crashing and not waking back up. Let”s skip that,shall we?

Technorati Tags:

Facebooktwitterlinkedinmail

The Risks You''ll Tackle in OCS 2007

I”ve talked a lot about some of the benefits from using OCS 2007.
Now I”d like to talk about the risks.

Every network-based application carries a risk. Either in terms of security breaches, or in terms of employees abusing the system in some way. Such actions are rare. And with a little preparation, they almost never occur.

That”s why I wanted to give this warning beforehand. So you”ll take the following into consideration during your OCS planning & setup process. You can avoid most of these risks entirely if they”re planned against.
Read more… »

Facebooktwitterlinkedinmail

Exchange 2010 is in Beta Already!

Just a heads-up – this is the “OCS Insider” blog. But I plan on talking about technologies related to OCS too. Like Exchange Server.

Which is why I”m linking to this article from InfoWorld.com –
First Look: Exchange Server 2010 Beta Shines

Yes, the beta for Exchange 2010 is already out.

InfoWorld publishes some pretty good IT articles, in my opinion. This “first look” is no exception – lots of information about the new beta in here.

My thoughts?

Refining most of the major services from Exchange 2007 – Great!

Dropping support for Windows Server 2003/Requiring Windows Server 2008 – Problem for cash-strapped businesses. With that in mind, I think it”s good that Exchange 2010 won”t be due out until late 2009. More time for upgrades later.

I also found this on Page 4:

“The Outlook 2010 client and OWA both will have conversation view, and both will include integrated instant messaging and voice mail. Voice mail includes a text preview of the recorded message, automatically transcribed using Microsoft”s voice-to-text engine.”

So Exchange 2010 will sharpen up the Unified Messaging side of things in Outlook. Nice.

If you want to try out the beta, download it here: Microsoft Exchange Server 2010 Beta

Facebooktwitterlinkedinmail