Sometimes users may face problems logging in to new mailboxes created or moved in to Exchange Server 2007 when they use Outlook Web Access. Users may get error messages like the one below (abridged):

Request Url: https://webmail.company.com:443/owa/lang.owa
User host address: 192.168.x.x

Exception
Exception type: Microsoft.Exchange.Data.Storage.StoragePermanentException
Exception message: There was a problem accessing Active Directory.

Call stack
Microsoft.Exchange.Data.Storage.ExchangePrincipal.Save()
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchLanguagePostLocally(OwaContext owaContext, OwaIdentity logonIdentity, CultureInfo culture, String timeZoneKeyName, Boolean isOptimized)
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchLanguagePostRequest(OwaContext owaContext)
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.PrepareRequestWithoutSession(OwaContext owaContext, UserContextCookie userContextCookie)
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.InternalDispatchRequest(OwaContext owaContext)
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchRequest(OwaContext owaContext)
System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Inner Exception
Exception type: Microsoft.Exchange.Data.Directory.ADOperationException
Exception message: Active Directory operation failed on cs-ad-03.ad.hct.ac.ae. This error is not retriable. Additional information: Insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
…

Here are some of the things that you may want to try out when you face this kind of a problem:

• Make sure that the user object is inheriting permissions from the parent object. To do this,
• Open ADUC.
• View > Advanced features
• Right click on the user choose Properties.
• On Security tab click Advanced
• Make sure that this object inherits permissions from parent object is checked.
• Click OK
• Try running the following Exchange Management Shell cmdlet:
  Set-Mailbox "username" -ApplyMandatoryProperties
• Make sure SELF has permissions on the user account and the user mailbox.
• Make sure that there are no connectivity problems between Exchange Server and Active Directory. Also make sure that a GC is available.

By default, windows returns only a maximum of 1000 objects in response to a single LDAP query. This can be a limitation when you have more than 1000 objects in your Active Directory and you are running some kind of script that does a bulk import of objects (user accounts and/or computers) from Active Directory.

Some applications like Adobe Connect also require such bulk imports. If you find that the number of user accounts imported from Active Directory is exactly 1000 when you are sure there are more, its time to take a look at this.

The 1000-object limit is governed by the MaxPageSize LDAP administration limit, which is defined using NTDSUTIL. To increase the value:

1. Open Command Prompt on a domain controller, logged in as domain administrator.
2. Type NTDSUTIL and press ENTER.
3. In the ntdsutil: prompt, type ldap policies
4. In the ldap policy: prompt, type connections
5. In the server connections: prompt, type connect to server <FQDN of domain controller>
6. Once you are connected, type q to come back to the ldap policy: prompt.
7. If you type show values, you can see the current value for the administration limits, including the MaxPageSize limit.
8. To change the value to allow up to 30,000 objects to be returned in a single LDAP query, type set MaxPageSize to 30000
9. You can view your changes by typing Show Changes. Note that the new values appear in brackets, because you have not yet commited your changes.
10. To commit changes type commit changes

If you are using a third-party/home-grown application or script to provision user accounts and mailboxes, you can still create mailboxes by populating Active Directory attributes. The recommended way would be to use PowerShell aka Exchange Management Shell or the Exchange Management Console. However, this may not always be possible – so here’s something that I’ve tried and it works.

Please pay special attention to the disclaimer at the bottom of the page. This (and any other post) is my own view and not endorsed by Microsoft. Supportability of this method is at Microsoft’s discretion. You are on your own when it comes to risk.

The following attributes need to be populated, just like earlier versions of Exchange Server:

• HomeMTA
• HomeMDB
• legacyExchangeDN
• msExchHomeServerName

In addition, the following "mandatory attributes" need to be added. To know the values for these attributes in your environment, see the values on existing mailboxes using ADSIEDIT.

• msExchVersion
• msExchMobileMailboxFlags
• msExchRecipientDisplayType
• msExchRecipientTypeDetails

If you prefer not to add the "mandatory attributes", you can always run the following Shell command, and Exchange will do that stuff for you.

Set-Mailbox <mailboxname> -applymandatoryproperties

If you had to change the legacyExchangeDN for your users as part of a migration or other manual process, or even an error in your automated user provisioning software, there are certain things that you need to be aware of.

For one thing, cached Outlook ‘autocomplete’ entries will stop working. If a sender uses his Outlook autocomplete to select a user whose legacyExchangeDN has been recently changedand sends an email to a user, chances are that the mail will bounce with the following NDR:

Jack Rabbit
The recipient’s e-mail address was not found in the recipient’s e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.

The first thing you need to do after changing the legacyExchangeDN is to initiate an Offline Address Book rebuild. The way out of this problem is to instruct the sender to first download the Address Book by doing a full Send/Receive. Then ask the sender to manually select the affected recipient from the Address book instead of using the cached Autocomplete.

This is because, in an Exchange organization, Outlook client autocomplete caches do not save the SMTP email address. Instead, it saves the X.500 address using the legacyExchangeDN attribute from Active Directory. And that’s exactly what you have changed!

Workaround:

There is another workaround to prevent the NDRs. This would be to enter the old value of the legacyExchangeDN attribute as an X.500 address for the user account. This is done by opening the user object’s Email Address properties –> Add a Custom Address –> Enter the old value of legacyExchangeDN as the address and the address type as "X500" without the quotes. The drawback of this method is that you are populating the user’s email address field with garbage, which you don’t need after a while but can’t remove because you are unsure if traces of the old entries in Outlook caches are gone!

This is more a Microsoft Word tip rather than an Active Directory tip. In essence, it shows one of the many methods to compare values of all attributes of two different objects in Active Directory, or of the same object in a "before-after" comparison scenario – to track changes.

In this example, we will try to do a before-after analysis of a single user object to track changes that have happened to the attributes of the same user object.

First, I dump the LDF file for the user that I want to track changes for, before I make the changes using the LDIFDE tool.

LDIFDE -f user_before.ldf -d "CN=User Jones,OU=Test Users,DC=Domain,DC=local

Then, I make the changes to the attributes. In this case, I am moving the user’s mailbox from an Exchange 2003 server to an Exchange 2007 mailbox server.

Once again, I dump the LDF for the same user after I’ve done the operation.

LDIFDE -f user_after.ldf -d "CN=User Jones,OU=Test Users,DC=Domain,DC=local

Now I have two LDF files, which I want to compare. Microsoft Word has a pretty cool compare feature that shows you what exactly has changed in red. Also, you get to see both the files in two small windows and the changes in a separate window, and they all scroll together!

Simply open (or paste) the two files in Microsoft Word as separate documents. Then, open up the Review toolbar tab, and choose the Compare option.

Here’s a screenshot.

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:

Failure
[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:

Failure
[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!

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)

Observation:

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.

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:

OU=Department,OU=Division,DC=MyDomain,DC=com

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

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!

Here are a few things to check in your Active Directory before you co-exist Exchange Server 2007 in a Exchange Server 2003 environment.

• For all your Exchange users and groups, make sure Exchange mailbox alias field does not contain spaces or characters other than a to z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, , } or ~. One or more periods may be embedded in an alias, but each one of them should be preceded and followed by at least one of the other characters. The @ symbol is not allowed in an alias.
• For all your Exchange users, make sure the UserPrincipalName (aka Logon name) is “user@domain.com” and not just “user”. I have seent that this problem is usually found on users that are created in Active Directory by Cisco Unity.
• Make sure your display names do not contain leading or trailing white spaces, i.e. the first and last characters in a display name cannot be a white space.

Usually these kind of problems are found in large environments where user provisioning is automated by a third party application or script. If any of the above conditions apply, Exchange Management Console (or get-recipient shell command) will warn you of inconsistent Active Directory objects.