Exchange Server 2010 SP1 Beta incorporates a number of feature updates including archiving and discovery enhancements, a faster Outlook Web App (OWA), upgraded mobility features, and several improvements in the management UI. The SP1 beta is available to the public and can be downloaded today.

Recently, Exchange Server 2007 Service Pack 3 was also made available to customers in 11 languages for both 32 and 64 bit. As highlighted in the recent post on the Exchange Server Team Blog,  this service pack was created in response to strong customer demand for Windows Server 2008 R2 supportability for Exchange Server 2007. In addition to the newly supported OS, this service pack also provides updates to a number of core components and the reintroduction of the password reset functionality within OWA for customers using Windows Server 2008 and Windows Server 2008 R2.

Outlook Web Access in Exchange Server 2010 offers integrated instant messaging capability right from the browser.

Check this out:

You also see presence information against each contact in an email header.

You can also change your status from the top right corner of the OWA page:

Outlook Web Access is not currently available for the user mailbox that you are trying to access. If the problem continues, contact technical support for your organization and tell them the following: The Microsoft Exchange Client Access server that is proxying the Outlook Web Access requests is running an older version of Microsoft Exchange than the Client Access server in the mailbox Active Directory site.

If you have set up Exchange Server 2007 Client Access Servers in a CAS-CAS Proxy scenario, where the CAS server in the main site is exposed to the internet and the CAS servers in other remote locations depend on the internet-exposed CAS to proxy requests to them, users in the remote site may get the above error when they try to access their mailboxes via Outlook Web Access.

The cause is very simple. The Client Access Server in the remote site may have the latest Update Rollup for Exchange 2007 installed on it, while Client Access Server in the main site is still having an older Update Rollup.

I noticed this problem when the Client Access Server in the main site is running with Update Rollup 3, while the remote site has already got Update Rollup 4 installed.  A quick install of the latest Update Rollup on all servers solved the problem.

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.

If you are running Exchange 2003 and Exchange 2007 in co-existence and you have users on both systems, you will notice that, while Exchange 2007′s new OWA interface has a brand new Change Password option, the Change Password functionality for the users on Exchange 2003 has stopped working and you receive a 404 – File Not Found error.

This is because the IISADMPWD virtual directory, which was previously available on your Exchange 2003 Front-End server is no longer present on your Client Access Server. So here’s the solution:

1. If you are running Exchange Server 2007 on Windows Server 2003:

Simply enable the IISADMPWD virtual directory by following this article.

2. If you are running Exchange Server 2007 SP1 on Windows Server 2008

Things can get a little tricky here. Especially when you’ve noticed that there is no IISADMPWD folder inside the \Windows\System32\Inetsrv folder! Now what are we gonna do?! Here’s something that I’ve tried and it works:

a. Simply copy the \Windows\System32\InetSrv\IISADMPWD folder from your Exchange 2003 Front End server and copy it to \Windows\System32\InetSrv\ folder on your Windows 2008 Exchange Client Access Server.

b. Open IIS Manager. Right click on Default Web site and choose Add Virtual Directory. Specify the alias as IISADMPWD and browse to the path of the \Windows\System32\InetSrv\IISADMPWD folder.

c. Right click on the IISADMPWD virtual directory, and select the option Convert to Application.

d. Click on IISADMPWD application to select it. On the right pane, open the Authentication icon. Disable Anonymous authentication and enable Basic Authentication. Make sure only Basic Authentication is enabled.

e. Restart IIS service by using the command iisreset /noforce

Your Exchange 2003 users should now be able to change their passwords.

If you have two separate Exchange Server 2007 mailbox servers, and users in one mailbox server can login to Outlook Web Access using your Client Access Server, while the users on the second mailbox server cannot log in to Outlook Web Access using the same Client Access Servers, the following might help.

This issue is seen if the mailbox server is running Exchange Server 2007 SP1 on Windows Server 2008. From Server Manager, open Web Server (IIS). Make sure the following Role services are added:

Under Application Development, select the following:

• ASP.NET
• .Net Extensibility
• ASP
• ISAPI Extensions
• ISAPI Filters
• Server Side Includes
• .NET environment

Under Security, select the following:

• Basic authentication
• Windows Authentication

Do an IISRESET /noforce.

You should be able to login now. If you can’t try logging in using the domain\username format, even if you chose the option for ‘user name only’ on your Client Access Server. If you are able to log in with domain\username and not just username, and you have enabled ‘username’ only option under Forms based Authentication on your Client Access Servers, try the following.

On the IIS of your Exchange Server 2007 mailbox server, navigate to the /exchange virtual directory, open Authentication, and change the properties for Basic Authentication and enter a "\" without the quotes for the Default Domain.

In an earlier post, I explained how you can use Outlook Web Access (OWA) hosted on Exchange 2007 CAS Servers for accessing Exchange 2003 mailboxes in a co-existence environment by using the /exchange virtual directory.

Exchange Server 2007 CAS Servers come with Forms Based Authentication enabled by default. Now, if you wanted to disable the forms based authentication (required if you want to publish using ISA Sever 2006 Forms based authentication), OWA would still work fine internally (i.e. https://servername/exchange or /owa), as long as you choose Basic Authentication. The user will be presented with a popup password window instead of the form.

Now, what if you didn’t want users who are already logged in to the domain to be prompted for their password. The answer sounds simple – enable Integrated authentication, right?

Well, no. If you are co-existing Exchange 2003 and Exchange 2007 mailboxes and if your users have mailboxes on Exchange 2003 backend servers, and if they try to login via a CAS server using https://servername/exchange, they will receive an HTTP 404 Page not found message.

This is because ‘/exchange’ on the CAS is an Exchange 2003 virtual directory. Exchange 2007 supports Integrated Authentication only on Exchange 2007 virtual directories (see this article).

So the moral of the story is that you cannot enable Integrated Authentication on the CAS Server for the /exchange folder in an Exchange 2007 co-existence scenario. Exchange 2007 users can use Integrated authentication only if they use /owa virtual directory for accessing OWA.

While trying to open Outlook Web Access hosted on an Exchange Server 2007 Client Access Server, I get an error stating that Outlook Web Access could not connect to Active Directory, followed by a detailed stack trace:

Request Url: https://owaURL/owa/forms/premium/DirectoryView.aspx?ae=AddressList&t=Recipients&a=
User host address:
User: someone
EX Address: /o=MYORG/ou=MYOU/cn=RECIPIENTS/cn=SOMEONE
SMTP Address: someone@mydomain.com
OWA version: 8.0.685.24
Mailbox server: mail.mydomain.com


My initial search fetched a Microsoft KB article 919166, which deals with exactly the same problem. However, unlike the conditions mentioned in the article, the locale on my domain controller and Exchange servers are the same and my domain controller has Windows Server 2003 Service Pack 2 which supersedes the mentioned hotfix.

So I called Microsoft, and it turned out to be related more to KB886683 while OWA is querying the Global Catalog. To fix the problem:

1. Open ADSIEDIT.
2. Navigate to CN=Configuration, CN=Services, CN=Windows NT, CN=Directory Service
3. Right click on CN=Directory Service and choose Properties.
4. Edit the multi-valued attribute msDS-Other-Settings
5. If you see a string value DisableVLVSupport=1, remove it and change it to DisableVLVSupport=0 and add it back. Click OK all the way out.

Replicate the changes across all your domain controllers. You should now be able to open your address book.

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.