How to specify the default Address List in OWA

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.

Upgrading address lists created in Exchange Server 2003

EHLO again.

Hope you enjoyed my previous post that explains how to upgrade Exchange 2003 recipient policies for use with Exchange Server 2007.

This post deals with the “art and science” of upgrading Exchange 2003 Address Lists to its Exchange Server 2007 form. I say “art and science” because it can be a little tricky to understand for those who havent worked much on Powershell or any scripting/coding environment.

If you click on an address list created by Exchange 2003 in the Exchange Management Console, you will receive the following error:

Unable to edit the specified E-mail address policy. E-mail address policies created with legacy versions of exchange must be upgraded using the ‘Set-EmailAddressPolicy’ task, with the Exchange 2007 Recipient Filter specified. specified.

Exchange 2003 Address Lists have a recipient filter that is made up of an LDAP filter. Exchange Server 2007, on the other hand, understands only OPATH filters. The trick is to convert the LDAP filter to an OPATH filter, and this needs to be done manually.

I’m going to explain this with the help of an example. Lets open an Address List in Exchange 2003 System Manager and examine the LDAP filter:

(& (& (& (mailnickname=*) ( (& (objectCategory=person) (objectClass=user) (homeMDB=CN=Mega MailStore (EXCH01),CN=SG01,CN=InformationStore,CN=EXCH01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com) ) ) ) ))

To refresh our brains, this LDAP filter basically creates an Address list out of all users that have a mailbox in the ‘Mega MailStore’ mailbox store on EXCH01 server.

Before we convert this LDAP to OPATH, lets write this in a better way:

(&
(&
(&
(mailnickname=*)
( (&
(objectCategory=person)
(objectClass=user)
(homeMDB=CN=Mega MailStore (EXCH01),CN=SG01,CN=InformationStore,CN=EXCH01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com)
) )
)
)
)

Now, carefully change all ampersands (&) to an -and. The ampersands are placed in a prefix fashion in LDAP filter, but in OPATH, its much simpler – you place -and between the two parameters. Similarly, change all equal signs (=) to -eq.

(RecipientType -eq ‘UserMailbox’)
-and
(Database -eq ‘CN=Mega MailStore (EXCH01),CN=SG01,CN=InformationStore,CN=EXCH01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com’)

Notice that I have also replaced the property ‘homeMDB’ with ‘Database’. This kind of change is required to convert LDAP property names to OPATH. You can get a complete list of properties here.

So, I arrive at my full command:

Set-AddressList “Mega users” -RecipientFilter { (RecipientType -eq ‘UserMailbox’) -and (Database -eq ‘CN=Mega MailStore (EXCH01),CN=SG01,CN=InformationStore,CN=EXCH01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=mydomain,DC=com’) }

The guys at Microsoft Exchange Team have more to say about conversion from LDAP to OPATH, and is worth a peek.

Upgrading recipient policies created in Exchange 2003

After installing Exchange Server 2007 Mailbox server into an Exchange Server 2003 organization, you open Exchange Management Console and navigate to Organization Configuration > Hub Transport > Email Address Policies.

You find all the legacy recipient policies that you created in Exchange 2003 over here, but when you try to edit a recipient policy, you get the following error:

Unable to edit the specified E-mail address policy. E-mail address policies created with legacy versions of Exchange must be upgraded using the ‘Set-EmailAddressPolicy’ task, with the Exchange 2007 Recipient Filter specified.

So just how do you fix your email address policy? Yup, you will need to use Exchange Management Shell, no matter how much you hate it.

First, lets fix the Default policy using the Set-EmailAddressPolicy cmdlet:

Hit ‘Y’ when you are asked to confirm the upgrade.
If you have additional recipient policies, you need to upgrade them as required. One important thing to remember is that, in Exchange 2007, you can specify only from the following ‘filter’ fields, as far as email address policies (recipient policies) are concerned:

• Department
• Company
• CustomAttribute1, CustomAttribute2, … , CustomAttribute15

In Exchange 2003, it was possible to define recipient policies from complex LDAP queries, but I see that kind of flexibility is unavailable in Exchange Server 2007. For instance, in Exchange Server 2003, you could create a recipient policy for all users who have mailboxes in a particular mailbox store.

Anyways, lets upgrade our policy using one of the available tactics – lets say – based on Department. If I have an Exchange 2003 recipient policy that gives all users from the sales department email addresses of the form @sales.mydomain.com, my Set-EmailAddressPolicy command would look like this:

Set-EmailAddressPolicy “Sales Dept Recipient Policy” -ConditionalDepartment ‘Sales’ -IncludedRecipients AllRecipients

Note that I do not need to specify the email address format for upgrading the recipient policy.

When Setup fails: Exchange Server 2007 Mailbox Server Role

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

Never store PST files on network shares!

OWA for Exchange 2003 mailboxes via Exchange 2007 Client Access Server

If you are planning on co-existing Exchange Server 2003 backend servers alongside Exchange Server 2007 mailbox servers, you will have the following question lingering in your mind:

But what about Outlook Web Access?

If some of your users have mailboxes on Exchange Server 2003 while others have mailboxes on Exchange Server 2007, and you publish your OWA URL as http://webmail.mycompany/owa, you will notice that Exchange 2003 users get the following error:

Outlook Web Access could not find a mailbox for DOMAIN\USER. If the problem continues, contact technical support for your organization and tell them the following: The mailbox may be stored on a Microsoft Exchange 2000 or Microsoft Exchange 2003 server, or the Active Directory user account was created recently and has not yet replicated to the Active Directory site where this Client Access server is hosted.

The solution is to use the URL http://webmail.mycompany/exchange on the Client Access server. The ‘/exchange’ virtual directory on the Client Access server is able to proxy OWA requests for Exchange 2003 mailboxes to the appropriate Exchange 2003 back end server and the user sees the Exchange 2003 OWA experience. The ‘/exchange’ virtual directory will also automatically redirect OWA requests for Exchange 2007 mailboxes to the ‘/owa’ virtual directory.

For more information, see this post on the Exchange Team blog.

SCVMM: Test lab built

I have finally completed building the servers required for my Exchange 2007 test lab. I have used Microsoft System Center Virtual Machine Manager (SCVMM) for virtualizing the lab environment. For the purposes of testing I will have a total of 10 guest machines running on my SCVMM host. The machines include 2 domain controllers, 2 Exchange 2003 back ends, 2 Exchange 2003 front ends, Exchange 2007 servers (1 hub transport, 1 edge transport, 1 mailbox and 1 CAS).

For easy management of the VMs, I installed the SCVMM Administrator Console on my Windows Vista notebook.

I’m all set to test, validate, and abuse my test lab servers as I wish! [*devilish laugh*]

Transitioning to Exchange Server 2007!

The organization that I work for has decided thats it’s time to upgrade to Exchange Server 2007. With approximately 18,000 Exchange mailboxes scattered across one four-node active-active-active-passive cluster and five two-node active-passive clusters spanning six geographic locations, this is going to be a mammoth task, nevertheless exciting!

The project will religiously adhere to the Microsoft Solutions Framework (MSF). Preparation is key to success. One of the most crucial stages is the testing. I’m doing the testing on a virtualized environment. More specifically, System Center Virtual Machine Manager 2007. The virtualization software is Virtual Server 2005 R2. The host is machine is a Windows 2003 x64 box with 16 GB RAM.

The virtualized environment will consist of two domain controllers, two Exchange 2003 backends, two front ends, an Exchange 2007 CAS server, a mailbox server, a hub transport server, and an edge server.

More on my adventures with this massive implementation will follow.

Disabled users continue to receive mail in Exchange 2003 SP2

In the RTM version of Exchange 2003, if you disable an active directory user account, mail flow to the disabled user’s mailbox stops. To a sender, it is as though the mailbox doesn’t exist.

With service packs, this behaviour has been changed. Hotfixes 916783 and 903158 make changes to the store.exe as follows:

If the SELF SID is missing from the Mailbox permissions, store.exe checks to see if the msExchMasterAccountSID is populated (this is the same as before). If it is not populated, then store.exe will use the objectSID of the user account, which should always be present.

This is good news for some administrators and bad news for others.

The good news is that if you want to temporarily restrict a user from accessing his mailbox but do not want him to lose out on receiving important e-mail, this is now possible. Also, if an employee leaves the company and you would like to configure an Out of Office message stating that he is no longer working there and at the same time disable the account for security purposes, this is now possible.

The bad news is that the above is not good enough for some companies. They just want to disable the account and forget about it. In such cases, administrators can adjust the delivery restrictions for the disabled user and configure that the user receive mails *only from* his own account. Or, you can configure ‘prohibit send/receive’ at 0 KB. Or, you can simple change or remove the SMTP email address of the user.

The day the Exchange cluster died

I installed Windows Server 2003 Service Pack 2 on a client’s Exchange Server 2003 cluster on Thursday night (Yeah, I hear you – what a way to spend a weekend!). Everything went well, installation completed, rebooted and everything was happy and kicking.

…until on Friday morning when the Exchange HTTP Virtual Server Instance failed. Since this resource was configured to ‘affect the group’, the failure forced a failover of the whole Exchange cluster group to the passive node.

Within no time, Exchange HTTP Virtual Server Instance failed again, this time on the passive node! Someone press the Panic button!! The initial understanding of the situation was clear – Installation of Windows Server 2003 Service Pack 2 brought the mighty Exchange cluster to its knees.

I rebooted both nodes and normal operation ensued. But after a couple of hours it happened again. In the event logs, I could see things like:

Event Type: Warning
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1115
Description:
Error 0xfffffbbe returned from closing database table, called from function JTAB_BASE::EcCloseTable on table DeletedFolders. For more information, click http://www.microsoft.com/contentredirect.asp.

Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services
Event ID: 1005
Description: Exchange HTTP Virtual Server Instance 100 (servername): The IsAlive check for this resource failed. For more information, click http://www.microsoft.com/contentredirect.asp.

Event Type: Error
Event Source: Srv
Event Category: None
Event ID: 2019
Description: The server was unable to allocate from the system nonpaged pool because the pool was empty. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

I couldn’t find much on these errors on the Internet, and this is the reason for this post. Here’s what the problem is.

My client is running Windows Server 2003 on a 32 bit server. 32-bit versions of Windows, as we all know, support a maximum of 4 GB RAM. By default, Windows slices the total memory right down the middle: 2 GB is reserved for the OS and 2 GB for the applications. Out of the 2 GB reserved for the OS, 256 MB is reserved for non-paged pool memory.

My client is using the /3GB switch, which forces Windows to limit itself to 1 GB RAM and let the applications use 3 GB. But this causes the non-paged pool memory reservation to be reduced to 128MB instead of 256MB.

Now, 128 MB is a tight little space. IIS uses non paged pool memory for processing requests. On Windows Server 2003 and Windows Vista, IIS stops processing requests once the available non-paged pool memory goes below 20 MB. Event 2019 is evidence for that.

Of course you know, Exchange relies heavily on IIS. So that explains why the Exchange HTTP Virtual Server resource went down! But wait – what’s hogging up the non-paged pool memory? And how do we fix this?

That’s when Microsoft sent in their Poolmon utility, that grabs information on whats in there. The culprit? – Broadcom’s NetXtreme II network card driver! It was incompatible with scalable networking features bundled with Windows Server 2003 SP2 (and the Windows Scalable Networking Pack) and caused a memory leak! I disabled the TCP Chimney with the following command:

Netsh int ip set chimney DISABLED

I also disabled the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA registry value setting by it to zero on both nodes and other steps mentioned in KB936594. That was all it took to solve the problem!

See my earlier related post: Delayed Logins: Change Password feature in ISA 2006