Accessing Exchange 2010 mailbox move history data

Posted on September 13, 2010 by Tony Redmond

By default, the Exchange 2010 Mailbox Replication Service (MRS) keeps the last two logs for moves performed on a mailbox.  Each log occupies approximately 300KB and, if desired, you can increase the number of logs that MRS keeps by editing its configuration file (MSExchangeMailboxReplication.exe.config), which is kept in the Exchange binaries folder on CAS servers. Like many of the Exchange configuration files, this is an XML document that you can edit with a text editor (NotePad is just fine).  The setting you want to change is MaxMoveHistoryLength, which can be set to any value between 0 (zero) and 100.

Editing the MRS configuration file to amend the number of mailbox logs that can be kept

Remember that Exchange 2010 CAS servers do not share MRS configuration details, so if you amend the configuration file, you have to make the same changes on all CAS servers if you want to have the same behavior on all servers.

The mailbox move logs are stored in a hidden folder in the user’s mailbox and can be retrieved using the Get-MailboxStatistics cmdlet to gain an insight into the work done by MRS to move a mailbox (and perhaps its personal archive) between servers. Two different reports can be extracted:

  1. The Move History, a summary report that describes the essential parameters for the mailbox move.
  2. The Move Report, a detailed report that contains a much more detailed view of the mailbox move.

The move history can be generated with this command. The important point is to specify the –IncludeMoveHistory parameter when we run Get-MailboxStatistics. As you can see, we pipe the output into a variable.

$MoveHistory = (Get-MailboxStatistics –Identity ‘Redmond, Tony’                            –IncludeMoveHistory).MoveHistory

The variable contains all of the move reports that are available for the mailbox in an array. The most recent report is available in the first element in the array, so we can extract it as follows and pipe the output through the Out-File cmdlet to Notepad.

$MoveHistory[0] | Out-file –FilePath ‘c:\Temp\MRS-History.Log’ | Notepad ‘c:\Temp\MRS-History.Log’

So good, so far. The information available in a move report is shown below.

Status                           : Completed
Flags                            : IntraOrg, Pull, MoveOnlyPrimaryMailbox
RequestStyle                     : IntraOrg
Direction                        : Pull
IsOffline                        : False
SourceDatabase                   : DB3
SourceVersion                    : Version 14.1 (Build 218.0)
SourceArchiveDatabase            :
SourceArchiveVersion             : Version 0.0 (Build 0.0)
TargetDatabase                   : DB1
TargetVersion                    : Version 14.1 (Build 218.0)
TargetArchiveDatabase            :
TargetArchiveVersion             : Version 0.0 (Build 0.0)
BadItemLimit                     : 0
BadItemsEncountered              : 0
QueuedTimestamp                  : 9/9/2010 4:13:59 PM
StartTimestamp                   : 9/9/2010 4:14:24 PM
InitialSeedingCompletedTimestamp : 9/9/2010 4:29:46 PM
FinalSyncTimestamp               : 9/9/2010 4:29:46 PM
CompletionTimestamp              : 9/9/2010 4:31:51 PM
OverallDuration                  : 00:17:45
TotalFinalizationDuration        : 00:02:04
TotalSuspendedDuration           :
TotalFailedDuration              :
TotalQueuedDuration              : 00:00:02
TotalInProgressDuration          : 00:17:42
TotalStalledDueToHADuration      : 00:00:30
TotalTransientFailureDuration    :
MRSServerName                    : ExServer2.contoso.com
TotalMailboxSize                 : 483.4 MB (506,878,889 bytes)
TotalMailboxItemCount            : 9194
TotalArchiveSize                 :
TotalArchiveItemCount            :

This report tells us that:

  • The move completed successfully
  • The move only involved the primary mailbox (in Exchange 2010, you can move the primary mailbox or its archive separately, or the two together)
  • The move was within an organization (IntraOrg) and it was between Exchange 2010 servers (Pull – when a move occurs between Exchange 2010 and legacy servers, the Store on the Exchange 2010 server has to push the content to the legacy server).
  • The source database is DB3, the target database is DB1.
  • The source and target servers both run Exchange 2010 SP1 (MRS identifies itself as build 218.0)
  • No corrupt (bad) items were encountered. This is good, because the tolerance limit for bad items was set to zero, so any corrupt item would have forced MRS to halt the move.
  • Only 25 seconds elapsed between the move request being queued and the time when the MRS running on exserver2.contoso.com started to process the move.
  • The initial seeding of the new mailbox on the target server took about 15 minutes for 9194 items occupying approximately 483MB. Your mileage will vary when you move data depending on server and network load.
  • After the initial seeding, the final incremental synchronization and clean-up took another two minutes. It’s at this time that Exchange switches the Active Directory pointers to relocate the user’s mailbox on the target server.
  • A small stall of 30 seconds took place due to high availability (HA) requirements. This only occurs when the target server is in a DAG and was probably due to a replication queue building on that server. The stall allows the server to clear the queue before it proceeds to finalize the mailbox move.

Overall, the history paints a picture of a mailbox move that proceeded smoothly and has completed without meeting any great problems. If we want to confirm this impression with a higher level of detail, we can replace the –IncludeMoveHistory parameter with –IncludeMoveReport. You can output the result to a text file using the same commands as shown above.

$MoveReport = (Get-MailboxStatistics –Identity ‘Redmond, Tony’                              –IncludeMoveReport).MoveHistory

The detailed move report begins with the same summary information that you see in the move summary. It then starts to list all of the actions taken to set up and then move the mailbox. An edited version follows:

Report : 9/9/2010 4:13:59 PM [ExServer1] 'contoso.com/Users/Administrator' created move request.
9/9/2010 4:14:01 PM [ExServer2] The Microsoft Exchange Mailbox Replication service '
ExServer2.contoso.com' (14.1.218.11 caps:07) is examining the request.
9/9/2010 4:14:01 PM [ExServer2] Connected to target mailbox 'Primary (2a0e48f1-ca39-
4efa-9ae6-23bb2fb917c8)', database 'DB1', Mailbox server 'EXSERVER1.contoso.com' Ver
sion 14.1 (Build 218.0).
9/9/2010 4:14:01 PM [ExServer2] Connected to source mailbox 'Primary (2a0e48f1-ca39-
4efa-9ae6-23bb2fb917c8)', database 'DB3', Mailbox server 'EXSERVER1.contoso.com' Ver
sion 14.1 (Build 218.0).
9/9/2010 4:14:02 PM [ExServer2] Request processing started.
9/9/2010 4:14:02 PM [ExServer2] Mailbox signature will not be preserved for mailbox
'Primary (2a0e48f1-ca39-4efa-9ae6-23bb2fb917c8)'. Outlook clients will need to resta
rt to access the moved mailbox.
9/9/2010 4:14:24 PM [ExServer2] Source Mailbox information before the move:
Regular Items: 883, 68.72 MB (72,062,206 bytes)
Regular Deleted Items: 8295, 414.7 MB (434,816,683 bytes)
FAI Items: 16, 0 B (0 bytes)
FAI Deleted Items: 0, 0 B (0 bytes)
9/9/2010 4:14:25 PM [ExServer2] Initializing folder hierarchy in mailbox 'Primary (2data
a0e48f1-ca39-4efa-9ae6-23bb2fb917c8)': 91 folders total.
9/9/2010 4:14:38 PM [ExServer2] Folder hierarchy initialized for mailbox 'Primary (2
a0e48f1-ca39-4efa-9ae6-23bb2fb917c8)': 91 folders total.
9/9/2010 4:14:38 PM [ExServer2] Stage: CreatingInitialSyncCheckpoint. Percent comple
te: 15.
9/9/2010 4:14:41 PM [ExServer2] Stage: LoadingMessages. Percent complete: 20.
9/9/2010 4:14:48 PM [ExServer2] Stage: CopyingMessages. Percent complete: 25.
9/9/2010 4:14:48 PM [ExServer2] Copy progress: 0/9195 messages, 0 B (0 bytes)/483.4
MB (506,878,755 bytes).

We can see these actions:

  • The move request is initiated
  • The MRS running on server exserver2.contoso.com picks up the request and begins to process it.
  • MRS connects to the source and target mailboxes on the respective servers. Note the build number that’s reported. In this case, we can see that it’s 218.0, which is the version reported by the MRS on an Exchange 2010 SP1 server. Other versions are reported with different information. For example, an Exchange 2003 server might show up like this:
    9/23/2010 9:15:17 PM [ExServer1] Connected to source mailbox 'Primary (4502f638-d741-4a39-9239-cf17454a8738)', database 'Ex2003\First Storage Group\Database1', Mailbox server 'Ex2003.contoso.com' Version 6.0 (Build 7654.0).
  • A warning is flagged that the mailbox signature cannot be preserved during the move, which means that Outlook clients have to reconnect after the new mailbox is set up. Microsoft hoped to introduce code to preserve mailbox signatures during mailbox moves in Exchange 2010 SP1 but this didn’t happen. I expect this code to appear in the future to eventually eliminate the need for Outlook clients to restart after mailbox moves. Non-MAPI clients will continue to have to reconfigure their settings to connect to the moved mailbox.
  • The contents of the source mailbox are enumerated. Regular items (items in user-visible folders), the dumpster (preserved on moves involving Exchange 2010 servers), and FAI (folder associated items – hidden items that hold data such as rules)  are noted for transfer.
  • The folder hierarchy is initialized in the new mailbox.
  • A checkpoint is created and then the Store starts to transfer information by pulling it from the source mailbox to build up the content in the new mailbox.

We then see a note to tell us that the move stalled because the target database (DB3) does not satisfy HA requirements because the DataMoveReplicationConstraint is not satisfied. This is a setting on mailbox databases that tells MRS how to proceed if the database is mounted in a DAG. The idea is to make sure that the replication activity provoked to process all the transaction logs generated by mailbox moves does not interfere with the normal operations of the DAG. The default (SecondCopy) is that at least one copy of the target database should be up to date before the mailbox move can proceed. If there is a backlog, Active Manager lets MRS know that it should stall for 30 seconds to see if the condition clears, which is what happens here. In this case, after 30 seconds, the stall lifts because the replication constraint is satisfied and the move can proceed. If the constraint is not satisfied within fifteen minutes, MRS will fail the move.

9/9/2010 4:15:57 PM [ExServer2] Move for mailbox '/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Redmond, Tony' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'DB1' (agent MailboxDatabaseReplication). Failure Reason: Database 1ec5194c-90b9-43d8-aae1-01a5374438f2 does not satisfy constraint SecondCopy. There are no available healthy database copies. Will wait until 9/9/2010 4:30:57 PM.
9/9/2010 4:16:27 PM [ExServer2] Request is no longer stalled and will continue.

After all the items originally enumerated are copied to the new mailbox, MRS performs a final incremental synchronization to copy any items that have been created in the mailbox since the move operation began.
9/9/2010 4:29:46 PM [ExServer2] Stage: IncrementalSync. Percent complete: 95.
9/9/2010 4:29:46 PM [ExServer2] Final sync has started.
9/9/2010 4:29:47 PM [ExServer2] Changes reported in source 'Primary (2a0e48f1-ca39-4
efa-9ae6-23bb2fb917c8)': 0 changed folders, 0 deleted folders, 0 changed messages.
9/9/2010 4:29:47 PM [ExServer2] Incremental Sync 'Primary (2a0e48f1-ca39-4efa-9ae6-2
3bb2fb917c8)' completed: 0 changed items.
9/9/2010 4:30:09 PM [ExServer2] Stage: FinalIncrementalSync. Percent complete: 95.
9/9/2010 4:30:09 PM [ExServer2] Waiting for mailbox changes to replicate.
9/9/2010 4:31:09 PM [ExServer2] Waiting for mailbox changes to replicate.

At this point, the mailbox attributes are updated in Active Directory to switch the mailbox over. The move history reports all of the Active Directory attributes for the mail-enabled account before and after the switch to validate that nothing has been changed. This is of less interest for intra-organization moves but it becomes a very useful source for debugging information when you move mailboxes between organizations and want to be sure that the new mail-enabled account accurately reflects the source data.

9/9/2010 4:31:50 PM [ExServer2] Mailbox was updated using domain controller 'ADRoot.
contoso.com'.
9/9/2010 4:31:50 PM [ExServer2] Mailbox data after finalization:
AcceptMessagesOnlyFrom:
AcceptMessagesOnlyFromDLMembers:
AcceptMessagesOnlyFromSendersOrMembers:
ActiveSyncAllowedDeviceIDs:
ActiveSyncBlockedDeviceIDs:
ActiveSyncEnabled: True
AddressBookFlags: 1
AddressListMembership: \Mailboxes(VLV); \All Mailboxes(VLV); \All Recipients(VLV); \
Default Global Address List; \All Users
AggregationSubscriptionCredential:
Alias: TRedmond

We’re on the down slope now and the new mailbox is established. MRS performs some final clean up and we’re good to go.

9/9/2010 4:31:51 PM [ExServer2] Move has completed and final clean up has started.
9/9/2010 4:31:51 PM [ExServer2] Target mailbox 'Primary (2a0e48f1-ca39-4efa-9ae6-23b
b2fb917c8)' was successfully reset after the move.
9/9/2010 4:31:51 PM [ExServer2] MBI cache of the target mailbox 'Primary (2a0e48f1-c
a39-4efa-9ae6-23bb2fb917c8)' database was successfully seeded after the move. If the
target mailbox was on an Exchange 2003 or Exchange 2007 Mailbox server, this operat
ion isn't supported and wasn't performed.
9/9/2010 4:31:51 PM [ExServer2] Source mailbox 'Primary (2a0e48f1-ca39-4efa-9ae6-23b
b2fb917c8)' was successfully cleaned up after the move.
9/9/2010 4:31:51 PM [ExServer2] Target mailbox information after the move:
Regular Items: 883, 68.72 MB (72,062,206 bytes)
Regular Deleted Items: 8295, 414.7 MB (434,816,683 bytes)
FAI Items: 16, 0 B (0 bytes)
FAI Deleted Items: 0, 0 B (0 bytes)
9/9/2010 4:31:51 PM [ExServer2] Request is complete.

Details are also captured if MRS encounters problems during the move. For example, here’s an edited extract from a move report with an error that indicates that a problem was met when MRS attempted to process some rule information from the mailbox (see the bolded information below). A number of sites have reported problems with rules when moving mailboxes from Exchange 2003 to Exchange 2010. Some administrators have fixed the problem by opening the problem mailbox with the MfcMapi utility and looking for suspect rules (for instance, a rule with a blank name). Another idea is to run Outlook against the problem mailbox with the /CleanRules switch to see if that cleans up the rules sufficiently to allow the move to proceed. Still another idea is a suggestion to have the user add another rule to force an update in the rules set in the mailbox to see if that cures the problem. If all fails, remember to spread magic dust in a circle and chant for a while in the hope that whatever is stopping the move simply goes away.

9/10/2010 11:29:14 PM [ExServer1] Fatal error MapiExceptionInvalidParameter has occurred.
Error details: MapiExceptionInvalidParameter: Unable to modify table. (hr=0x80070057, ec=-2147024809)
Diagnostic context:
Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=192]
Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=652][latency=0]
Lid: 23226 --- ROP Parse Start ---
Lid: 27962 ROP: ropModifyRules [65]
Lid: 17082 ROP Error: 0x80070057
Lid: 27745
Lid: 21921 StoreEc: 0x80070057
Lid: 27962 ROP: ropExtendedError [250]
Lid: 26849
Lid: 21817 ROP Failure: 0x80070057
Lid: 29150
Lid: 20446 StoreEc: 0x80070057
at Microsoft.Mapi.MapiExceptionHelper.ThrowIfError(String message, Int32 hresult, SafeExInterfaceHandle iUnknown, Exception innerException)
at Microsoft.Mapi.MapiModifyTable.ModifyTable(ModifyTableFlags flags, ICollection`1 rowList)
at Microsoft.Mapi.MapiFolder.AddRules(Rule[] rules)
at Microsoft.Mapi.MapiFolder.SetRules(Rule[] rules)

As you can see from this discussion, the detailed move history is sufficiently detailed to provide a real insight into the workings of Exchange 2010 move requests. One more small detail – the Exchange 2010 SP1 version of EMC allows you to view a move log as a move request progresses. Click on Move Requests in the Mailbox node and then select a mailbox that is being moved, then click on Properties and then the Log tab. The information presented here (see example below) is very similar to the detailed move report – the sole difference is that it doesn’t come from the user’s mailbox unless the move is complete. When a move is in progress, Exchange keeps the move report data in the system mailbox of the target database unless the move operates in push mode, in which case the data is kept in the system mailbox of the source database. When the move completes, MRS moves the data from the system mailbox into the user’s mailbox.

Viewing the move log from EMC

A final point about the completion percentage reported in move reports. The first 20% of the work done to move a mailbox is in the preparatory phase to create the new mailbox and enumerate the content in the source mailbox. The majority of the work is done between 20% and 95% as the content is moved from source to new mailbox. MRS reports progress as items are moved and increases the reported percentage from 20% onwards based on the amount of mailbox data moved from the source. Once all the source data that was originally enumerated has been moved MRS halts and reports 95% completion. A final incremental synchronization to move any changed content and to flip the mailbox settings in Active Directory is all that’s required to get us to 100%.

So there you are – lots of information about mailbox move requests! This is documented in my Microsoft Exchange Server 2010 Inside Out book. Very much “thoughts of an idle mind”!

Follow Tony @12Knocksinna

Posted in Exchange, Exchange 2010 | Tagged , , , , | 31 Comments

Extracting the Exchange 2010 version number for a server

Posted on September 10, 2010 by Tony Redmond

I was asked me the other day what the best method is to retrieve information about the build version for Exchange 2010 that’s installed on a server. There are two ways of approaching the problem. You can either fetch the information that’s stored on the server itself or you can interrogate the Active Directory to fetch the version information that’s stored for each server in the Microsoft Exchange container in the configuration naming context. Build information is updated by the Exchange Setup program each time it successfully runs on a server.

The first place to look is on the server itself. The Exchange Setup program updates the system registry with build information and I had this piece of PowerShell code floating around – I have no doubt that its genesis is somewhere in an email discussion – and thought that it would be good to share. The code to fetch the build information from the registry is as follows:

$RegExSetup = 'Software\\Microsoft\\ExchangeServer\\v14\\Setup'

$Server = (Get-Content env:ComputerName)

$Registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $Server)

$RegKey = $Registry.OpenSubKey($RegExSetup)

$V1 = "MsiBuildMajor"

$V2 = "MsiBuildMinor"

$BuildMajor = ($RegKey.GetValue($V1)) –as [String]

$BuildMinor = ($RegKey.GetValue($V2)) –as [String]

$ExVersion = $BuildMajor + “.” + $BuildMinor

Write-Host $Server “runs version” $ExVersion

Exchange 2010 server versions are reported in terms of a major build number and a minor build number. Exchange 2010 SP1 is major build 218 and minor build 15, so if you meet a server that reports a build number of 218.15, you know that it runs Exchange 2010 SP1.As proven in the screen shot, this code works. However, it’s probably not the most elegant code in the world, so feel free to improve it.

Interrogating the system registry to return Exchange server version data

Moving to how to extract Exchange server version data from Active Directory, you can run these commands to fetch and report the version number for a server. This is actually how Microsoft describe how to retrieve a server version in TechNet. The AdminDisplayVersion property is displayed with the Get-ExchangeServer cmdlet and in the About menu in EMC. However, you will see other versions reported elsewhere in the product. For example, the Mailbox Replication Service (MRS) faithfully reports that it runs version 218.0 in its mailbox move reports.

PS> Get-ExchangeServer -Identity ExServer1 | Format-Table Name, AdminDisplayVersion

Returning the version data for an Exchange 2010 server

To fetch build information for all servers in the organization, just omit the -Identity parameter and the name of the specific server as used in the example, which is what I do in the screen shot below. You can see that the build information is different to what’s reported from the registry in that Exchange tells you its “administrative display version” and then its major and minor build numbers. The administrative build in this instance is 14.1 for all servers, meaning that they are Exchange 2010 SP1 servers (Exchange 2010 is version 14). The difference between the reported major and minor builds is accounted for because two of the servers run the RTM version of SP1 while the other (an edge server that I haven’t gotten around to upgrading) runs an earlier build that Microsoft released during the SP1 development process.

Returning version data for all servers in the organization

I’ve also seen examples of code that use an LDAP lookup to fetch the same information:

PS> [ADSI]"LDAP://contoso.com/$(Get-ExchangeServer ExServer1| Select-Object -Expand dis*)" | Format-Table SerialNumber

Using LDAP to fetch the Exchange server version data from Active Directory

As you can see, the values reported for the serialNumber property of the server object include version 14.1, so that’s consistent, but the value of the build is 30218.15! I’m not suspicious (just paranoid), so I checked the property with ADSIEdit (below) and the same values are present. I guess that the Get-ExchangeServer cmdlet must trim the first two characters from the build number before it reports the data in AdminDisplayVersion.

Viewing server properties with ADSIEdit

All of this proves that the information is available and a range of solutions are available to extract it from a server or Active Directory – and that you can comfortably waste several hours poking around to discover information like this. Sometimes you will want to run code on a server and sometimes you’ll want to collate information from a range of servers, so it’s good to have the choice of approaches.

– Tony

More stuff like this can be found scattered throughout my Microsoft Exchange Server 2010 Inside Out book.

Posted in Exchange, Exchange 2010 | Tagged , | 2 Comments

Why bother with Outlook 2003?

Posted on September 8, 2010 by Tony Redmond

When Microsoft released Outlook 2003 in October 2003 (The history of Outlook is a good link to the history of Outlook), it marked several breakthroughs for Exchange clients. First, Outlook 2003 introduced RPC over HTTP and laid the foundation of the access enjoyed by many users enjoy as they connect Outlook using wireless and other networks across the Internet to their corporate network without having to use a VPN. We take this kind of access for granted these days, but it was a huge advance when it arrived, even if configuring RPC over HTTP required major incantations of mystical spells before it worked with Exchange 2003. Of course, Outlook Anywhere as it’s now called, works beautifully in Exchange 2007 and 2010 and administrators who never had the opportunity to work with Exchange 2003 probably don’t know what the fuss is about.

Cached Exchange mode was the second major advance introduced in Outlook 2003. Apart from the ability to synchronize folders for a complete mailbox down to local replicas held in the OST file, Outlook 2003 included a mass of network smarts such as drizzle mode synchronization, incremental synchronization, and intelligent threads to make sure that cached Exchange mode didn’t become a burden on networks.

The combination of cached Exchange mode and RPC over HTTP access create the foundation for the working habits of millions of users today. We don’t care about flaky network connections because we work with local data; we know that Outlook will connect in its own time and that it will get the mail through, even the large messages sent by our friends in marketing that contain the latest corporate PowerPoint 10MB template for us to marvel at.

So Outlook 2003 was an excellent client for Exchange 2003 – or even for Exchange 2007 when it was released. But technology and tide wait for no man (or software) and Outlook 2003 has been passed by to a point where it’s now an antique client that doesn’t know anything about the new server features that have been added in versions such as Exchange 2010, nor does it have the added smarts that Outlook 2007 SP1 introduced to reduce the connectivity load on Exchange or the ability that Outlook 2007 SP2 has to deal with large mailboxes. In fact, the Exchange development group has gone so far as to publish a blog post called Common Client Access Considerations for Outlook 2003 and Exchange 2010 that describes all of the problems that you get when you connect Outlook 2003 to Exchange 2010. Simple stuff at times, such as having to make sure that Outlook encrypts its connections to Exchange (not a default with Outlook 2003), but also more annoying things such as slower notification of newly arrived email due to the deprecation of UDP notifications in Exchange 2010.

Microsoft’s blog does not go on to explain that Outlook 2003 is further handicapped by its inability to access new features that are important to Exchange 2010 such as personal archives and retention tags. It also can’t use some of the cosmetic stuff such as MailTips. And while Microsoft has promised to release an update for Outlook 2007 to enable it to access personal archives, you can forget about a similar release for Outlook 2003 simply because this client is so old.

Yet I hear that many companies want to plunge into deployments of Exchange 2010 and continue to use Outlook 2003. I can understand the logic in wanting to upgrade the server infrastructure without incurring the cost of desktop upgrades and user training but I wonder whether this is short-term thinking that will only result in a pile of calls to the help desk as users scrabble to cope with the documented (but unknown to them) shortcomings. All in all, it seems to me that an upgrade to at least Outlook 2007 SP2 or, even better if the cost can be justified (because Exchange CALs no longer include Outlook), to Outlook 2010 so that all the new features – even the more esoteric and seldom used such as Outlook Protection Rules – can be considered to see whether they add value to users and the company as a whole.

Every company is different and every company has different pressures and requirements that will drive the decision… but I just wonder why anyone would seriously bother with Outlook 2003 if they’re considering a deployment of Exchange 2010.

These and other questions are the issues that we’ll grapple with at the Exchange 2010 maestro events next month (Training in Boston and Anaheim)

– Tony

More information about clients for Exchange 2010 can be found in my Microsoft Exchange Server 2010 Inside Out book!

Posted in Exchange, Exchange 2010, Outlook | Tagged , , , , | 4 Comments

SharePoint 2010 for Dummies – that must be for me!

Posted on September 6, 2010 by Tony Redmond

The redoubtable team of Kevin Laahs, Emer McKenna, and Veli-Matti Vanamo have gotten into the saddle once again to produce SharePoint 2010 All-in-One For Dummies (also available from Amazon.co.uk). The book is scheduled for publication on 4 November 2010 so treat this as advance notice together with some background.

SharePoint 2010 for Dummies

This eclectic combination of a Scotsman, known mostly for appearing at conferences in a kilt (he will do anything to get a high score from an audience), a wee Irish lassie (who confuses the children of Sacramento with her accent when she talks about cows and other animals), and a Finn (living in Ireland instead of enjoying the lakes, trees, and red-hot saunas in Finland, but we can’t all be perfect), first came together with Don Vickers to write a SharePoint 2001 book for Digital Press. Amazon.com says that the SharePoint 2001 book is still available, so those of you who need help with SharePoint 2001 can go and buy Microsoft SharePoint Portal Server: Building Knowledge Sharing Applications. Somehow I suspect that few will pick up this particular volume.

SharePoint 2001 was actually quite a product. Despite its undoubted limitations (scalability and management to name but two), it proved that it was possible to deploy department-level collaboration at a fraction of the price that many companies were then paying. I also believe that the appearance of SharePoint 2001 marked the death knell for public folders in Exchange. Public folders had never reached the potential promised when they appeared in Exchange 4.0 in 1996. Sure, they had a reasonably effective replication mechanism to get information close to readers (as long as administrators didn’t rehome the folders to servers located in interesting places scattered around the planet), but the user and management interfaces for public folders were really awful. Up to the time that SharePoint 2001 appeared, Microsoft had no answer for customers who wanted to move away from public folders, but then Microsoft dropped the ball in a very comprehensive manner by never providing integration and migration facilities to allow customers to share information between public folders and SharePoint and eventually to move all the data, including metadata and permissions, from public folders to SharePoint. The upshot is that public folders still persist today – or maybe linger in limbo as the great cockroaches of Exchange.

Leaving the ignored opportunity to transition from public folders aside, it’s fair to say Microsoft reset the whole content indexing and search market with SharePoint 2001 and one of the best initiatives I ever pushed inside Compaq (at the time) was the implementation of SharePoint as the collaboration infrastructure for the company. After the HP-Compaq merger, SharePoint made even more of an impact as it helped us to eliminate some very expensive UNIX-based document management systems at a time when HP was pretty focused on eliminating cost to justify the merger. Apart from being expensive, the UNIX-based system was pretty unusable in terms of finding information, unless you had taken a three-week course in how to categorize documents according to the prevailing wisdom of those who had designed and implemented the system. The relative simplicity of SharePoint provided a huge contrast!

Kevin, Emer, and Veli-Matti produced their second book to cover SharePoint 2003 “Microsoft SharePoint Technologies: Planning, Design, and Implementation” and then for SharePoint 2007 with Microsoft SharePoint 2007 Technologies: Planning, Design and Implementation. I suspected that this book would have been their last as a team, if only because Kevin told all and sundry that he would never write a book again. I’ve never written a book as part of a team and it must create a very interesting dynamic at times when you can blame someone else instead of yourself!

Like me, Kevin, Emer, and Veli-Matti were affected by the decision of Digital Press to exit the technology books market. I’m delighted that they were able to make a deal with the publishers of the “Dummies” series to do another book. I know that they have worked really hard to do the research on SharePoint 2010 and write the text. The team has faced challenges along the way as they sorted out who would write the different chapters and the writing has been tough, but the end result is good and that’s all that matters. Along the way, the publisher created some mirth to lighten the situation when Kevin was told that his sample chapter needed substantial rework because he wrote text that was “too British”. What a thing to say to a Scot, especially one who carries a small knife stuffed into his sock…

You may assume that a book labelled “Dummies” implies that it’s really an entry-level text that won’t provide much useful information to anyone who has worked with SharePoint before. That’s not true as the “Dummies” label has strayed far away from its original purpose of providing very accessible and easily understandable descriptions of technology to a point where some of their books contain in-depth technical information that you won’t find elsewhere. I think that this book is in the latter category and you won’t do badly if you buy it to gain some help with SharePoint 2010 and to understand how the technology can be used effectively to solve real-world problems. Recommended!

– Tony

Posted in SharePoint 2010, Technology | Tagged , | Leave a comment

Making client connection settings available to ECP

Posted on September 3, 2010 by Tony Redmond

The “Account Information” page of the Exchange Control Panel (ECP) contains a pointer to “Settings for POP, IMAP, and SMTP access…” The intention is to provide users with the information that they need to input into clients that use these protocols so that they can connect to Exchange. Users need to know the name of the client access server to which to connect, the port number for the protocol, and the encryption type security setting. These values are held in the ExternalConnectionSettings property of the CAS server and are set using the Set-POPSettings and Set-IMAPSettings cmdlets.

Unfortunately, if you leave the default settings in place, users will see blank values when they access the page. To provide the information, you have to take three steps:

  • Provide details for POP3 access:

Set-POPSettings –ExternalConnectionSettings ExServer2.contoso.com:995:SSL -Server ExServer2

  • Provide details for IMAP4 access:

Set-IMAPSettings –ExternalConnectionSettings ExServer2.contoso.com:993:SSL –Server ExServer2

  • Most companies provide a receive connector on a hub transport server that POP3 and IMAP4 clients can use to relay their outgoing messages. To make users aware of which server to use, you publish information about the connector by setting its AdvertiseClientSetting property to $True. In this case, I’m telling users to connect to the default receive connector on a hub transport server, but in production circumstances you’d be more likely to create a specific receive connector that is dedicated and configured to act as a client relay.

Set-ReceiveConnector –Identity ‘ExServer2\Default ExServer2’ –AdvertiseClientSettings $True

Remember that the POP3 and IMAP4 settings are server-specific, so you have to set the values on all the CAS servers that you want to use for this purpose.

A restart of IIS on the CAS server may be necessary to make the new values available to clients. Afterwards, users should be able to see values for connection settings as shown below:

How ECP displays connection protocol settings to users

Hope this helps to fill in one of the mysteries thrown up by Exchange 2010.

– Tony

Read more about the Exchange Control Panel and how to use it effectively in my Microsoft Exchange Server 2010 Inside Out book!

Posted in Exchange, Exchange 2010 | Tagged , , , , | Leave a comment

The remarkable disconnect between Exchange 2010 and Outlook 2007

Posted on September 1, 2010 by Tony Redmond

*** See note about December 2010 cumulative update for Office 2007 at the end of this post.

The recent release of Exchange 2010 SP1 is good news for the Exchange community because it improves the overall quality of the product and introduces some new features such as block-level replication within the DAG. However, a nagging doubt has increasingly troubled me in that the signs are there that a gap exists between the Exchange and Outlook development teams that should have been closed a long time ago. That gap is represented in the current lack of support for personal archives and retention tags in Outlook 2007.

Microsoft originally shipped Exchange 2010 in November 2009 (Microsoft press announcement for Exchange). Office 2010 then made an appearance in June 2010 (Office 2010 arrives). Outlook 2010 is the premier client for Exchange 2010 because it exposes so many of the new features such as the personal archive, retention and archive tags, MailTips, conversation views, and so on and it’s probably reasonable that Outlook would appear a little later than Exchange. Eight months of a gap seems a tad extreme, especially for customers who wanted to deploy Exchange 2010 early. The evidence to date is that only a reasonably small proportion of the market has deployed Exchange 2010 so far, maybe because they were waiting for Exchange 2010 SP1 to see all the features that should have been in the RTM version but needed some additional time to be fully baked, but also perhaps because they wanted a client that really worked with Exchange 2010. Outlook Web App is good (and it’s a lot better in SP1), but Outlook is the premier client and in particular it’s needed for corporate users who want to be able to work offline.

Deploying a new client when it is available is certainly an answer to the “how do I get to the new functionality” question and the deployment of the client software to all user machines can be factored into an overall plan. But then you run into the issue for many companies that managing a major new release of client software to tens of thousands of desktops is not something that they look forward to. A lot of work is involved to plan and execute the deployment; the help desk has to be ready for the inevitable flood of user queries about new features; user training has to happen (sometimes); and the new software may have potential impacts on add-on software that’s in use. This is why many companies avoid rushed deployments of new releases of Microsoft Office and instead plan the deployment as part of desktop or laptop refreshes, which typically now occur every three to four years.

I assume Microsoft wants customers to migrate to Exchange 2010 from Exchange 2003 (less so from Exchange 2007 at this point) reasonably quickly and I assume that they want customers to use major new features such as personal archives and the other compliance features, if only to stake out a claim to the market that is currently dominated by third-party archiving software such as Symantec Enterprise Vault (a product with a really interesting history going back to Digital Equipment’s ALL-IN-1 product). But Microsoft doesn’t seem to want to provide an upgrade to Outlook 2007 to allow customers who use this client to access the new features. I think it is reasonable to expect that Microsoft would do such a thing (on the other hand, expecting an upgrade for Outlook 2003 at this point would be simply unreasonable), especially as it seems to be in their best interest to do so, but despite rumblings from Redmond (the place, not the person), nothing has appeared so far.

Customers do genuinely wait for the first service pack of Microsoft server products to appear before they will consider deployment. Exchange 2010 SP1 adds weight to that argument with the array of new and finished features that it boasts plus the added time for the engineers to work on and bed in new technology such as the Database Availability Group. While you can certainly connect Outlook 2007 to Exchange 2010 and have a nice time sending email, it’s still a half-functional client when compared to what it could be and that is simply not good enough eight months after the original RTM release.

Don’t get me wrong. I like Exchange 2010 and I like Outlook 2010. I’m simply reflecting the frustration and bewilderment that I hear on a constant basis as to why Microsoft can’t coordinate releases of important client and server software in such a way that it reflects real-world production environments. Being able to deploy new software within Microsoft’s own IT shop is great and I am sure that Microsoft gains enormously from eating their own dogfood; the Exchange Technology Adaption Program is also very good and generates a rich vein of customer feedback (and is run by a group of very committed individuals who do their level best to serve customer needs). But there’s still something missing and the disconnect between Exchange 2010 and Outlook 2007 is regretted. At least, it is by this observer.

Come on Microsoft… it’s time to remove the proverbial digit and ship a version of Outlook 2007 that enables all the functionality that Exchange 2010 reveals to its MAPI clients!

– Tony

Read more about the choice of clients for Exchange 2010 in my Microsoft Exchange Server 2010 Inside Out book – available also at Amazon.co.uk and other online booksellers. The book is also available in a Kindle edition.

Update December 14, 2010: Microsoft has released the December 2010 cumulative update for Office 2007 (or the Outlook only hotfix). According to Microsoft, this update enables access to Exchange 2010 archive mailboxes from Outlook 2007 (including delegate access). Some restrictions still apply such as the inability to see archive policies, probably because of the need to add some new user interface that just couldn’t be done in an update. It’s still good to be able to access archive mailboxes from Outlook 2007 even if Outlook 2010 still delivers a much better user experience. Note that a report from fellow MVP Henrik Walther indicated that the required code is in the October 2010 cumulative release for Office 2007, which seems like an odd way to release such an eagerly-awaited feature…

Posted in Exchange, Exchange 2010 | Tagged , , , | 13 Comments

Auto-tagging in Exchange 2010

Posted on August 27, 2010 by Tony Redmond

Exchange 2010 includes the ability for administrators to define retention policies to control how long items are allowed to remain inside user mailboxes before Exchange will automatically take action to move or remove the items. A retention policy is composed of a set of retention tags that can apply to every item in a mailbox or just items in a specific folder. Each retention tag specifies a retention period in days and an action that Exchange will take when the retention period expires. For example, you could create a retention tag for Inbox items that cause Exchange to move items into the Deleted Items folder after 30 days. Once an administrator assigns a retention policy to a mailbox, the retention tags in the policy are placed on items by the Managed Folder Assistant, which runs nightly on Exchange mailbox servers. The Managed Folder Assistant then subsequently examines items on a nightly basis to discover items whose retention period has expired and then takes the defined action. All of this is a big change from the Managed Records Management (MRM) approach taken by Microsoft in Exchange 2007, which requires users to move items into managed folders before Exchange will manage them and that’s why Microsoft refers to the MRM built around retention policies and delivered in Exchange 2010 as MRM 2.0.

The ideas behind retention policies and tags are sound; the implementation in Exchange 2010 lacks completeness because of the need to define retention policies and tags through the Exchange Management Shell (EMS). This will be a concern for some administrators who prefer to work with objects through a GUI, especially when they’re dealing with concepts that they haven’t become accustomed to yet. Microsoft addresses this issue in Exchange 2010 SP1 where the Exchange Management Console (EMC) comes fully equipped with the necessary GUI to define, manage, and apply retention policies and tags.

This article focuses on auto-tagging, one of the more interesting and advanced techniques that Microsoft has incorporated into Exchange 2010. Auto-tagging is a concept introduced to assist administrators to implement retention tags by adding machine learning to automate the application of tags. Unfortunately auto-tagging is a feature that Microsoft has dropped from Exchange 2010 SP1. The reasons why are varied but include poor user and administrator awareness, lack of a GUI to guide people through the intricacies of setting auto-tagging up for a mailbox, and maybe a lack of completeness in terms of the feature itself – or possibly just some bugs. I think auto-tagging is a really good idea and hope that Microsoft will reintroduce it in a future service pack.

Learning how users tag items

The idea behind auto-tagging is simple. The user begins the process by manually applying retention tags to at least 500 items to form a collection of items called the training set. A smaller number is not sufficient to allow Exchange to build a good automatic tagging scheme that might match normal user behaviour. To tag an item, the user can either move the item into a folder that has a default tag or they can apply a specific tag to a specific item. For example, if the user receives regular progress reports for “Project Euro” and they apply the “Retain for five years” tag to these reports, Exchange will learn that any time a new item comes into the user’s Inbox for “Project Euro”, it’s a safe guess that “Retain for five years” is a good tag to apply.

Once they have tagged enough items to provide Exchange with a sufficiently diverse set to learn about their tagging behaviour, the user informs the administrator, who then then trains Exchange by pointing it to the set of tagged items. It would be nice if Outlook or Outlook Web App offered the user an option to train Exchange without administrator intervention but it’s the nature of new technology that some rough edges are inevitable and this is a rough edge for auto-tagging.

When the administrator launches the learning process, Exchange reviews the training set of items and learns from the content of the items and the tags that the user has applied to the items to construct a tagging scheme that it can apply automatically as new items arrive in the user’s inbox. The more tagged items Exchange can learn from, the better the automatic tagging scheme will be. The user can replace an auto-applied tag with another if a mistake is made or an administrator can clear all of the auto-applied tags in a mailbox and restart the learning process if the tags prove to be inappropriate, possibly because the set supplied to Exchange for it to learn about the user’s retention tagging pattern was incomplete or unrepresentative of the usual material that flows into their mailbox.

Steps to implement auto-tagging for a mailbox

To start the process of training Exchange, the administrator first enables a retention policy for the mailbox and then turns on auto-tagging for the mailbox. These commands first assign the “IT Department Retention Policy” retention policy to a mailbox and then enable auto-tagging:

Set-Mailbox –Identity JSmith –RetentionPolicy “IT Department Retention Policy”

Set-MailboxComplianceConfiguration –Identity JSmith –RetentionAutoTaggingEnabled $True

Once auto-tagging is enabled, Exchange accumulates details of items that the user applies retention tags manually until it has enough (at least 500) to begin the training process. The details of the items in the training set that Exchange uses to learn about user tagging behaviour includes information such as the message subject, the sender, and some key words from the text.

An administrator can check whether sufficient items have been tagged with the Get-MailboxComplianceConfiguration cmdlet. If enough items haven’t been added to the training set, Exchange will tell you how many more are needed before auto-tagging is possible. In this example, the required training count figure is 493 (the number reduces from 500), so the user still has a considerable way to go before auto-tagging is possible. Applying an archive tag does not reduce the required training count.

Get-MailboxComplianceConfiguration –Identity JSmith

Identity                    : ajr.com/Exchange Users/JSmith

RetentionAutoTaggingEnabled : True

RequiredTrainingCount       : 493

CorrectedMailCount          : 0

PredictedMailCount          : 0

ErrorRate                   : 0

After the training set is built, you can begin the training process. Exchange flags an error if insufficient tagged items are present in the mailbox. Be aware that Exchange also resets the required training count to 500 if you execute this command before sufficient items have been tagged, so you’ll have to begin to accumulate a new set of manually tagged items. However, let’s assume that we have done the right thing and tagged 500 items before we start the training process. Checking the mail compliance status now reveals:

Identity                    : ajr.com/Exchange Users/JSmith

RetentionAutoTaggingEnabled : True

RequiredTrainingCount       : 0

CorrectedMailCount          : 0

PredictedMailCount          : 0

ErrorRate                   : 0

As the required training count has now reached zero, we can start the training process:

Start-RetentionAutoTagLearning –Identity JSmith –Train

Once Exchange has been trained to auto-tag new items in a mailbox, the user can keep track of the effect of auto-tagging on by checking the tags placed on new items in the Inbox. It’s a good indication that things are progressing well if you select an item in the Inbox, find that a retention policy tag is present, and that it’s a tag that you would reasonably expect to place on the item. You can always adjust matters for the few items that don’t get a good automatic tag by applying a manual tag. On the other hand, if checking reveals that the training set of items used by Exchange to create its tagging scheme results in it applying inappropriate tags to new items that you simply can’t use, you will have to clear the set of automatic tags and begin the process again. Use this command to clear the set of automatic tags:

Set-RetentionAutoTagLearning –Identity JSmith –Clear

You then have to disable and re-enable auto-tagging for the mailbox to restart the process of accumulating a new training set of manually tagged items before you can retrain Exchange.

If you don’t want to check the tags on individual items, you can the Set-RetentionAutoTagLearning cmdlet to validate that Exchange is successfully applying auto-tagging for a mailbox. In this example we see that the “SuccessRate” is reported as 1, indicating that auto-tagging is proceeding normally. The other outputs indicate whether items that should be tagged are blank or have otherwise failed to be tagged for some reason.

Set-RetentionAutoTagLearning -Identity JSmith –CrossValidate –Segments 16

SuccessRate                             BlankRate                               FailureRate

-----------                             ---------                               -----------

1                                       0                                       0

The Segments parameter divides up a mailbox into different sections to learn from the tagged contents of each section. By default, Exchange divides a mailbox into ten segments. The minimum value is two while the maximum is 64. If the contents of a mailbox vary extensively, you may gain more accurate learning results by dividing a mailbox into additional segments. On the other hand, you can use a smaller number of segments if a mailbox contains items that are mostly similar.

No UI anywhere!

Unfortunately, there is no user interface for either administrators or users available in EMC or the Exchange Control Panel to enable auto-tagging, view details of the items used to determine how auto-tagging will happen, start or validate the collection process, conduct training, or review and tweak auto-tagging scheme afterwards. Everything has to be done through EMS. This is a pity as it will inevitably limit the impact of the functionality within the user community. After all, if they don’t know about a feature, they are hardly likely to use it unless they plumb the depths of TechNet or some other literature to discover that auto-tagging is possible. Hopefully, Microsoft will provide the necessary UI in the future.

In conclusion

Few users enjoy filing items into appropriate folders in their mailbox. Approximately the same number will enjoy applying retention tags. Auto-tagging therefore contributes to the effective use of retention tags by relieving users from a mundane task. Over time, and probably following several training exercises to develop an effective view of how a user would manually tag new items, auto-tagging has the potential to add some real value at low cost. Auto-tagging is interesting technology that may ease the introduction of retention policies in some quarters. Others will find its lack of GUI and documentation to be too high a barrier to warrant the investment of valuable administrator time. These cases are likely to be in the majority which means that auto-tagging will remain an exercise in computer science that needs to be revamped and made more user- and administrator-friendly. As we all know, Microsoft’s product development history demonstrates that they are very persistent when it comes to making features work right (eventually) so it will be interesting to see whether auto-tagging version 2.0 or even 3.0 is the one that succeeds or this will turn out to be an example of a bright idea that was ahead of its time and ends up on the great byte scrapheap.

Posted in Exchange, Exchange 2010 | Tagged , , , , | 4 Comments

The meaning of events 4113 and 4114 to Exchange 2010 SP1

Posted on August 27, 2010 by Tony Redmond

One of the lesser discussed updates included in Exchange 2010 SP1 is the addition of database redundancy monitoring by the Microsoft Exchange Replication service. This occurs for databases that are in a Database Availability Group (DAG) and is intended to ensure that each replicated database has sufficient healthy copies to make it redundant. In this context, sufficient means at least two copies and a healthy copy is one that is online and has no problems copying or replaying transaction logs.

Exchange 2010 SP1 contains a script called CheckDatabaseRedundancy.ps1 in the default \Scripts folder. You can run the script interactively to check a database and it is also possible to incorporate the script into Microsoft SCOM monitoring. See the Exchange 2010 SP1 CHM for details.

What’s interesting to me is that the same script is run hourly by the Microsoft Exchange Replication service to perform a redundancy health check for replicated databases . If Exchange finds that a replicated database doesn’t have sufficient healthy copies, the Microsoft Exchange Replication Service (MSExchangeRepl) logs event 4113 as shown below.

Event 4113 logged for a non-redundant database

In this instance I had a database (DB2) that had just been added to the DAG and no database copies apart from the active had yet been generated. The information captured in the event reports that only one copy exists, which is what I expected. The Replication Service will continue to check and log event 4113 for the database every twenty minutes until it goes into a state where sufficient redundancy exists to accommodate an outage and allow the failed copy of the database to failover to a healthy copy.

Event 4114 logged for a database deemed to be redundant

Event 4114 is logged for replicated databases that pass the redundancy health check. As you can see from the screen shot above, database DB2 has passed the health check because two healthy copies are available. If you scroll on down through the event details, you can see other information such as the replay and copy queue lengths for the copies.

Of course, you can debate the threshold that Microsoft has selected for database redundancy. In production environments, two copies is probably not sufficient to ensure the kind of redundancy that many companies demand, but it is enough to ensure that the DAG can cope with an outage that affects the disk that holds the database (or its transaction logs) or the server on which the database is mounted. As such, two copies is redundant enough for the purpose of illustration and initial deployment if not for long-term protection.

One interesting point is that Exchange 2010 uses the Windows 2008 Task Scheduler to run CheckDatabaseRedundancy.ps1 to check database copies. Exchange 2010 SP1 introduced a dependency on the Task Scheduler in that if this service is disabled on a server, you won’t be able to install the mailbox role. Not many people disable the Task Scheduler, so it’s not a problem that is encountered often but there are instances where overly-zealous Windows build engineers disable anything and everything before handing a server over to the Exchange deployment team who then see the problem illustrated below. The issue is obvious “The Task Scheduler Service is not running” but you might just wonder why this is a problem for Exchange. Now you know… To be fair to the Microsoft engineers, they know about this issue and are working out how to make it go away, probably by implementing the dependency check as part of adding a mailbox server to a DAG, which seems like the right place to test for a service that has to be running to validate database redundancy.

Whoops - Mailbox Role won't install because the Task Scheduler is disabled

In any case, the point is that enabling a redundancy check for database copies is a nice example of proactive monitoring that has found its way into Exchange 2010 SP1, something that may just make the life of administrators a little easier, especially as they tease out the complexities of DAGs under the stresses and strains of real-life production environments.

– Tony

Find out more interesting details about Exchange 2010 SP1 with a copy of my Microsoft Exchange Server 2010 Inside Out book and continue to learn more about the mysteries of the Exchange 2010 Information Store!

Posted in Exchange, Exchange 2010 | Tagged , , | 7 Comments

Exchange 2010 SP1 reaches RTM status

Posted on August 25, 2010 by Tony Redmond

Microsoft declared that Exchange 2010 SP1 had attained a sufficiently high standard of code and features to warrant release to manufacturing (RTM) on Monday, August 23. This decision was reached by the development team “war room” after the customers who participated in the Technology Adoption Program (TAP) provided their votes to say that SP1 was ready for the big time. This didn’t come as a huge surprise because the software has been very solid for the last few builds. Some late-breaking bugs did surface and caused minor impact on some features but certainly nothing to take the sheen off the overall value delivered in SP1. An interesting factoid is that the TAP sites had nearly half a million mailboxes deployed on SP1 before the final build was released, so there was no shortage of testing.

I’ve written about the new features in Exchange 2010 SP1 for Windows IT Pro magazine. You can find the article at Windows IT Pro. The available space and editing and production requirements of a magazine will always restrict what you can write so not everything is covered (I guess that’s why I have been writing a book about SP1), so this post provides some late breaking news that isn’t in the article. Further details are available at Microsoft’s own blog post announcing SP1 at EHLO, posted today. This post also includes information about how to download the SP1 software.  Or just go direct to http://www.microsoft.com/downloads/details.aspx?FamilyID=50b32685-4356-49cc-8b37-d9c9d4ea3f5b&displaylang=en. The release notes are available at http://technet.microsoft.com/en-us/library/ff728620(EXCHG.141).aspx.

This release is interesting because it is available in 13 server languages (including support for bi-directional languages – Arabic and Hebrew- for the first time), 55 client languages (the ones that you can select to use with OWA), and 26 languages for Unified Messaging.

The final build number is 218.15, which is what you get if you upgrade a server and then run this command:

Get-ExchangeServer | Select Name, AdminDisplayVersion

Checking version numbers for different servers

As you can see from the screen shot, my Edge server still runs an early build of SP1 (one that I have clearly not gotten to upgrade) while server ExServer1 has been upgraded to SP1 RTM and server ExServer2 lags a few builds behind. For the record, these servers have now been upgraded.

Those who are observant will notice that SP1 build numbers are lower than the RTM version (639.15). This is probably due to some internal Microsoft software build numbering rules that are impenetrable to normal human beings. A further inconsistency is seen in the fact that the version number reported by EMC (Help… About) is 218.13 rather than the proper minor build number. Such is life.

SP1 version reported by EMC

What’s far more important is that the upgrade is very easy and quick. You do have to upgrade the Active Directory schema to accommodate a host of new features such as mailbox auditing. Afterwards the VersionNumber reported for the Microsoft Exchange Systems Object (MESO) object will be 13214 and the value of the rangeUpper attribute of Ms-Exchange-Schema-Version-Pt in the schema is 14726.

After the schema is ready, you have to run Setup to upgrade your servers. You may have to apply a few hot fixes, but assuming that you have been keeping up to date with Windows Update, you’ll probably find that you have everything in place. For the record, the KBs that I have in my “SP1 pre-requisites” folder are:

The original matrix posted by the Exchange team on http://msexchangeteam.com/archive/2010/09/01/456094.aspx indicates that only four of these are required on Windows 2008 R2 servers. Microsoft subsequently updated this matrix to specify five patches for Windows 2008 R2 (the one that they added is 977020). All I can say is that various builds of the SP1 setup program complained about these patches and required me to install them, so I did. The one that is apparently not required for Windows 2008 R2 servers is 981002. Given the recommendation now available from the development group, I would start with the fixes on their list and only add others if Setup complains.

Update: Windows 2008 R2 SP1 includes the necessary hot fixes so you don’t have to mess around with these patches before you install Exchange 2010 SP1.

You’ll also have to update the Microsoft Office Filter pack on mailbox and hub transport servers to version 2.0. Remember to get the Adobe PDF IFilter and load it too if you want to include PDF documents in the content indexes. It’s best to install the Filter Pack on a server before you install Exchange as this will cause Exchange to register the Office filters for you as part of its installation. You can install the Filter Pack afterwards but in this case you’ll have to register the filters manually before Exchange can use them. See TechNet for more information.

Setup normally runs very smoothly. A number of people, including myself, noticed a small hiccup when performing a B2B (build to build upgrade) on mailbox servers that are members of a Database Availability Group (DAG). It may be that this only happens when the servers are multi-role; in my case they also host the CAS and hub transport runs. In any case, the symptom is that Setup aborts because a process called “PowerShell” is locking some files (see screen shot).

PowerShell causes a problem for the SP1 upgrade

This isn’t as big a problem as it seems. The underlying issue appears to be that something in the upgrade launches PowerShell to collect some data and the process lingers. The fix is to kill the offending process, which you can do with Task Manager:

Killing the offending PowerShell process

You can then run Setup again and all should go as expected to produce a nice new SP1 server:

Success! Exchange 2010 SP1 is upgraded on a multi-role server

Note that if you are running Exchange 2010 mailbox servers in a DAG, you should upgrade all servers to SP1 and not have some servers run RTM and some SP1. The reason is simple: a DAG member running the RTM software can move its databases to an SP1 server but the reverse is not possible. Therefore, you do not want to arrive in a situation where you need to activate databases on a server and cannot because the server has not been upgraded to SP1.

Apart from that caveat and the small installation hiccups that are sometimes seen, that’s all there is to it…

Update 1 September: Be aware of an issue that occurs when Microsoft TMG is used in conjunction with Forefront Protection for Exchange on an Exchange 2010 Edge server after SP1 is installed. It’s all to do with the fact that SP1 removes the Get-AntispamUpdates cmdlet, which then breaks the connections with the other products. See http://blogs.technet.com/b/isablog/archive/2010/09/01/problems-when-installing-exchange-2010-service-pack-1-on-a-tmg-configured-for-mail-protection.aspx for more information.

Update 2 – also 1 September: The Exchange engineering group has written a good blog on the issues that have been reported to them since SP1 was released. On the surface, it’s disappointing that such a list should be necessary given the huge effort that was put into testing SP1 over the last few months, but I think this reflects the diversity of environments that Exchange runs in and the massive challenge that any development group faces when they come to test new software. The old truth that an installed base is both a blessing and a hurdle to progress for any software product comes to mind. You can find the blog post at http://msexchangeteam.com/archive/2010/09/01/456094.aspx.

Update September 2: Fellow Exchange MVP Johan Delimon points out that you need to apply the OCS integration after the SP1 installation finishes.

Update October 7:  Microsoft has released the Roll-Up update #1 (RU1) for Exchange 2010 SP1. You now have the chance to apply two upgrades in short order to move from Exchange 2010…  According to Microsoft, the most important fixes included in RU1 are the following:

  • 2028967 Event ID 3022 is logged and you still cannot replicate a public folder from one Exchange Server 2010 server to another
  • 2251610 The email address of a user is updated unexpectedly after you run the Update-Recipient cmdlet on an Exchange Server 2010 server
  • 978292 An IMAP4 client cannot send an email message that has a large attachment in a mixed Exchange Server 2010 and Exchange Server 2003 environment

Update December 14, 2010: Microsoft has released Rollup Update 2 (RU2) for Exchange 2010 SP1. The big fixes are:

  • 2322161 Passive DAG Copy Doesn’t Replay Logs if “Don’t mount this database at startup” is Checked
  • 2431500 Cannot connect using Outlook Anywhere as the same user from multiple XP Clients
  • 2409597 Implement OpenFlags.AlternateServer for PublicLogon

According to Microsoft, RU3 for Exchange Server 2010 Service Pack 1 is currently scheduled for release in late February or early March 2011.

Update: Microsoft has released an updated version of the Exchange 2010 SP1 help file that you’ll want to download as it includes a number of fixes for the product documentation. You can download the updated help file from here.

Read more detail in my Microsoft Exchange Server 2010 Inside Out book, also available at Amazon.co.uk, other online stores, and at all good booksellers!

Posted in Exchange, Exchange 2010 | Tagged , , | 4 Comments

On Abbey Island

Posted on August 23, 2010 by Tony Redmond

Unlike the impression that many have of Irish people, I have never spent much time getting to know the Ring of Kerry. In fact, I’ve always regarded it as a route much beloved of tourists and therefore cluttered with tourist buses or – perhaps even worse – tourists driving hire cars slowly along narrow stone-walled roads that are probably a world apart from their normal expectations of what a well-engineered road looks like, especially if they come from the U.S. In fact, I have concluded that much of the damage exhibited by hire cars in Ireland is due to the mental challenge undergone by tourists who are not used to driving on the left, coping with a manual gearbox, and keeping a keen eye out for Irish drivers who cheerfully speed along the narrow roads leaving a full inch on either side of their car, van, or truck. Tourists with a keen eye and a stout heart keep on going while anyone who fades away from the challenge might have a small encounter with a stone jutting out from a wall and so end up with another small dent, scrape, or other damage on the side of their hire car.

In any case, I spent some time last week in Ballinskelligs last week and discovered that this part of Ireland is extraordinarily beautiful if you get any sort of good weather. Two of the three days that we spent in Ballinskelligs were excellent – dry, sunny, and an invitation to be outdoors, so that wasn’t a bad outcome. The other day featured low grey clouds and some rain but it wasn’t enough to keep anyone indoors.

Ballinskelligs Castle

Thankfully for the local economy, tourists were out in force on the Ring of Kerry. Maybe age has made me more tolerant or now I can see the value in driving at a pace where the scenery isn’t a mere blur. Mind you, the last time I spent any time on the Ring was in the late 1970s when I came down for the Circuit of Ireland car rally to see mad men in Fiat Miraforis, Vauxhall Chevettes, and Ford Escorts hurdle around the roads at speeds that posed danger to themselves and the crowds that clung to any available spot that offered some chance of seeing the action.

Atlantic view from Coomatloukane

Stunning views were available over the Atlantic from stops along the Ring such as the car park at Coomatloukane. Even better, the beach at Derrynane proved to be an absolute delight because it was sandy and safe and possessed all of the facilities necessary to justify its rating as a Blue Flag beach.

I took the time to walk from the beach over to Derrynane burial grounds on Abbey Island. The burial grounds are still in use and feature the ruins of St. Finian’s Abbey, which dates from somewhere close to 700AD. It really is a beautiful spot that is worth the effort to walk across to explore. The warning posted by Kerry County Council that the ground is uneven is fair but there’s no great danger lurking as long as you don’t do something silly like attempting to scale the abbey’s ruined walls.

Looking out from the ruins of St. Finian's Abbey

The path to Derrynane beach from St. Finian's Abbey

Strolling around the burial ground and the ruins of St. Finian’s Abbey, you couldn’t help forming a view that this was a very peaceful and serene place that enjoyed a wonderful vista and that those who rested there were lucky in some ways. It reminded me of a similar graveyard on Inis Mor in the Aran Islands that also boasts the ruins of an old church amongst the graves.

Light falls on the walls of Derrynane Abbey

I enjoyed the 30 minutes of solitude and peace that I had exploring St. Finian’s Abbey and the surrounding graveyard. If you get the chance to spend any time close to the Ballinskelligs-Waterville-Caherdaniel area in South Kerry and it’s a nice day, you could do far worse if you headed off to Derrynane beach and walked over to Abbey Island – and if you’re brave enough and there’s enough heat in the day, you might even finish off by taking a swim.

Reasonable books covering this area and the Ring of Kerry include Ireland Insight Step by Step Guide and Irish Coastal Walks.

– Tony

Posted in Travel | Tagged , , | 2 Comments