“Failure [0xC3EC7814] Pool is not ready” while adding OCS Server to Pool

by Shijaz Abdulla on 19.05.2008 at 21:01


I was trying to get Office Communications Server 2007 (OCS) to work on our environment for the past few days and ran into some challenging issues.

OCS 2007 is being installed on Windows Server 2003 x64 R2 with SP2, and the SQL 2005 back end is on a separate machine. Co-existing the two on the same box is not supported.

Our environment used to have an LCS 2005 Pool, which had been decommissioned while setting out on the OCS adventure. The schema preparation, creating an enterprise pool, and configuring the pool – all went through successfully. The show-stopper was the ‘adding server to pool’ part.

During the ‘Add Server to Pool‘ wizard operation, the installation of the program files and some additional configuration succeeded. However, when it was time to activate the server, all hell broke loose and the operation failed.

When I opened the logs, The ‘add server to pool’ log file showed:

[0xC3EC796C] One or more errors occurred during execution of the wizard; the wizard was unable to complete successfully. Please check the log file for more information.

Drilling further down into the log, I found that the problem was while activating the server. I clicked on the link to open the Activation logs, and found the following generic error:

[0xC3EC7814] Pool is not ready.

After ironing out every logical possibility, days of searching the net, and after asking in the MVP Private newsgroups with no luck, I decided to contact Product Support.

A few hours later, the problem turned out to be remnants of the past LCS pools that were still lurking in the Active Directory. We opened up ADSIEDIT, navigated to the Domain partition –> System container –> Policies container. Over here, we found the GUID of the LCS 2005 pools and deleted them manually. Since we didn’t have any more LCS 2005 servers, we didn’t need them anyway.

Due to this, OCS 2007 Pools were not actually being created in AD, even though the wizard ran successfully. After a successful pool creation, OCS 2007 Pools should be seen in Domain partition –> System container –>  Microsoft –> Rtc Service –> Pools. However, the Pools container was apparently empty even after I created OCS 2007 pools.

Once we got rid of the LCS 2005 pool GUIDs mentioned earlier:

1. We removed the pool we created using the command lcscmd.exe /forest /action:RemovePool /poolname:<poolname> /force

2. Deleted the SQL 2005 database and log files for this pool

3. Re-created the pool from scratch starting with the ‘Create Enterprise Pool‘ wizard.

Server activation was successful and we are back in business!

OWA calendaring issue “This action cannot be performed”

by Shijaz Abdulla on 19.03.2008 at 07:17

This post discusses a common Outlook Web Access (OWA) calendaring issue reported at most forums. I could not find a satisfactory answer posted anywhere, including eventID.net, so I thought I’d share the knowledge.

A description of the problem:

When a user tries to save an appointment/calendar item or responds to a meeting request using Outlook Web Access provided by Exchange Server 2003, he/she sees the following error:

This action can’t be performed.

The user is unable to save changes to his/her calendar using OWA. Additionally, he/she may see the following error while trying to dismiss or snooze reminder popups in OWA:

One or more of your reminders cannot be snoozed or dismissed.

You will also get the errors in the event log of the Exchange server such as “Calendaring agent failed to save appointment.”

This can occur due to one or more of the following conditions:

  1. As per Microsoft KB 310440, check if the required registry keys are intact.
  2. Make sure your antivirus software is excluded from doing realtime scanning on Exchange database/log files.
  3. Open the affected user objects attributes in ADSIEDIT. Make sure that the legacyExchangeDN attribute is in order.

To elaborate on the third condition, make sure your legacyExchangeDN attribute looks something like this:

/o=OrganizationName/ou=First Administrative Group/cn=Recipients/cn=shijaz

and not:

/o=OrganizationName/ou=First Administrative Group/cn=Recipientsshijaz

(missing “/cn=” before the user alias)


If you move a mailbox with a malformed legacyExchangeDN attribute to Exchange Server 2007, the user will not receive meeting requests/updates. These will get stuck up on the queue with a 430 4.2.0 “STOREDRV.Deliver.Exception:MAPIExceptionCanNotComplete” error.

How to specify the default Address List in OWA

by Shijaz Abdulla on 31.01.2008 at 17:56

By default, Microsoft Outlook Web Access shows all address lists in Active Directory, regardless of the permissions that are set on the address list. To restrict access so that users can only view the address lists that are contained in their own OU, you can configure the msExchQueryBaseDN attribute for the OWA user.

In an Active Directory environment with a large number of users where there is a need to filter the long list to just a number of relevant recipients, this is particularly useful.

Here’s how to go about it:

  1. Open ADSIEDIT
  2. Find the user for whom you want to restrict the view and open the properties
  3. Find the msExchQueryBaseDN attribute. Enter the DN for the OU or restricted Address list you want the user to see in OWA. To enable user to see all lists, just clear the field.

To find the DN for the restricted address list you created, open ADSIEDIT and navigate to Configuration > Services > Microsoft Exchange > [Organization Name] > Address Lists container. Here is an example:

CN=My Address List,CN=All Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=MyDomain,DC=com

If you prefer to use the DN of an OU, it would look something like this:


If you want to edit msExchQueryBaseDN attribute for a large number of users (entire OU or domain), you can use the ADModify tool.

How to bulk edit an Active Directory attribute

by Shijaz Abdulla on 29.01.2008 at 18:08

Everybody knows that if you want to manually edit the value for an attribute in Active Directory, you ought to be using ADSIEDIT.

But what if you just realized that you have to modify a particular attribute for a large number of Active Directory users, if not all users? Would this mean opening up each user object in ADSIEDIT and modifying the required attribute?

Thankfully, there is the ADModify tool from Microsoft PSS that lets you bulk-edit Active directory. You simply set the filter on what users should be affected, and then specify the attribute that needs to be changed and the value to which it should be changed. You can even make the values to by typing the word null as the value.

A word of caution here – Bulk edits can be really, really painful if you do it wrong. You can seriously mess up your Active Directory if you’re not careful!

When Setup fails: Exchange Server 2007 Mailbox Server Role

by Shijaz Abdulla on 28.01.2008 at 20:14

I went ahead to install the mailbox server role on one of the brand new servers commissioned for Exchange Server 2007.

The prerequisite checks went OK, and setup began doing the ‘real stuff’. Happiness was shortlived, because, towards the end setup showed that it failed. The following error was thrown:

An unexpected error has occurred and a Watson dump is being generated: The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error. It was running command ‘$error.Clear(); $count=0; $ExchangeServers = Get-ExchangeServer -DomainController $RoleDomainController; foreach($server in $ExchangeServers) { if(($server.AdminDisplayVersion.Build -gt 641) -and ($server.IsMailboxServer -eq $true)) { $count++; } } if( $count -eq 1) { Set-OrganizationConfig -DomainController $RoleDomainController; }’.

I closed the Setup program, and tried to assess what’s been done. I could see that Exchange Management Console and Exchange Management Shell have been installed and that I could open both, but I could not edit the existing address lists or recipient policies from Exchange Management Console.

Upon further investigation, it dawned on me that Exchange Server 2007 does not use LDAP filters for recipient policies! It uses OPATH instead. How to make this change from LDAP to OPATH filters will be discussed in another post, but in order to make this change I need setup to complete successfully, otherwise I get an error that the Address List service is not responding. Now we have a deadlock situation.

We can trick Exchange 2007 setup into believing that the filter is alright by removing parenthesis “(“, “)”and ampersand “&” symbols from the filter. To do this,
  • Navigate to CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=, CN=Recipient Policies
  • You will find all your Exchange 2000/2003 recipient policies here. Open each and find the purportedSearch attribute. Click Edit to open the value. Note the original value of this field and save it in a notepad file. Then hit the Clear button to change the value to (not set).
  • Do the previous step for each recipient policy
  • Re-run Setup. You will find that setup completes successfully!

The next question is, what do I do with the original values of purportedSearch? I put them back as they were before setup, so that I can upgrade the policies to Exchange 2007 later without disturbing the current Exchange 2003 users.