Using the Exchange 2010 SP1 Mailbox Export features for Mass Exports to PST files
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!
# Steve Goodman. Use at your own risk!
###############
# Settings #
###############
# Pick ONE of the two below. If you choose both, it will use $Server.
$Server = "server"
$Database = ""
# Share to export mailboxes to. Needs R/W by Exchange Trusted Subsystem
# Must be a UNC path as this is run by the CAS MRS service.
$ExportShare = "\\server\share"
# After each run a report of the exports can be dropped into the directory specified below. (The user that runs this script needs access to this share)
# Must be a UNC path or the full path of a local directory.
$ReportShare = "\\server\share"
# Shall we remove the PST file, if it exists beforehand? (The user that runs this script needs access to the $ExportShare share)
# Valid values: $true or $false
$RemovePSTBeforeExport = $false
###############
# Code #
###############
if ($Server)
{
if (!(Get-ExchangeServer $Server -ErrorAction SilentlyContinue))
{
throw "Exchange Server $Server not found";
}
if (!(Get-MailboxDatabase -Server $Server -ErrorAction SilentlyContinue))
{
throw "Exchange Server $Server does not have mailbox databases";
}
$Mailboxes = Get-Mailbox -Server $Server -ResultSize Unlimited
} elseif ($Database) {
if (!(Get-MailboxDatabase $Database -ErrorAction SilentlyContinue))
{
throw "Mailbox database $Database not found"
}
$Mailboxes = Get-Mailbox -Database $Database
}
if (!$Mailboxes)
{
throw "No mailboxes found on $Server"
}
if (!$Mailboxes.Count)
{
throw "This script does not support a single mailbox export."
}
# Pre-checks done
# Make batch name
$date=Get-Date
$BatchName = "Export_$($date.Year)-$($date.Month)-$($date.Day)_$($date.Hour)-$($date.Minute)-$($date.Second)"
Write-Output "Queuing $($Mailboxes.Count) mailboxes as batch '$($BatchName)'"
# Queue all mailbox export requests
foreach ($Mailbox in $Mailboxes)
{
if ($RemovePSTBeforeExport -eq $true -and (Get-Item "$($ExportShare)\$($Mailbox.Alias).PST" -ErrorAction SilentlyContinue))
{
Remove-Item "$($ExportShare)\$($Mailbox.Alias).PST" -Confirm:$false
}
New-MailboxExportRequest -BatchName $BatchName -Mailbox $Mailbox.Alias -FilePath "$($ExportShare)\$($Mailbox.Alias).PST"
}
Write-Output "Waiting for batch to complete"
# Wait for mailbox export requests to complete
while ((Get-MailboxExportRequest -BatchName $BatchName | Where {$_.Status -eq "Queued" -or $_.Status -eq "InProgress"}))
{
sleep 60
}
# Write reports if required
if ($ReportShare)
{
Write-Output "Writing reports to $($ReportShare)"
$Completed = Get-MailboxExportRequest -BatchName $BatchName | Where {$_.Status -eq "Completed"} | Get-MailboxExportRequestStatistics | Format-List
if ($Completed)
{
$Completed | Out-File -FilePath "$($ReportShare)\$($BatchName)_Completed.txt"
}
$Incomplete = Get-MailboxExportRequest -BatchName $BatchName | Where {$_.Status -ne "Completed"} | Get-MailboxExportRequestStatistics | Format-List
if ($Incomplete)
{
$Incomplete | Out-File -FilePath "$($ReportShare)\$($BatchName)_Incomplete_Report.txt"
}
}
# Remove Requests
Write-Output "Removing requests created as part of batch '$($BatchName)'"
Get-MailboxExportRequest -BatchName $BatchName | Remove-MailboxExportRequest -Confirm:$false
Command file contents:
New OWA themes available in Exchange 2010 SP1
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
Exchange 2010 SP1 posts from around the web in June..
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
Managing iCal Calendar Sharing with Exchange 2010 SP1 [Updated]
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
Does your domain start with “live."? Expect problems with Outlook 2010! [Updated with workaround]
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
Writing Powershell scripts that target Exchange 2007 and 2010
If you’re planning a migration to Exchange 2010 that won’t be completed overnight, you may want to be able to run Exchange Powershell scripts that execute both Exchange 2007 and 2010 cmdlets from the same script. There’s a few reasons for doing this, including:
- If you use logic to determine where to place new user mailboxes, and some mailboxes will be on 2007 and some on 2010.
- If you create new mailboxes on Exchange 2007 and then add the new mailbox to a Exchange 2010 distribution group (for example, if you use moderated distribution groups).
- If you’re using Outlook Live (Live@EDU hosted Exchange 2010) and create MailUsers on-premise and Mailboxes in the hosted environment.
- You are using the Transporter suite to migrate mail and need to create mailboxes on a temporary Exchange 2007 server, migrate mail, and then move mailboxes to Exchange 2010.
OK – so my examples are mostly about provisioning and these are real-life examples of where I’ve used this method, but I’m sure you can think of other examples where it might be useful to you. So – what do you need?
- Exchange 2007 SP2 management tools on any OS that supports them.
- Powershell 2.0
- Remote Powershell enabled on the account you run the script as (using Set-User username –RemotePowerShellEnabled:$true)
You can use this on Windows Server 2003 R2, x86; no Exchange 2010 management tools are required. Enough of what you need – here’s what you need to put in your Powershell scripts to do Exchange 2007/2010:
# Add Exchange 2007. If you'll always run from the Exchange Management Shell, you don't need the next line.Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin# Exchange 2007 Commands Go Here - i.e.Get-MailboxDatabase# Unload Exchange 2007Remove-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin# Create Remote Powershell session with Exchange 2010 - edit the server name in ConnetionUri$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://exchange.contoso.com/powershell/ -Authentication KerberosImport-PSSession $Session# Exchange 2010 Commands Go Here - i.e.Get-MailboxDatabase# Unload Exchange 2010Remove-PSSession $Session
If you’re looking to connect to Outlook Live instead of Exchange 2010, simply replace the line beginning “$Session =” with a couple of lines similar to this:
$LiveCred = New-Object System.Management.Automation.PSCredential "yourliveadmin@contoso.edu", (ConvertTo-SecureString "password" -AsPlainText -Force)$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection -WarningAction SilentlyContinue
Hope this helps!
Steve
Scripted Shared Mailbox Creation on Exchange 2007/2010
I thought I’d share one of the scripts we use for automating creation of Shared Mailboxes within our organisation. One of the more laborious parts of creating shared mailboxes after creation of the actual Mailbox, is setting the manager, department, and granting a (possibly long) list of users permissions and send-as rights.
This script is a simple Powershell script that takes some of the pain out of the process. The assumption is that you want to achieve the following:
- Create a shared mailbox with a common alias, email address and username, checking input values before attempting to create the mailbox.
- You would like to specify the Department at creation and use the Department AD attribute to generate Address Lists
- You would like to attach a user as Manager for the Shared Mailbox so it is clear who manages it
You can use the script with Parameters – e.g:
.\New-SharedMailbox.ps1 -Department "Human Resources" -Alias hr_test -DisplayName "HR Test" -Manager managerusername -Usernames "username1,username2"
–Department is the text to use for the department attribute
–Alias is the Email Alias & Username
–DisplayName is the friendly textual name shown to users and recipients
–Manager is the username, UPN or email address of the Manager (who will have full access + send as rights along with being set as Manager)
–Usernames is a comma separated list of usernames of people who should also have full access and send-as rights.
Or - if that isn’t your thing, then you can just run the script without any options, and it will prompt you as you go along for the parameters. If you are using the Department attribute for Address List generation, you can hit enter when prompted for the department to get a list of in-use departments. As you go along values will be checked, to ensure the Alias and Display Name aren’t in use by Mailboxes or Mail Users and that the Manager and Usernames are attached to valid Mailboxes.
Before you get started with script it does need a little setup.
The setup is fairly straightforward, though. Open the script in a text editor, and change the values for $DomainController, $OU, $UPNDomain and $MailboxDatabase to values appropriate for your organisation. It goes without saying you should test this out on something not connected to your production environment. I won’t take any responsibility for any damage you do with this!
I’ve obviously taken some stuff out that is specific to our organisation (for example, we have a switch statement to determine the mailbox database and exchange server; and also generate Unix information) and if this almost does what you want let me know and I’ll be happy to help you customise it.
Download New-SharedMailbox.ps1
Enabling the Exchange 2010 ECP Performance Console
If you’ve been testing or even running Exchange 2010 in production, you will most certainly be aware of the Exchange Control Panel – which is now not only the user’s Options panel but provides access to a number of Administrative tools, such as basic user management and reporting/mailbox searches.
However one feature contained in the ECP but isn’t visible immediately is the ECP Performance Console.
The ECP Performance Console is ECP-specific in that it provides a whole wealth of information about how your Exchange Control Panel is performing – from how long client requests are taking, RPC latency down to what’s happening on the Powershell side. Although it is totally ECP specific the information can help you diagnose areas in which your client access server isn’t performing as it should and verifying improvements are working as they should.
The fields available in the ECP Performance console are as follows:
Request URL
Client Request Time (ms)
Server Request Time (ms)
RBAC Session
RBAC Session Latency (ms)
RPC Requests
RPC Latency (ms)
LDAP Requests
LDAP Latency (ms)
Serialization
Serialization Time (ms)
Runspace
Runspace Latency (ms)
Runspace Activations
Runspace Active Time (ms)
Windows PowerShell Invoke Count
Windows PowerShell Invoke Time (ms)
Cmdlets Instantiated
Cmdlet Time (ms)
Cmdlets Invoked
BeginProcessing Time (ms)
ProcessRecord Count
Process Record Time (ms)
EndProcessing Time (ms)
Authentication (ms)
Authorization (ms)
Resolve Cache (ms)
Map Request (ms)
Acquire State (ms)
Execute Handler (ms)
Release State (ms)
Update Cache (ms)
Log Request (ms)
Client Network Time (ms)
UI Response (ms)
To enable the ECP Performance Console, edit the ECP root directory’s web.config file on each Client Access server you wish to use this on. This is located at the following location:
C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\ecp\web.config
Look int he file for the following section:
<!-- Set ShowPerformanceConsole to "true" to show ECP's Perf Console: --><add key="ShowPerformanceConsole" value="false" />
Change the value for ShowPerformanceConsole to false to true as described in the preceding comment, and save the file.
Once you’ve made the change, run the customary iisreset /noforce to reset IIS then as normal login at your ECP URL (i.e. https://mail.contoso.com/ecp) and after login, click the drop-down to the right of the help icon:
You should see Performance Console now listed. Click it and voila – it should appear.
If you want to export the data - simply press the Copy button in the top left corner. The data can then be pasted into Excel.
Hope you find this useful, at some point!
Steve
Exchange 2010 MCITP: EMA now available – my comments
As of today, exam 70-663 is now available to take at your local Prometic test centre. After passing 70-662, TS: Exchange 2010, Configuring this is the only exam you need to pass to become MCITP on Exchange 2010.
As someone lucky enough to take and pass the beta exam (they cancelled a LOT of places - thankfully I booked mine for Dec 1st) I can say it's certainly no harder than the Exchange 2007 MCITP exams. If you have already passed those, although there is not a specific upgrade path you won't be too dissapointed as much of the same ground is covered apart from new features, like DAG, RBAC etc.
One area where I am disappointed with the MCITP in general is that they aren't hard enough. I'm not likely to win any friends by saying that, but personally I want to feel really satified after passing the exam. With exams like the VCP getting harder I think Microsoft should follow this example and make the MCITP something that is hard to achieve; there simply is too much of a gap between MCITP and MCM/MCA and too little of a difference in skill level between MCTS and MCITP.
Solving iPhone and Exchange 2010/2007 coexistence issues
During my testing of our Exchange 2010 implementation I came across a rather annoying issue - iPhones users with Exchange 2007 mailboxes no longer can connect after moving the client access across to 2010.
So - what is supposed to happen? Well - as iPhone is supposed to implement EAS protocol version 12.1 (i.e. it supports AutoDiscover), it should be redirected to the legacy Exchange 2007 Client Access array. Problem is, it doesn't work.
Of course not all ActiveSync clients support AutoDiscover and those that implement EAS protocol 12.0 or lower are automatically proxied by the Exchange 2010 Client Access array back to Exchange 2007 client access servers.
This is all explained in more detail (including an acknoledgement not all clients implement EAS protocol 12.1 correctly!) over at the Microsoft Exchange Team blog in their article, Upgrading Exchange ActiveSync to Exchange 2010.
Whilst looking for solutions, I've unfortunately only came across verification this is a known issue, with the solution to simply wait for Apple to fix the iPhone. However I have a deadline to meet and getting IT staff to visit hundreds of iPhone users to change EAS settings isn't an option, it's not an option to move all those mailboxes at the same time, and we can't wait for a fix from Apple.
The most simple solution, as it stands - is to force all ActiveSync clients to be proxied. As noted in the MS Exchange Team blog article above, all non-internet facing site mailbox ActiveSync access is proxied anyway, so it will work. And thankfully, the proxying isn't based on AD sites. It's simply based on the ExternalURL on the ActiveSync virtual directory - if it's set to $null on the Client Access servers in the site of the user's Mailbox it will proxy instead of redirect.
If you want to do this via the Exchange Management Shell - it's simple - do this for each Internet facing client access server during the switchover:
Get-ActiveSyncVirtualDirectory -Server E2007CA | Set-ActiveSyncVirtualDirectory -ExternalURL:$null
The implication of this is that there will be extra overhead associated with proxying Exchange 2007 ActiveSync users, so this would need to be factored into your plans should you implement my solution.
