Sunday, July 28, 2013

Exchange 2007 (SP3) - migration (staged) - Exchange Online (Office 365) - Part 3 - Domain Names



Adding (and validating) a domain name to Office 365



When we sign up for Office 365, we select a domain name that by default becomes a subdomain of "onmicrosoft.com".
 
For example, if we take the fictional company, contoso.com, often used by Microsoft as an example in its literature, and imagine its management decides to migrate to Office 365, that would (by default, once again) give us something like this:
 
contoso.onmicrosoft.com
 
If "John Smith" is the administrator who set up the Office 365 account, he would connect using the following logon name (if his user name is john.smith):
 
john.smith@contoso.onmicrosoft.com
 
Most organizations, however, will prefer to use their own domain name, not only because it represents them, but also because it is easier to enter without having to add "onmicrosoft" each time one logs on.
 
We accomplish this by connecting to Office 365 and adding a domain. We also will need to prove to Microsoft that we own the domain. But one step at a time...
 
 
Add a domain
 
1. Logon to Office 365 using the "long" username (with "onmicrosoft.com").
 
Enter "login.microsoftonline.com" for the URL.
 
It will automatically change to the more secure "https://login.microsoftonline.com"
 
 
 
 
 
2. We then enter our username and password:
 
 

 
 
This should bring us to the "Office 365 admin center" where we can (among many other things) manage our domains. Click on "domains" to do this (left-hand side of the screen):
 
 
 
 
 
 
The instructions explain that your Office 365 accounts comes with a name like... "contoso.onmicrosoft.com" but that you can add your own domain - if you own one. If you do not, you can purchase one from a domain registrar such as Network Solutions or GoDaddy. Since I already have purchased a domain name, I'll add it to my Office 365 account:
 
3. Click on "Add a domain"
 
 
 
We'll start with the first step "Specify a domain name and confirm ownership"
 
 
 
4. I enter my domain name and click next.
 
 
 
 
Validate the domain (confirm ownership)
 
5. Select your DNS provider - if listed. Mine is not listed so I will use the general instructions.
 
 
 
We are directed to create certain DNS records:
 
 
 
 
 
 
6. I'll create a TXT record in the management interface of my DNS provider.
 
 
 
 
 
Note: this step is NOT performed in Office 365 but rather using the interface of your DNS provider.
 
 
The interface will be more or less different with each provider. But in the end, it's simply a matter of creating a DNS "TXT" record.
 
Note: if your DNS provider does not offer a TXT record option, you can resort to the MX option. If the record is created according to MS instructions, it should have no effect on mail flow. Moreover, once validation is complete, the record can be removed. It is not intended to be functional (i.e. direct SMTP traffic) but simply allow for verification of domain name ownership.
 
I click on the "Verify" button toward the bottom of the screen and... in a couple seconds see that verification was successful.
 
Click "Finish".
 
Now, since I plan to migrate users with DirSync rather than creating them directly in Office 365, I will not proceed to Step 2 for the time being.
 
 
 

Tuesday, July 23, 2013

Exchange 2007 (SP3) - migration (staged) - Exchange Online (Office 365) - Part 2 - Outlook Anywhere

Outlook Anywhere: enabling, testing and troubleshooting


Although Outlook Anywhere, enabled on the onsite Client Access Server(s), is a requirement for migration to Exchange Online, many organizations will have already enabled it for simple client access onsite. In that case, there is no need to enable it, since it already is enabled, and probably no need to test or troubleshoot either.

Nevertheless, I've decided to post the following instructions for those who may not use Outlook Anywhere but are planning a migration to Exchange Online. I'll also share my solution to a problem with Outlook Anywhere, apparently related to IPv6, and that I was able to resolve without having to disable IPv6 entirely.

If you have already enabled Outlook Anywhere, and if it is perfectly functional, you could skip to "Part 3" of this series on a staged Exchange 2007 to Office 365 migration without reading the rest of this post.
 


Enable Outlook Anywhere

 
First, let's just enable Outlook Anywhere. The following cmdlet, entered at the EMS command line, is probably the most simple way to enable Outlook Anywhere:
 

Enable-OutlookAnywhere -Server 'Server1' -ExternalHostname 'mail.mydomain.net' -DefaultAuthenticationMethod 'Basic' -SSLOffloading $false

 
Note: if you do use SSLOffloading, change the value to "true".

 
If you really prefer the GUI, here is the equivalent procedure:

 
1. Right click on the server icon as shown below ("Server Configuration" section, "Client Access") and select the option "Enable Outlook Anywhere:
 






2. Enter the external host name. If your domain was contoso.com and you use mail.contoso.com for external access (to OWA, for example), that is what you would enter. I have concealed my domain name for privacy. In reality, you would enter the complete domain name.






3. You can verify that Outlook Anywhere has been enabled in Event Viewer. There should be an Event ID 3006 entry in the Application Log.








Test and troubleshoot Outlook Anywhere (optional)



In case of a problem with connectivity, especially outside the LAN, the Exchange Remote Connectivity Analyzer, or ExRCA, is one of the most useful troubleshooting tools available.


It can be found at the following URL:

www.testexchangeconnectivity.com

In case the URL ever changes, you could also look for "ExRCA" using your preferred search engine (Bing, Google, etc.).


One pre-requisite is the creation of a user account whose credentials can be used for the various tests. It is recommended to create such an account for testing purposes and then delete the account afterwards so the credentials cannot be reused or misused, presumably by someone who could conceivably access them one way or another.


On the ExRCA homepage, we can select from several tests: ActiveSync, Web Services, Outlook Anywhere, Autodiscover as well as Inbound and Outbound SMTP message flow.







In the context of my migration to Exchange Online, which requires Outlook Anywhere, I'll select the "Outlook Anywhere" test.


I enter the credentials of my test user:






The tool requires us to enter a "verification code" as well. The verification is valid for 30 minutes, after which another verification code must be entered:




I then click on "Perform Test" (in the lower right-hand corner).

The results are displayed...






And I have the option to "Start Over" or "Run Test Again".





The Outlook Anywhere test is successful in this case but let's create a situation where it would fail and then resolve the problem (this is, in fact, the problem I encountered when I performed the test for the first time).


***

 

In this scenario, we are running Exchange 2007 (SP3) on a Windows 2008 (SP2) server. By default, a component known as the RPCProxy attempts to connect, preferably with IPv6, to a component known as the DSProxy that... does not listen for IPv6 connections.


This produces the following error message:

If we expand, we can see the détails of the error:





Note: this was the case for Exchange 2007. I have SP3 with Rollup 10 installed so, even at that patch level, the problem apparently requires the modification that follows.
 
I was able to resolve this problem by simply adding a DWORD value ("DisabledComponents") at the following location in the registry of the Exchange 2007 server and entering "20" (without quotes) for the value data (hexadecimal):
 
HKEY_Local_Machine\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
 
This makes IPv4 the preferred protocol.
 
It was not necessary to disable IPv6, using the more "extreme" settings below, or on a particular network interface.
 
  • Type 0 to enable all IPv6 components. (Windows default setting)
  • Type 0xffffffff to disable all IPv6 components except the IPv6 loopback interface. This value also configures Windows to prefer using IPv4 over IPv6 by changing entries in the prefix policy table.
  • Type 0x20 to prefer IPv4 over IPv6 by changing entries in the prefix policy table.
  • Type 0x10 to disable IPv6 on all nontunnel interfaces (both LAN and Point-to-Point Protocol [PPP] interfaces).
  • Type 0x01 to disable IPv6 on all tunnel interfaces. These include Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6to4, and Teredo.
  • Type 0x11 to disable all IPv6 interfaces except for the IPv6 loopback interface.

Note: the "0x" indicates the value is hexadecimal. It is not necessary to enter "0x" and the registry editor may not even allow this.

 
Source:
 

 
 
 
 
 
 








Sunday, July 21, 2013

Exchange 2007 SP3 - migration (staged) - Exchange Online (Office 365) - Part 1

 
INTRODUCTION...
and creation of an Office 365 tenant (part 1)
 
 
INTRODUCTION
 
Cloud-based solutions for email are becoming more and more prevalent. Exchange Online (part of Office 365) is MIcrosoft's product - or service - in this market. In most cases, especially for medium and large sized businesses, there is already a "onsite" or "on-premises" messaging solution in place: possibly Exchange 2003, more likely Exchange 2007 or 2010. The challenge is to migrate the messaging system to the "Cloud", or more prescisely, in this case, to Exchange Online.
 
Of course, my assumption is that the existing messaging solution is a Microsoft product (some version of Exchange). Migrating from a non-Microsoft product would be well beyond the scope of this article and probably beyond the native Microsoft migration tools.
 
There are three primary migration options, ranging from an almost immediate transfer of email operations to Exchange Online to a coexistence scenario where the onsite and online versions of Exchange could interact for months or even years:
 
  • Cutover
  • Staged
  • Hybrid
 
The terms are not quite self-explanatory but one might be able to guess what each one means. "Cutover" represents the most rapid transition, something that might be performed over the weekend. "Staged" refers to a migration in stages, or steps, or phases. The migration does not happen in a day or two, it may even take weeks (or months) to accomplish but the objective is to move all operations to Exchange Online. In the "Hybrid" scenario, some mailboxes may remain on premises for a long period of time.
 
The version of Exchange onsite may limit migration choices. In particular, the staged migration is only an option with Exchange 2003 or 2007. With Exchange 2010, only the cutover and hybrid options are possible.
 
In the majority of migration scenarios, at least some resources will remain onsite and Active Directory Domain Services in particular. This requires some sort of directory synchronization so user, contact and group accounts are available for use with Exchange Online in the Cloud.
 
Once again, we have three options:
 
  • Cloud-based credentials only. I'll mention this option only as a basis for comparison, since no synchronization takes place. User credentials only exist in the Cloud, in Office 365. This would only be suitable for (probably very small) organizations that have no requirement to authenticate users onsite. Users would logon to their devices with local (not domain) credentials, or might not logon at all, and then access Exchange Online afterwards.
  • DirSync. this tool synchronizes onsite account information, and more recently password hashes, to Office 365 so they can be used to authenticate users accessing Exchange Online. DirSync provides "Same-Sign-On" as opposed to "Single-Sign-On" functionality. We can use the same password to access onsite and online resources but we may have to logon more than once when accessing email. For example, I would logon to my laptop to access the desktop and when I open Outlook by clicking on my shortcut, I would have to enter the password again.
  • Active Directory Federation Services (ADFS). This option provides "Single-Sign-On" functionality. When a user with an online mailbox attempts to open Outlook, ADFS allows Exchange Online to query onsite Active Directory just as Exchange would do if it were located onsite.
 
 
In the following lines, and subsequent posts, I will perform a staged migration from Exchange 2007 SP3 to Exchange Online (Office 365). As for directory synchronization, I will opt for the DirSync solution.
 
Users may have to logon more than once to read their email in Outlook but DirSync only requires one server, possibly an existing server. Even if the server in question fails, users can still access their email as long as their credentials have already been synchronized to Exchange Online. Of course, DirSync would have to be placed back in service so new user credentials, and changes to existing user credentials, could be synchronized as needed.
 
Note: the ADFS option requires high-availability and potentially as many as four additional servers and possibily a load balancer. Yes, one could conceivably run ADFS as another role on some existing domain controllers and even do without the proxy servers, not to mention the load balancer, but this would violate best practices in several respects, and probably place the organization at risk of a loss of service. In any case, I will not address this option in this article.
 
 
CREATION OF AN OFFICE 365 TENANT
 
The first step is to purchase an Office 365 business plan.
 
Of course, if you are acting as a simple individual, or on behalf of an educational or government organization, there are other plans.
 
Otherwise, the relationship between the customer and Microsoft is comparable to that between a renter and the building owner. Microsoft owns Office 365 and the customer rents space from Microsoft to run their business.
 
So the customer must become a "tenant" of Microsoft, of Office 365, to obtain the use of this space and associated services.
 
Note: these links were accurate at the time of this writing. They could change - just like the Office 365 interface.
 
 
1. Go to the Office 365 homepage.
 
 
Your region will probably be detected and the URL automatically adjusted.
 
 
2. Click on "Products", then "Compare Options".
 
 
 
 
 
 
 
 
3. Select the "Enterprise" tab, then "Hosted email" (Exchange Online Plan 1).
 
 
 
 
Note: this is the option that I've selected for this article. I could have opted for the trial version of another plan (the hosted email plan does not have a trial option) but it expires in 30 days and I intended to practice various scenarios for a longer period of time. Of course, if your organization requires more services than hosted email, you would want to examine the other plans.
 
 
4. Setup your account.
 
 
Enter the required information.
 
 
 
5. Customize your order.
 
 
 
 
I'll migrate two mailboxes for this exercise so I'll purchase two user licenses.
 
 
 
6. Review the order.
 
 
 
Note: personal information is summarized to the right - I've cropped the screenshot to remove this.
 
 
7. Read and accept the legal agreement.
 
 
 
 
8. Pay.
 
 
Note: once again, my screenshot does not show all details, my credit card number for example.
 
There will be a confirmation page indicating that you will receive an email.
 
 
 
ACCESS OFFICE 365
 
Once the procedure outlined above is complete, we can access Office 365 (of which Exchange Online is a part) at the following address:
 
 
 
 
The URL will automatically be adjusted to the more secure HTTPS connection:
 
 
 
 
 
You logon using the same credentials selected when you configured your account just before purchase.
 
 
This completes the first phase of migrating to Exchange Online: creating a tenant.


Saturday, July 6, 2013

Exchange 2010 - Security - Auditing administrator access to mailboxes


 


Introduction
 
From time to time, on the Technet Exchange forums, someone will ask a question about Exchange administrators accessing another user's mailbox. They may suspect that an administrator is reading other staff member's email or management may simply have requested that IT take measures to prevent this proactively.
 
Some respond that you have to trust your administrators and if you cannot, fire them and hire administrators that you can trust.
 
Some propose a more technical - and more complex - solution with S/MIME or IRM/RMS. The key point here is that since these solutions are based on certificates and public/private key pairs, the administrators that manage Exchange and the certificate administrators should not be the same. If this is the case, users can encrypt their email with S/MIME and since the Exchange administrators do not have the appropriate key, they could not open and read the email of other employees.
 
In this post, I'm going to take a look at another approach based on monitoring...
  1. access to mailboxes and...
  2. modifications to access rights on mailboxes.
 
The objective is not to block administrator access to mailboxes but to log any attempts to access these mailboxes.
 
This approach is really only feasible in an organization with more than one administrator on staff. The person (or team) responsible for monitoring the logs would be different from the person that manages Exchange.




Default permissions on mailboxes (administrator access)
 
By default, administrators do not have access to anyone's mailbox. In fact, if we except the system itself, only the user has access to their mailbox. This is represented by the entry "SELF".
 
 
Right-click on the mailbox in question and select "Manage Full Access Permission".
 
 


 
 
 
 
 
 
However, the resulting entry in the "Manage Full Access" interface is the product of a rather complex interaction among permissions that is better illustrated in the output of the Get-MailboxPermission cmdlet (please feel free to skip to the summary that follows, below):
 
*************************
*************************
 
 
Get-MailboxPermission ana.hayes@mynet.lan | fl User,AccessRights,IsInherited,Deny


 

User         : NT AUTHORITY\SELF
AccessRights : {FullAccess, ReadPermission}
IsInherited  : False
Deny         : False

 
User         : MYNET\Domain Admins
AccessRights : {FullAccess}
IsInherited  : True
Deny         : True
 
User         : MYNET\Enterprise Admins
AccessRights : {FullAccess}
IsInherited  : True
Deny         : True
 
User         : MYNET\Organization Management
AccessRights : {FullAccess}
IsInherited  : True
Deny         : True
 
User         : MYNET\Exchange Organization Administrators
AccessRights : {FullAccess}
IsInherited  : True
Deny         : True
 
User         : MYNET\admin
AccessRights : {FullAccess}
IsInherited  : True
Deny         : True
 
User         : MYNET\Exchange Servers
AccessRights : {FullAccess}
IsInherited  : True
Deny         : False
 
User         : MYNET\Organization Management
AccessRights : {ReadPermission}
IsInherited  : True
Deny         : False
 
User         : MYNET\Public Folder Management
AccessRights : {ReadPermission}
IsInherited  : True
Deny         : False
 
User         : MYNET\Exchange Public Folder Administrators
AccessRights : {ReadPermission}
IsInherited  : True
Deny         : False
 
User         : NT AUTHORITY\SYSTEM
AccessRights : {FullAccess}
IsInherited  : True
Deny         : False
 
User         : NT AUTHORITY\NETWORK SERVICE
AccessRights : {ReadPermission}
IsInherited  : True
Deny         : False
 
User         : MYNET\Exchange Servers
AccessRights : {ReadPermission}
IsInherited  : True
Deny         : False
 
User         : MYNET\Delegated Setup
AccessRights : {ReadPermission}
IsInherited  : True
Deny         : False
 
User         : MYNET\Exchange View-Only Administrators
AccessRights : {ReadPermission}
IsInherited  : True
Deny         : False
 
User         : MYNET\Organization Management
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited  : True
Deny         : False
 
User         : MYNET\Exchange Organization Administrators
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited  : True
Deny         : False
 
User         : MYNET\Exchange Trusted Subsystem
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited  : True
Deny         : False
 
User         : MYNET\admin
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited  : True
Deny         : False
 
User         : MYNET\Enterprise Admins
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited  : True
Deny         : False
 
User         : MYNET\Domain Admins
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited  : True
Deny         : False


******************************
******************************
 
 
Let's attempt to summarize.
 
In Exchange 2010 at least, READ access to the user's mailbox is specifically denied to common administrative groups. This means that even if they belong to a group that may have READ access otherwise, they are still denied READ access because of this single "Deny" permission.
 
 
For example:
 
User         : MYNET\admin
AccessRights : {FullAccess}
IsInherited  : True
Deny         : True
 
On the other hand, Exchange administrators most certainly can change permissions on the mailbox.
 
We cannot see this in the GUI but the Get-MailboxPermission cmdlet shows all these details:
 
User         : MYNET\admin
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited  : True
Deny         : False
 
"ChangePermission" is not denied here. Full Access is not either but it is elsewhere. A single "Deny" permission will suffice to block access.
 
 
Let's test this!
 
When we need to access another person's mailbox in Outlook, we follow this path (after opening Outlook - Outlook 2010 in this example):
 
File (tab) | Account Settings | Change (select email account if several) | More Settings | Advanced | Open these additional mailboxes
 
 
 
 
Yes, the administrator is able to add the mailbox to Outlook... but cannot open it. If I try, this is what happens:
 
 
 
 
 
Now let's have the administrator grant himself "Full Access" to Ana Hayes' mailbox:
 
 
 
 
Here is the EMS - PowerShell equivalent:
 
 
Add-MailboxPermission 'CN=Ana.Hayes,OU=ExchangeUsers,DC=mynet,DC=lan' -User 'MYNET\admin' -AccessRights 'FullAccess'
 
 
This changes the output of the Get-MailboxPermission cmdlet. Now the "Deny" for the READ permission is no longer "True":
 
*************************
 
 
Get-MailboxPermission ana.hayes@mynet.lan | fl User,AccessRights,IsInherited,Deny


User         : NT AUTHORITY\SELF
AccessRights : {FullAccess, ReadPermission}
IsInherited  : False
Deny         : False

 

User         : MYNET\admin
AccessRights : {FullAccess}
IsInherited  : False
Deny         : False


************************
 
 
Now the admin can open the the mailbox of Ana Hayes and read her email!
 
 
 
 
 
In this case, the content is not very interesting but if it were, the administrator could read it.
 
Note: the admin CANNOT open the email message marked with the padlock which has been encrypted with S/MIME:
 
 
 
 
 
However, the administrator has left traces! Granted, we would have to know where to look to find those traces.
 
So... where do we look?
 
There are at least two places we can find this information:
 
 
  1. The Powershell equivalent of the actions performed in the EMC is logged in the MSEXchange Management section of the Event Viewer.
  2. We can perform a search for "non-owner mailbox access" in the Audit section of the Exchange Control Panel (ECP).
 
 
 
Actions added to the MSEXchange Management log
 
 
On the mail server, we have to open the Event Viewer and go to the MSEXchange Management section:
 
 
 
At that point, we are looking for a "needle in a haystack". The Event ID is 1 but the Event ID for the execution of other Powershell cmdlets is also 1. This is how the entry appears:
 
 
 
We can see that even though the EMC (GUI) was used to grant the administrator access to the mailbox, the underlying PowerShell cmdlet was logged in the Event Viewer.
 
Of course, the administrator could clear the MSExchange Management log.
 
But such an event would be logged in the System Log:
 
 
 
 
But what if the admin clears the System Log? That too would be logged:
 
 
 
 
Otherwise, the loss of these entries would be noticed if anyone else is monitoring the logs. That is the key point. If there is only one administrator, there's probably no one else looking at the logs anyway.
 
We've demonstrated that an adminstrator cannot grant himself access to someone else's mailbox without the event being recorded in the Event Viewer logs. However, we have also seen that even if a second person is monitoring these logs, it is not easy to find evidence of such actions even when the evidence is there.
 
Is there a better way?
 
Yes.
 
We can use the ECP Audit option "Search for Mailbox Access by Non-Owners".
 
 
 
 
Search for Mailbox Access by Non-Owners
 
 
Once we have logged into the ECP (I'll assume that if you are managing an Exchange 2010 server, you know how to do this), we must go to the following location:
 
Mail | Options: Manage My Organization | Roles and Auditing | Auditing (tab)
 
Select the option "Run a non-owner mailbox access report":
 
 
 
 
 
 
 
At first, this option does not seem very convincing. I know I've accessed Ana Hayes' mailbox as administrator yet no results appear:
 
 
 
 
Note: the "Search" button, not shown in the screenshot above,  is off to the right.
 
In fact, as we can see below, mailbox auditing is not enabled by default so we have to enable it manually:
 
****************
 
[PS] C:Get-Mailbox ana.hayes@mynet.lan | fl *auditenabled*

AuditEnabled : False
 
[PS] C:\>Set-Mailbox ana.hayes@mynet.lan -AuditEnabled $true
[PS] C:\>
[PS] C:\>Get-Mailbox ana.hayes@mynet.lan | fl *auditenabled*

AuditEnabled : True
 
 
*****************
 
The problem is that it does not function even after that...
 
"There are no items to show in this view".
 
I selected "All non-owners".
 
I've been clicking all over the place in Ana Hayes' mailbox. There is obvious access but nothing is being logged...
 
Here is what's happening.
 
  1. Not all actions are logged. In fact, simple access is not logged for "Delegates".
  2. Administrators that have been granted (or that have granted themselves) "Full Access" are considered "Delegates".
 
The following commands show what actions, by default, are logged, after logging is enabled:
 
*********************
 
[PS] C:\>(Get-Mailbox ana.hayes@mynet.lan).auditadmin
 
Update
Move
MoveToDeletedItems
SoftDelete
HardDelete
FolderBind
SendAs
SendOnBehalf
Create
 
[PS] C:\>(Get-Mailbox ana.hayes@mynet.lan).auditdelegate
 
Update
SoftDelete
HardDelete
SendAs
 
 
*********************
 
In particular, the action "MessageBind" which consists of viewing or opening a message is not logged by default for anyone - even when auditing is enabled. Strangely enough, it appears that we cannot add the action "MessageBind" for delegate auditing. I did try:
 
********************
 
[PS] C:\>Set-Mailbox ana.hayes@mynet.lan -auditDelegate update,softdelete, harddelete,sendas,create,folderbind,messagebind

Invalid audit operation specified. Supported audit operations for Delegate are None, Create, FolderBind, SendAs, SendOnBehalf, SoftDelete, HardDelete, Update, Move, and MoveToDeletedItems.
    + CategoryInfo: NotSpecified: (Microsoft.Excha...asks.SetMailbox:SetMailbox) [], RecipientTaskException
    + FullyQualifiedErrorId : DB4194A
 
 
********************
 
 
After all is said and done, since the administrator is considered a "delegate" here, we cannot audit the reading of an email by an administrator!
 
Given the default settings, results could only be obtained if I created a new folder and moved a message to this folder. Besides the creation of the folder, this resulted in a "soft-delete" of the message which was logged:
 
 


 
Let's see if we can at least audit folder access?
 
 
I add the action FolderBind to the list of audited actions with the following results:
 
******************
 
[PS] C:\>Set-Mailbox ana.hayes@mynet.lan -auditDelegate update,softdelete, harddelete,sendas,create,folderbind

[PS] C:\>


[PS] C:\>(Get-Mailbox ana.hayes@mynet.lan).auditdelegate

Update
SoftDelete
HardDelete
FolderBind
SendAs
Create


 
******************
 
 
However, I seem to obtain no more results than before (two hours earlier).
 
In fact, the logging process seems to require a minute or two.
 
If I wait a moment (several minutes) the "Open Folder" actions are indeed logged:
 
 


 
 
 
The methods above allow monitoring of administrator access to mailboxes in Exchange 2010. They do require some configuration effort.
 
Exchange 2007 did not provide any of the options presented above, but rather another method that required the logging level for the MSExchangeIS service to be increased to "medium". For more information, please consult the references below, in particular the article by Neil Hobsen.

 
 
References:


Auditing Mailbox Access (Exchange 2010) - by Nuno Mota


These articles apply to Office 365 but the content seems to apply to Exchange 2010 as well:

Use Auditing Reports in Exchange Online

Run a Non-Owner Mailbox Access Report

Run a non-owner mailbox access report in Auditing



Auditing mailbox access in Exchange 2007

Exchange Team Blog - Service Pack 2 Highlight: Mailbox Access Auditing

Exchange 2007 Mailbox Access Auditing - by Neil Hobsen