Tag Archives: Exchange

It’s 2012–ditch the PST!

Where's my mail?This article on the Exchange Team blog introduces the PST Capture tool, that was designed to help you get rid of PST files. It’s an interesting read, since apparently lots of people are still using PST files for archiving and sorting email. It’s 2012 – ditch the PST!

I took a moment to reflect back to a time when I had to use PST-files. That was years ago. I feel old now. Perhaps my mailbox was capped to 500 MB and after careful optimization I was able to live my chained-to-email life just barely under the limit. The obvious solution was to create additional PST-files on your local drive and shuffle emails back and forth between different repositories when necessary.

Backups were always painful. Copying 10 PST files, each 2 GB in size, took ages. Or that’s how it seems when you are forced to reorganize email for artificial reasons. Thank you, 500 MB quota.

With the advent of practically unlimited email storage from Google (Gmail), Microsoft (Hotmail) and others, it’s amazing how many companies are still offering email services with subpar storage and archival options for their employees. Who, in a way, are kind of paying for those services in exchange for their time and skills.

Microsoft Exchange 2010 has supported personal archives for quite some time now. Even the TechNet article states the reason for personal archives: “[..] eliminating the need for personal store (.pst) files”. Sadly it’s a premium feature requiring an Exchange enterprise Client Access License (CAL). The alternative for this would be to employ unlimited archive from the cloud with Office 365 by using Exchange Online Archiving.

I, for one, feel that archiving and indexing old emails is worth the effort. I find myself performing advanced search queries against my pre-2000 era emails several times a month. Searching emails from Sent Items is a daily occurrence, and every too often the email I thought I sent just yesterday was actually sent 2 months ago. This is also a painful reminder on how reliant we seem to be on email. Especially for archiving purposes: stuff is sent over the wire and then forgotten – but I’ve got a copy in my archive.

So, really – ditch the PST. Give your people unlimited email archive, today. There’s no reason not to.

Moving from on-premises Exchange 2010 to cross-premises Exchange with Office 365 (Part 1)

Office 365 is finally out of beta and ready for primetime! The question we think is one of the more important ones is this:

How do we, as a company, move from 100% on-premises Exchange to a cross-premises (hybrid) Exchange setup with Office 365? Not necessarily “all-in” but rather through a pilot (over time) or a permanent hybrid setup without disrupting the status quo.

In this post we’ll explore the preliminary steps you need to take in order to smoothly transition Exchange services from a full on-premises deployment to a cross-premises model.

Note: Hybrid deployment requires an Office 365 Plan E – it does not work with the P (Professional) plan. See plans here.

Assess current infrastructure

Most IT organizations know fairly well what they have running in their networks at the moment. They are also painfully aware of the pain points. There might be legacy servers and services, homebrew workstations acting as servers and lost or forgotten file shares.

The assessment is not about fixing everything – it’s about realizing if you are even ready to move beyond on-premises. Assess first, fix what you can and move forward.

The Office 365 Deployment Readiness Tool is an assessment tool you can run on a Windows 7 workstation joined to your Active Directory domain. You need to run the tool once per AD forest.

During initial run, C:office365reskit –folder is were the results are saved.

image

The Deployment Readiness Tool tries to determine and extract the following information about your environment:

  • AD structure (forests, trusts, domains, schema etc)
  • Exchange setup (email domains, public folders, delegates etc)
  • Networks (gateways, IP configuration)

In addition several checks for prerequisites in case you are planning a hybrid/coexistence setup with Office 365:

  • Directory Synchronization (AD <> MS Online)
  • Single sign-on (SSO)
  • Lync Online, SharePoint Online and Exchange Online statistics

The generated report is somewhat conclusive. In our (single forest, small environment) infrastructure the following information was gathered:

  • Email domains: 21 (I know, we love UPN suffixes)
  • Primary email domains: 13 (what? who owns the other 12?)
  • Total number of users: 115 (a lot of service accounts)
  • Total number of groups: 71 (and we love groups!)
  • Estimated objects for AD synchronization: 187
  • No AD trusts
  • Forest schema level: Windows Server 2008 R2
  • Exchange schema level: Exchange Server 2010 SP1
  • Domain functionality: Windows Server 2003
  • Forest functionality: Windows Server 2003
  • Domain Controller functionality: Windows Server 2008 R2

The verdict based on these findings is good: Our domain and infrastructure is prepared for Exchange Rich Coexistence. Still a bit miffed about that domain functionality level though.

A lot of additional checks are also captured in the report. Here’s a few:

  • Estimate of computer operating systems ready for Office 365: 8
  • Current SIP domains: 1
  • Exchange servers: 1

In a nutshell this means we can deploy a hybrid environment, where we employ whatever services from Exchange Online (via Office 365) while we still retain our existing Exchange 2010. Why keep both? Several reasons spring to mind:

  • We can test upcoming service packs faster than Office 365 would probably roll them out
  • We still ‘own’ the mailboxes, even if we decide to move away Office 365 in the future
  • We can control and manage Outlook Web Access, if needed
  • We can decide how mail is routed – for example, by enforcing our custom rules for any outgoing email, even for mailboxes residing in the cloud

Design your model

Armed with this information you can now design your future Exchange deployment model with the Exchange Server Deployment Assistant:

image

You can choose between three models:

  1. On-Premises only
  2. Coexistence (On-Prem + Cloud)
  3. Cloud only

I’ll skip #1 (On-Premises only), since that’s what majority of companies already have. 

When you choose #2 (Coexistence), you can now design your model:

  • Current Exchange version: 2003, 2007 or 2010
    • For illustrative purposes I’ll select Exchange 2010
  • Next, several options to choose from:
    • Do you want the ability to use on-premises credentials everywhere?
    • Do you want a shared email address base (company.com for everyone, both on-prem and cloud)?
    • Do you want to route email from the cloud through your on-premises Exchange?
    • Do you want to share free/busy and calendars between on-prem and cloud?
    • Do you want to use a single URL for all email needs (OWA and Outlook Anywhere)?

If you answer yes to all, you’ll get a list of action points to complete:

image

In essence, this scenario and deployment model requires your organization to set up the following:

  • Active Directory Federation Services 2.0 (ADFS) for identity federation
  • Active Directory Federation Services 2.0 Proxy (ADFS Proxy) for added security
  • Directory Synchronization (DirSync)  for synchronizing AD user accounts to the cloud
  • Connect current Exchange 2010 management tools to Office 365
  • Additional items such as:
    • Outlook Web Access configuration
    • DNS changes
    • Mail flow

Also, verify that your current infrastructure can meet the prerequisites:

  • 1 or more ADFS servers
  • 1 or more ADFS proxy servers
  • 1 DirSync server (has to be 32-bit for now)
  • Exchange Coexistence requirements

For piloting purposes you can virtualize most, if not all of these services.

You are now ready to start building your pilot implementation for a rich coexistence scenario. More on that in part 2.