When performing migrations between different systems, there’s always the case where the tools available don’t do the job out of the box – and although IMAP migration tools for Exchange and Outlook Live can be great for moving mail, there isn’t a decent free solution for importing contacts.

For a recent migration from a Unix system (Dovecot + SquirrelMail) to Outlook Live, I came across this very scenario. While Microsoft provide IMAP migration tools to move mail to Outlook Live (which I was lucky enough to beta test before it was widely available), no tools are provided to move other data such as contacts and calendars.

While this isn’t the actual code I used (I wrote my original code in C#), I’ve re-visited what I’ve done and listened to what others say they need. What I’ve heard is it would be useful to have some Powershell code that out-of-the box can import contacts into any Exchange mailbox. The reason that Powershell is the right language for code like this is that it’s fairly easy for the enterprising administrator to modify to their needs.

Getting started

Before you can run this script, there are a few things you need to set up first. Don’t worry though! It’s nothing too onerous – all is needed to get going is two things:

1. Setup of EWS  impersonation, unless you only want to work with accounts you know the username/password for.
2. Installing the Managed API DLL onto your computer.

Setup of Exchange Web Services Impersonation
Exchange Web Services is the programmatic interface to each user’s Exchange mailbox. Most actions that can be performed in Outlook can be performed via EWS – so much so, in fact, that Apple’s Mail.app in Snow Leopard and the latest update for Entourage 2008 use EWS as the backend for the mail clients themselves.

If you’re planning on doing a mass-import of contacts, or don’t know the user’s password you’re importing, then setup of EWS impersonation is the step you need to take to allow a trusted account to switch to the user you want to import.

In Exchange 2010, setup of Exchange impersonation is managed via RBAC. Full details of how to setup impersonal are on the Microsoft site, but if you just want to get it setup for a single admin/service account, org-wide, use the following command substituing serviceaccount for your service account:

On Exchange 2007, it’s very different, and is managed by AD permissions on individual Client Access Servers. Again – full details on the Microsoft site, but to add the permission to all CAS servers, the following code will suffice, again substituting serviceaccount for your Service account:

Installing the Exchange Web Services Managed API
Next, whatever environment you are in, you need a copy of the DLL file that provides the bits and pieces that make this all work. The easiest way to get up and running is to download the API (choosing the right version for your platform), and install it to it’s default location.

Download the EWS Managed API from the Microsoft site

Once downloaded and installed, you should be good to go with script.

Using the script Import-MailboxContacts.ps1

So, you’ve got impersonation setup if needed, got the EWS DLL on your machine. You should be good to go!

For each mailbox you want to import contacts from you need a separate CSV file. The format of the file is intentionally the same as Outlook will export in, mainly because a lot of apps already export in the format (Gmail does, for example) so you should find it easy to get test data, but if you haven’t I’ve included a sample file to get you started.

Along with the data, you also need, at a minimum, the mailbox email address to import to. This is used when impersonating, and for Autodiscover. If you’re not logged on as the user you want to use for the import, you can specify a username and password. Additionally, there’s a variety of options to specify the EWS Url manually, switching to the Exchange 2007 version of the API etc.

Examples

The first example is a straightforward import into the current logged-on user’s mailbox. We’re specifying the Email Address and the URL to EWS (to bypass Autodiscover):

As you can see in the above example – it’s all fairly straightforward. You’ll also see the output shows the contacts that have been created – you can use standard Powershell pipeling to export this data, pipe it to another command or filter it.

The second example is slightly more complicated, and reflects the main use case. We’re connecting to a remote exchange organisation, using Autodiscover to find the EWS address, enabling impersonation and providing credentials at the command line:

In addition to the options above, you can also specify the parameters -Exchange2007 $true and use -EWSManagedApiDLLFilePath to specify a different path the the EWS DLL.

Powershell Code

Finally, you’ll need a copy of the code to do all this. At the bottom of the post you’ll find a ZIP file containing the Import-MailboxContacts.ps1 file and a sample CSV file, and below you’ll see the code itself. Happy importing!

Download as ZIP

In Exchange 2007 SP1 thru to Exchange 2010 RTM, the Export-Mailbox command was the replacement for the once-familiar ExMerge utility when it came to exporting mailboxes to PST files.

The main problem with Export-Mailbox for most Exchange administrators is the requirement for Outlook – either on a 32-bit machine with Management Tools for Exchange 2007, or on a 64-bit machine for Exchange 2010. All in all, it wasn’t ideal and certainly didn’t facilitate scripted mailbox exports.

Thankfully, with Exchange 2010 SP1, Export-Mailbox is going the way of the dodo and new cmdlets for Mailbox imports and exports are available. Just like the New-MoveRequest cmdlet, the new import/export command use the Mailbox Replication Service to perform the move via one of the Client Access Servers giving performance benefits, such as ensuring the PST transfer doesn’t have to go via the machine with the Exchange Management Tools/Outlook installed, as was the case previously.

The main aim of this post is to give you an overview of how to use the new mailbox export cmdlets, and then show you how to put them to practical use, both at the command line and with a scheduled task for brick-level backups.

Getting it set up

The basic requirements for using the new feature are pretty straightforward. You need to use an account that’s a member of the organisational management groups, and have the “Mailbox Import Export” role assignment assigned to you or a role group you’re a member of. As the export is done at a CAS server (and if you’ve multiple CAS servers you can’t specify which one in each site will be used) you can’t specify a local drive letter and path – you must specify a UNC path to a network share that the “Exchange Trusted Subsystem” group has read/write access to.

Step One

Create a share on a server, and grant Exchange Trusted Subsystem read/write permission. In this example I’m using a share called Exports on a test server called Azua in my lab environment:

Step Two

Next, you’ll need to grant a user, or group, the Mailbox Import Export role assignment. You can do this using the Exchange Management shell with a single command. In this example, I’m granting my lab domain’s Administrator user the role assignment:

After you’ve done this, close and re-open the Exchange Management shell, and you’re ready to go!

Exporting a Mailbox

At it’s simplest, use the New-MailboxExportRequest command with the –Mailbox parameter, to specify the mailbox to export along with the –FilePath parameter, to specify the PST file to create and export data to, e.g:

In addition, there are some other useful options – such as –BatchName, which allows grouping of requests together, and –ContentFilter, which allows only certain content to be exported to the PST – useful for discovery purposes.  As usual, use the Get-Help New-MailboxExportRequest –detailed command to review the full plethora of options.

After submission of your requests, you can check progress, including the percentage complete, with the two Get-MailboxExportRequest and the Get-MailboxExportRequestStatistics commands. Pipe the former into the latter to get a listing:

After the requests complete, you can remove the requests in a similar fashion, using the Remove-MailboxExportRequest command:

Performing mass exports

One benefit of Powershell is it’s very easy to put together commands enabling mass-exports of PST data with only a few commands. If you really wanted to, you could even use a Powershell script as a secondary brick-level backup!

The Basics

So to check out how to do this, let’s look at it’s simplest – backing up all the mailboxes (assuming it’s a full Exchange 2010 environment) to a single share:

In the above example, we’re simply performing a for-each loop through each mailbox and creating a new Mailbox Export Request, using the alias to build the name for the PST.

But – what if we’re in a mixed environment, and only want to target the Exchange 2010 mailboxes?

In this example above, now, we’ve added a clause to only select the mailboxes where the Exchange Major Build is 14 – Exchange 2010. Simple!

Moving on from such wide-targeting, you may want to target just a pre-defined list, using a CSV file. To do this, simply create a CSV file with the column “Alias”, and list the Mailbox alias fields you wish to export. Then, using the Import-CSV command we can use this CSV file to create the requests:

Performing Mass Exports as a scheduled task

Now you’ve seen the basics of how easy it is to perform mass mailbox exports using the New-MailboxExportRequest command, I’ll finish off with a final example showing how to use this mass export feature as part of a scheduled task.

This script is aimed at backing up all the mailboxes on a single database, or a single server. After creating the requests, it waits for the requests to complete then, if you’ve specified a report directory, it will write reports showing completed and incomplete (i.e. failed!) requests. Finally it removes the requests it created.

To use the script, you need to alter the config section and specify either a server or a database, a share to export to, a share to write a report to after the process has completed and you can choose whether to remove each mailbox’s associated PST file or leave as-is at each export – merging the contents.

You’ll see the content of the script below and at the bottom of the post I’ve zipped it up along with a bootstrap CMD file you could use when setting up a schedule task. As always – use at your own risk and test out in your lab environment first. Happy Exporting!

Command file contents:

Download as ZIP

In my earlier post about the Outlook Web App improvements in SP1 you’d have seen than in Exchange 2010 SP1, themes are making a welcome return.

If you don’t have the resources and time to install the SP1 beta yourself, or just want a quick look at all the new themes that will be included in the upcoming service pack, this quick post is for you!

Default

Mixxer

Botanical

One World

Super Sparkle Happy

It Came From Space

Autumn Blade

Herding Cats

Finger Paints

Damask

Arctic

Cupcake

Blibbet

Gothitech

Winterland

Pink

Blue

Green

Voilet

Grey

With the release to the public of Exchange 2010 SP1 Beta, it's nice to see the everyone getting their hands dirty with it at long last. Here's a quick post with a few links I've seen and liked over the last few days.

Installing Exchange 2010 SP1 Beta (Mike Crowley's Whiteboard)

RBAC Database Scopes in Exchange Server 2010 SP1 Beta (Mike Pfeiffer's Blog)

Installing Exchange 2010 Pre-requisites Made Part Of The SP1 Beta Setup Process… (How Exchange Works)

Archive Mailbox Improvements In Exchange 2010 SP1 Beta… (How Exchange Works)

And of course there's a few more older articles linked at the Technet Wiki

One of the new features available in Exchange 2010 SP1 beta that I’m excited about (and already making use of) is the ability to share calendars from Exchange either in iCalendar or HTML format.

So – why is this useful? Doesn’t Exchange 2010 already have improved Calendar sharing with the new federated sharing features available from RTM? Well, yes it does.. And this new features doesn’t replace federated sharing, however if you want to share calendars now is that the world doesn’t run Exchange 2010. Some organisations will move to it over the next year or two; but lets face facts – some enterprises out there may move to Google Apps, Zimbra or something else, so Federated Sharing isn’t going to be an option. While a workaround might be to create partner mailboxes or use third party software, it would be nice to have a solution that “just works” and enables the business to collaborate with partners easily without worrying too much about what technology each other uses. Only with open standards can this happen and with SP1 that’s now a reality.

The ability to publish calendars with anonymous viewers (and that’s an important point, which I’ll come back to) means that should the admin enable it, the user can now go in via OWA, select the calendar they wish to share and choose to publish it. They then receive a set of URLs that they can share via email. The recipient then can simply refer to the calendar via a web browser, or by using any iCalendar compliant software or web app they can subscribe to the shared Calendar.

Getting back to the anonymous part, there are two options. The end user can publish a calendar with a “public” URL that is searchable. The other option is a “restricted” URL with an obfuscated URL. Additionally, the user can restrict what will be shown for each calendar they choose to publish. On top of this, the admin can restrict via sharing policies the maximum amount of information users can publish, and sharing policies can be tied to a certain set of users. So there is some risk in enabling the facility, but by default no user’s calendars are shared, and there are a number of controls available to user and admin to pull the feature in line with the business and individual user’s requirements.

Now you know a little more about the new feature, let’s take a look at how it comes together from a user perspective, and how it’s configured by the admin.

The User Experience

If a feature is going to work well it has to be easy for a user to find and configure. Exchange 2010 SP1 doesn’t disappoint as the feature is listed in both OWA and Outlook in the same place as other calendar sharing options.

For an OWA user, they select the calendar they want to share, then choose “Share”, and the option is listed as “Publish This Calendar…”

If they’re using Outlook 2010 (beta ), the user right clicks the calendar they want to share, chooses “Share” and again, it’s listed as “Publish This Calendar…”

After clicking “Publish This Calendar…” via OWA or Outlook, the options can be chosen including the detail to show, the date range and the type of access:

After clicking “Start Publishing”, the links are generated:

The user can now either copy the links from this page, or via “Share” choose “Send Links to This Calendar…” which opens a new email with the two URLs attached.

Opening the calendar by the recipient is easy enough. For our first example, let’s have a look at Exchange’s primary competitor, Google Apps. To add the shared calendar to Google Calendar, the end user chooses “Add” then “Add by URL”.

They pop in the iCalendar URL, and it shows up in the recipients Google Calendar. You’ll see below I’m subscribing to two Exchange 2010 SP1 calendars – my personal one and my team’s:

(In my case – this is one aspect I personally like about the feature. Although I don’t use Google Calendar I do use iGoogle and it allows me to see my Exchange calendars on my homepage via the Google Calendar widget.)

Next up it’s Zimba. Add a new Calendar, choose Synchronise appointments from remote calendar, then pop in the Exchange iCalendar URL:

Again, the Calendars show perfectly:

Finally let’s not forget Outlook users; from Outlook 2007 onwards iCalendar subscriptions are supported. I’ve quickly tried this in Outlook 2010 beta – simple right click in the calendar list, choose “Add Calendar” and then select “From Internet…”

As above, after popping the iCalendar URLs in the subscriptions are created in the local Outlook client.

And, finally let’s not forget HTML sharing, which does exactly what you’d expect:

The Admin Experience

Now you’ve seen the user experience let’s take a look at what needs to be done to get it up and running in your SP1 environment. To get it all enabled we need to do the following:

• Set an ExternalURL for your organisation’s Client Access Server
• Enable Calendar Publishing on the OWA Virtual Directory
• Create or modify the sharing policy to allow anonymous sharing

Setup of the ExternalURL is pretty standard stuff so I won’t cover it here. Moving on to the Calendar Publishing OWA virtual directory feature, let’s look at what it’s made up of.

The Calendar Publishing works via a new virtual directory – “calendar”. This lives beneath the “owa” virtual directory as “/owa/calendar” and has anonymous, http access enabled (watch out ISA/TMG users). It’s enabled by default but should it need re-enabling it’s pretty straightforward using Powershell. Here’s a quick example:

Set-OWAVirtualDirectory "owa (Default Web Site)" –CalendarPublishingEnabled:$true

Next up, a sharing policy needs to be configured to allow anonymous access. You can do this via EMS or via the EMC. The EMS example below changes the Default Sharing Policy to only allow anonymous access with maximum access level of Calendar Sharing with Free/Busy plus Subject, Location and Body.

Set-SharingPolicy -Identity "Default Sharing Policy" -Domains "Anonymous:CalendarSharingFreeBusyReviewer"

Via the EMC is also pretty straightforward and particularly suitable when you need to create multiple policies or modify existing ones. Here’s a quick run through of how to create a new policy via EMC that only applies to certain users:

Open EMC and navigate to the Organizational Configuration node, then to Mailbox and select the Sharing Policies tab:

First, examine the sharing policies already present. In the above screenshot, I’ve got a single sharing policy which is disabled. As we’re adding a new policy right-click in the white space or click “New Sharing Policy…” on the actions pane. Give the policy a name and add a new “domain” called “Anonymous” and select an appropriate maximum level of access:

After you’ve added the “domain” anonymous to the policy, make sure it’s enabled, then press Next. On the next page you’ll be presented with the opportunity to add mailboxes now. You can of course add these later either via the EMC or via EMS:

Press Next, then after confirming the details, press New. After completion you’ll see a warning that lets you know calendar publishing is enabled for this policy:

Press Finish and we’re all done. You should now be able to login to the specific mailbox and following the first part of the article share the Calendar.

Conclusion

We’ve had a look at what the new feature brings both from an end-user experience and to an administrator. As we can seen it’s great for sharing calendars in an environment where open standards are important or where partners use different products. I’d like to see full WebDAV compatibility so a Linux user can plug straight in and go, but this is a great start as far as sharing is concerned.

Getting back to new shared calendar features in SP1 - I’m hoping more can be revealed over the next few weeks as there’s still a bit more in store! And of course, you’ll be able to get your hands on this yourself early June.

A final thought – bear in mind all the features and steps described here are not necessarily final so don’t be surprised if things change over the next few months.

Steve

If you don’t already know, the first public beta of Exchange 2010 SP1 is now up for download. Although it must not be installed into production environments it’s defiantly worth a look due to some of the improvements brought to the table:

• Better setup experience including integrated pre-req installer and setup resumes where you let off after a reboot
• Improvements to the Exchange Management Console when managing DAGs
• Improvements to public folder management
• Import and Export of PST files without Outlook installed on the server
• Calendar sharing improvements including iCal sharing
• OWA themes and another OWA overhaul

More links to articles are available over on the Technet Wiki and SP1 beta’s available for download here.

Over on the Outlook Live forums today we discovered a very strange issue with Outlook 2010’s account setup preventing Exchange autodiscover from working for some domains. If your domain starts with “live.” then the Autodiscover and Guessmart processes don’t even kick in. You get prompted straight away to install the Hotmail Connector:

As you can see in the above example the domain doesn’t even exist. A NetMon trace shows no attempt to check the domain to somehow link it to Hotmail, and if you use the Test E-Mail Auto configuration utility it follows the “real” logic and doesn’t alert you to this problem.

Any information on exactly why this does this isn’t already out there – the closest I’ve come to an answer is over on the Outlook blog, here. If you know more – feel free to leave a comment. In the meantime I’ll be doing some more research.

Update 1 27/05/2010 – I have a solution from Microsoft for the issue. Just waiting for confirmation before I post.

Update 2 01/06/2010 - Workaround below:

NB: The following instructions are for use at your own risk. If you aren't sure what you are doing, get a professional to assist and always ensure you have an up-to-date backup that you know how to restore.

Open Registry Editor and navigate to:
HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\AutoConfigDomains
Remove the following key:
live.*

This will of course make it so name@live.com will not autoconfigure with the Hotmail Connector.

If you want that that to still work change the Key name to HKLM\Software\Microsoft\Office\Outlook\AutoConfigDomains\live.com

Today Microsoft made public some of the new features in Exchange 2010 SP1 over on the Exchange Team blog. There’s a multitude of new features available and I encourage you to take a look. I’ll be publishing a few posts over the coming days on features I’m most interested in but to start off, I’m looking at the massive improvements to Outlook Web App.

One of the biggest improvements in Exchange 2010 was the cross-browser OWA compatibility and cleaner interface. In the past, this would have been it until Exchange 15 came out, giving the competition (i.e. Google) a few years to catch up and leapfrog Microsoft. Today Microsoft made it clear that no longer will they allow the competition to out-innovate them against Exchange, and they will continue to deliver benefits to customers in between major releases.

What’s new in the premium interface?

Basically – nearly everything! Although from quick glance you might mistake the SP1 OWA for RTM, it won’t take long to realise it’s had an overhaul. The simpler UI is cleaner and well.. feels more like a modern web app than previous versions which have tried hard to mimic a desktop app. It’s less cluttered, easier to navigate and looks a lot more sexy

Enough anyway with the talk. Let’s get down to business and have a look.

Outlook Web App, Exchange 2010 RTM

Outlook Web App, Exchange 2010 SP1

As you’ll see the interface is a whole lot cleaner. There’s a breadcrumb navigation trail in the top left, just below the OWA logo to help you find where you are at a glance. The Exchange icon has gone - It’s just a simple tree menu. The structured lines separating the elements fade away and blend into the background. The icons have been refreshed and only what’s needed is present. If you look very closely you’ll even see that you can use checkboxes to select email. You don’t need to ctrl-click anymore, unless of course you want to!

The interface overhaul isn’t all that’s new. Also announced today were the following new features for OWA SP1 – A new set of themes, sharing calendars to the web and allowing the reading pane to be shown across the bottom.

Themes

Themes were an obvious omission from Exchange 2010 RTM, however in previous versions of OWA they have mainly been variations of the default theme but in different colours – apart from the Xbox and Zune themes – though I’m sure they weren’t overwhelmingly popular. I must say though, I am glad they didn’t rush these out. The new set of themes are absolutely amazing. I’m not going to reveal them all – that really would ruin the surprise but as a sneak preview here’s a couple of my favourite new themes and the new options button/themes picker:

New Options button and theme picker

Super Sparkle Happy theme

Blibbet (Check out the retro MSFT logo!)

Calendar sharing to the web

An often requested feature from my users has been the ability to share their calendar with non-exchange users.  And now it’s possible. Below you see Google Calendar opening an Exchange 2010 SP1 calendar. Also, note which interface fits better on a small window and looks more modern…

I’ll be following up Calendar sharing in more detail in my next post in a couple of days time – as it requires a little server configuration, and there’s more to show off.

Hope you’ve found this interesting. If there’s some more Exchange 2010 SP1 features made public over at the Exchange Team Blog that you’d like more information about let me know. If I can tell you, I will.

Steve

Just a quick note here – a big shout out to Chris Rue (@chrisrue on Twitter) over at Chris’ Funcave and a massive thank you!

I was lucky enough to win a Microsoft exam voucher from Chris as part of the Great Voucher Giveaway. I think I’ll be using mine to get a Hyper-V cert to go with my VMware certs. If nothing else that gives me a good excuse to get my team’s lab sorted out at work

And if you’d like to get in on some free voucher action – head over to Christopher Kusek’s blog (@cxi on Twitter) ASAP as he’s got an exam voucher giveaway going on right now.

Steve