Exchange 2007 access to all mailboxes for Administrator

24 05 2009

Deploying Exchange 2007 can have its problems at the best of times. The separation of Exchange management from the Active Directory tools also has a knock-on effect when it comes to granting Exchange-related permissions en masse. This seemingly easy task is now proving to be a minefield.

So, how do you grant an Administrator access to all the mailboxes for an Exchange 2007 Mailbox Database?

Remove the Default Permissions

Before you start, you need to remove the default permissions at the Exchange Organization Level. These apply to all mailboxes in the organization and specifically deny any administrative-type user the Send-As and Receive-As permissions. This may cause confusion later, so it is best to remove them.

The user accounts and groups which are denied the ‘Receive-As’ permission at the organization level are:

  • DOMAIN\Administrator
  • DOMAIN\Domain Admins
  • DOMAIN\Enterprise Admins
  • DOMAIN\Exchange Organization Administrators

In order to remove the Deny entry for all the above users, the following command should be used:

Get-OrganizationConfig | Remove-ADPermission -User “DOMAIN\Administrator” -AccessRights ExtendedRight -ExtendedRights Receive-As -Deny

Replace DOMAIN\Administrator with the other entries in the above list to remove the permission for those accounts too.

The Commands

Having removed the default permissions, you can now set about implementing the permissions needed. Prior to discussing the actul Powershell commands to use, it is important that you understand the different types of permission which can be granted:

  • FullAccess Mailbox Permission. This can only be granted at the individual mailbox level to a user or group of users; it allows the designated users the ability to access the mailbox via Outlook or the new feature to open another user’s mailbox in Outlook Web Access.This permission is granted directly on the mailbox using the cmdlet Add-MailboxPermission. An example might be Add-MailboxPermission -Identity JDoe -User MSmith -AccessRights FullAccess where MSmith is being granted the ability to access JDoe’s mailbox.This permission can also be granted via the Exchange Management Console. Selecting a Mailbox in Recipient view adds an option Manage Full Access Permission to the actions pane, where this permission can be managed in a similar fashion.The problem with granting permissions in this fashion is it has to be done on an individual mailbox basis. For granting permissions en masse, it would defeat the principles of granting permissions due to the administrative overhead of maintaining the ACLs. Instead, permissions should be granted on a common parent object and allowed to inherit to the child objects, in this case, the mailboxes.
  • Receive As Active Directory permission. This permission can be set either at the mailbox level, or at a higher level in the Active Directory tree. It has the same effect as Full Mailbox Access, with the difference that it can be set at the store or storage group level, and therefore will be inherited down by all decendent mailboxes.Generic Active Directory permissions related to Active Directory objects are granted and modified at the Management Shell using Add-ADPermission. This cmdlet expects the -Identity parameter to be a full Active Directory path – I believe a Distinguished Name is expected. It is, therefore, much easier to pipe this path from the result of a previous command, particularly when handling some of the more complicated Exchange objects with complex DNs. For example, to grant these permissions at the store level (the store being an Active Directory object), I could use: Get-MailboxDatabase -Identity “My Database” | Add-ADPermission -User “DOMAIN\Group of Users” -AccessRights ExtendedRight -ExtendedRights Receive-As

The problem with granting Receive As permissions is while Outlook will obey them and happily display a mailbox where the Receive As permission is inherited, the new feature of Outlook Web Access which allows other mailboxes to be opened does not. For the OWA feature to work, the user must be granted explicit Full Mailbox access on an individual mailbox basis, to every mailbox they need to access.

My Approach

To achieve the ultimate objective of allowing Domain Admins to access a mailbox, either from Outlook or OWA, I chose to use several commands.

I first granted Domain Admins ‘Receive-As’ access at the store level using the command I described above. Via Outlook, these permissions would allow any Domain Admin to open these mailboxes as additional mailboxes.

To counteract the OWA restriction, I had to grant the Full Access permission across every mailbox. While this is very messy to maintain, it is currently the only option. Furthermore, as new mailboxes will not have the permission set by default, I use a Scheduled Task with a small PowerShell script, to set the permissions for every mailbox once per day.

My PowerShell script (.ps1 file) consists of the following:

# Matt’s Powershell Script (see tigermatt.wordpress.com) to add Full Mailbox permissions to all mailboxes in the Exchange organization
Add-PSSnapin Microsoft.Exchange.Management.Powershell.Admin -erroraction silentlyContinue
$userAccounts = get-mailbox -resultsize unlimited
ForEach ($user in $userAccounts)
{
add-MailboxPermission -identity $user -user “Domain Admins” -AccessRights FullAccess
}

Via Task Scheduler (Windows Server 2008), you can launch the script by specifying powershell.exe as the application, and “& ‘C:\path\to\script.ps1′” as the parameter. Note the double-quote followed by single-quote, and the requirement to close both quotes at the end of the command.

On the basis defined by your Scheduled Task configuration (I would suggest the task runs daily during the night, when the load on the server is low), the script will enumerate all mailboxes in the Exchange Organization, adding the required Full Access permission to the Domain Admins group.

This concludes my entry on granting various permissions in Exchange using Powershell. I hope I have cleared up some concerns regarding the differences between adding Mailbox Permissions and adding Active Directory permissions, and that this helps you.

Advertisements




Microsoft Exchange: Stores fail to start with 0x8004010f error

21 05 2009

I was recently involved in a migration from a legacy Exchange 2000 Organization to a new Exchange 2007 deployment. All was going well until the Information Store service on the Exchange 2000 Server was restarted, but failed to start due to the following error:

Unable to initialize the Microsoft Exchange Information Store service. Error 0x8004010f
Event ID: 5000 Source: MSExchangeIS

On attemping to start the Information Store manually, I was greeted with a not-particularly-verbose error stating the process failed with service-specific error code ‘0’.

The issue was caused in this case by the X400 address, required by Exchange 2000/2003 for internal communications, being removed from the Default Recipient policy. Although legacy Exchange organizations require this address, Exchange 2007 deployments without any legacy Exchange Servers will function without the address , and it is possible some aspect of the new server configuration removed the entry.

Resolution

To restore the address, open Exchange System Manager on a legacy Exchange Server and edit the Default Recipient Policy. If no X400 address is present, add a new X400 address into the Recipient Policy using the appropriate information. Since removing an entry from a Recipient Policy does not remove the entry from existing mailboxes, I retrieved the required settings from an existing mailbox using the management tools on the new Exchange 2007 Server.

Once the address is added, or if it was present already but unchecked, you need to enable the entry. Attempting to check or uncheck the entry in ESM will more than likely result in an error:

X400 address cannot be disabled using Exchange System Manager

X400 address cannot be disabled using Exchange System Manager

This error is to be expected, since Exchange 2000/2003 requires the X400 address and will therefore prevent any attempt to remove it as a safety precaution. To enable the address, you need to perform a low-level edit using ADSIEdit on a Domain Controller.

Usual warnings apply – ADSIEdit can make permanent and potentially destructive changes to Active Directory. Use the tool at your own risk and with proper backups in place.

In ADSIEdit at a Domain Controller, expand the Configuration Naming Context and drill down through CN=Services > CN=Microsoft Exchange > CN=<Your Exchange Organization Name> > CN=Recipient Policies. Right click the Default Policy and choose Properties. You will notice the X400 address is listed within the ‘disabledGatewayProxy’ attribute. To enable:

  1. Edit the disabledGatewayProxy attribute and remove the X400 address.
  2. After pressing the ‘Remove’ button, the X400 configuration contents generated by Exchange are placed into the textarea. Copy this data.
  3. Close the attribute so it is now stored blank. Edit the ‘gatewayProxy’ attribute, which is the location for enabled entries in the policy, and add the X400 contents from your clipboard.
  4. Store your changes, then wait for or manually force Active Directory replication prior to restarting the Exchange Services.

Viola! Your IS service should now start and you can mount the stores. If the X400 issue was not the culprit, it is more than likely permissions within Active Directory. Verify the Exchange 2000/2003 computer is a member of the legacy Exchange Domain Servers group, and that group is in turn a Member Of the Exchange Enterprise Servers security group. You should then use ADSIEdit to check and reset certain permissions; the changes required are detailed over at Technet.

Special Thanks are due to kieran_b who offered assistance during his evening and at a moment’s notice to help resolve this issue.