Sunday, April 03, 2011

Microsoft Exchange Server 2010 SP1 on Windows 2008 Server R2 post-installation gotchas: Installing Active Directory Web Services


Active Directory Web Services (ADWS) is an option to enable Web based API access to Active Directory; predominantly via PowerShell and Active Directory Administration Console (ADAC). Read:

This functionality by default is available on Domain Controllers running Windows 2008 R2 and is currently available as add-on for Windows 2003 and Windows 2008 systems (Download from:

NOTE: ADWS uses TCP port 9389; ensure firewalls to and from clients and ADWS-enabled Domain Controllers does not block this port !!!

Microsoft Exchange Server 2010 SP1 on Windows 2008 Server R2 post-installation gotchas

Installation of Microsoft Exchange 2010 SP1 on a Windows 2008 R2 Server should be a straightforward process due to the descriptive Wizard and auto resume of the Setup process. As per the Wizard, following will be the pre-requisites of the Exchange 2010 installation:

  1. Installation of Microsoft .NET Framework 3.5 SP1
    1. This can be installed from Windows Manager – Add Feature – .NET Framework 3.5
    2. .NET would also require basic Web Service (IIS) role as its dependency.
  2. Running ‘setup /PrepareAD’
    1. This would be run automatically by the Setup process
    2. Make sure the account used to run Setup have the proper Domain and Schema Admins permission
  3. Select the language options
    1. Pretty straightforward, just choose use all language available in the DVD or download from the Internet if your language preference is extensive.

After enabling the basic pre-requisites above and resuming the Setup, further verifications by Role will commence. Depending on your existing configuration of the server, this will include:

  1. Enabling IIS Basic, Integrated Windows and Digest Authentication methods
    1. This can be updated from Windows Manager – Roles – Web Service – Add Role Features
  2. Enabling IIS Static and Dynamic Compression
    1. This can be updated from Windows Manager – Roles – Web Service – Add Role Features

After appeasing the requirements above, you should be able to continue the Setup process. Depending whether you are creating a new Exchange organization or adding a new Exchange server in an existing Organization, additional parameters would be required; this would be very straightforward and Setup should complete successfully. Reboot afterwards !!!

That would be the end of the Exchange installation and you should be happily configuring and using your Exchange installation; NOT !!! Depending on the symptoms that may or may not appear, further tweaking would need to be carried out.

NOTE: This may differ between OS versions (2008 SP2 or 2008 R2 SP1) or Exchange versions (RTM, SP1) etc.

  1. You find the Mailbox Database name to be too robotic (Mailbox_Database_1234567XXX…yuck) and decide to create a NEW Mailbox Database only to have error code 0x00000005 “INSUFF_ACCESS_RIGHTS” thrown at you !!! Read here
  2. You try to remove the default/first Mailbox Database and Exchange complains that you need to move out all mailboxes first before the Database can be deleted; problem is, as far as you can see there are no more mailboxes in the database to be moved out !!! Read here
  3. You open Microsoft Exchange PowerShell and in the initial Module loading stage it complains that Active Directory Web Service cannot find any available Domain Controller !!! Read here
  4. You try opening Outlook Web App (OWA) from your Web Browser (e.g: https://exch2010.tld/owa) and nothing comes out; just a blank page !!! Read here
  5. After rebooting the Exchange Server, after logging in to OWA in the login page, you are then presented with an empty page, or worse HTTP error 5XX !!! Read here

Microsoft Exchange Server 2010 SP1 on Windows 2008 Server R2 post-installation gotchas: Microsoft Exchange services start up issues


This is due to Microsoft Exchange Forms Based Authentication service not running; possibly after a normal reboot or power failure.

This is a Microsoft known issue since Exchange 2003 and also affects the Microsoft Exchange System Attendant service. Read and use the solution in

Microsoft reports that this issue affects installations of Exchange on Domain Controllers due to the delayed Global Catalog availability but it is prevalent even on standalone Exchange installations.

The only solution thus far is to configure the affected services with a Automatic Startup (Delayed) as opposed to the default Automatic Startup.

Also enable the 1st, 2nd and 3rd service recovery to attempt startup of the services if startup failed in the first try.

Microsoft Exchange Server 2010 SP1 on Windows 2008 Server R2 post-installation gotchas: Exchange 2010 required Windows Features


Thanks to

After successfully installing Exchange 2010, if you find your OWA page to be blank (but with a successful redirection URI, e.g: https://exch2010.tld/owa/logon/logon.aspx?blablabla) you may not  have all the dependencies installed. Install them using the steps below:

1. Installing dependencies using PowerShell. NOTE: This may reboot the server !!!

   1: Import-Module ServerManager
   2: Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

2. Installing dependencies using Server Manager:

    1. Open Windows Manager-Features-Add Features

    2. Add the RPC over HTTP Proxy feature; this will auto-install the other required dependencies as the PowerShell method above.

Retry the OWA login via your Web Browser.

NOTE: If the initial OWA login page can be displayed but a blank page is displayed ONLY after submitting the login, this could be due to the Microsoft Exchange Forms Based Authentication service not starting !!! Read here

Microsoft Exchange Server 2010 SP1 on Windows 2008 Server R2 post-installation gotchas: Deleting Arbitration Mailboxes

Exchange mailboxes consists of the normal user/resource Mailboxes and Arbitration mailboxes.

Arbitration mailboxes are “… used for managing approval workflow. For example, an arbitration mailbox is used for handling moderated recipients and distribution group membership approval”. Refer:

To delete a Mailbox database (especially the first created Mailbox database), you need to move out ALL mailboxes first into another Mailbox database.

In a normal Exchange console or from Get-Mailbox command these Arbitration mailboxes would not appear unless supplied with an additional –Arbitration parameter. Thus, in Exchange 2010, to move all mailboxes to another database would require the following command:

1. Moving all normal user/resource mailboxes from DB1 to DB2

   1: Get-Mailbox -Database DB1 | New-MoveRequest -TargetDatabase DB2

2. Moving all Arbitration mailboxes from DB1 to DB2

   1: Get-Mailbox -Database DB1 -Arbitration | New-MoveRequest -TargetDatabase DB2

Wait for the move request to complete and delete/remove the required database.

Microsoft Exchange Server 2010 SP1 on Windows 2008 Server R2 post-installation gotchas: 0x00000005 INSUFF_ACCESS_RIGHTS

This is possibly due to disabled ‘Inheritable permission’ option causing the ‘Exchange Trusted Subsystem’ group not being able to have Full Access to a number of important Microsoft Exchange OUs in the Active Directory configuration dSE.

As Exchange 2010 runs its Active Directory access via the Exchange Trusted Subsystem group permission (not as the logged-on user account permission), relevant objects in the Active Directory would require Full Access rights for this group. This would be (automatically) achievable if the Active Directory objects inherit the permissions from the parent object as the parent’s security permission is changed during Exchange setup’s PrepareAD process.

However, if certain child objects have their Inheritable permission option disabled beforehand, it would not acquire the correct permission level for the Exchange Trusted Subsystem to access them. For resolution, use the steps below:

  1. Using ‘adsiedit,msc’ traverse the Active Directory configuration schema and verify that the following OUs have its inheritable permission enabled (checkout Richard’s Exchange Ramblings blog:
    1. RootDSE-Configuration-Services-Microsoft Exchange-First Organization
    2. RootDSE-Configuration-Services-Microsoft Exchange-First Organization-Administrative Groups
    3. RootDSE-Configuration-Services-Microsoft Exchange-First Organization-Administrative Groups-Exchange Administrative Group (FYDIBOHF23SPDLT)
  2. Remove the Exchange Server computer account from the Exchange Trusted Subsystem group and adding it back again.
  3. Reboot the relevant Exchange server.
  4. Ensure that your currently logged-on account is a member of the Active Directory Schema admins.
    1. In an Administrator elevated Command Prompt re-run Exchange setup’s PrepareAD parameter “%ExchangeInstallationFiles\setup /PrepareAD”
    2. Reboot the Exchange server again.