Dgoldman's WebLog

Microsoft Exchange and Search Folders

The Exchange search folders tend to be a very complicated subject for a lot of administrators. There are two different ways of filtering messages in MAPI - (Search folders and restrictions).

• A search folder is like a regular MAPI folder, except that instead of containing real messages, it contains only links to messages in other folders which meet some specified restriction.  A search folder is created by calling IMAPIFolder::CreateFolder with a folder type of FOLDER_SEARCH, followed by a call to IMAPIContainer::SetSearchCriteria to specify the search restriction and search domain.  The search domain may be an arbitrary set of folders in the same store, and may be recursive, so that messages in any sub-folder of the specified domain folders are also searched.
• A “restriction” is formed by calling IMAPITable::Restrict on a MAPI Table.  The resulting table shows only the items which match the restriction specified in the Restrict call.  A restricted contents table can show only messages from a single folder.  This usage sometimes causes confusion with the MAPI-defined structure which describes the filter criteria for a search folder, which we also call a restriction.

Now when a client (any application with search capabilities) sets up a restriction on a contents table object (which is known as a VMSG – View Message Object), we will create a hidden search folder which searches the original folder, and will point the VMSG at the search folder. Clients have no knowledge that this has occurred, and will only that some of the messages have disappeared from the table. This is not a fast process because even a restriction on a small table requires that we create a new folder row and a new message folder table in Jet. Creating tables via Jet will cause us to log transactions because we are creating objects. Excessive logging can lead to complications and 623’s (Version Store Out Of Memory). For more information on Version Store please see this blog: "Troubleshooting Version Store issues - JET_errVersionStoreOutOfMemory". In addition to that blog I also reviewed an article that we wrote and we blogged about it on the Exchange Blog site: "Version Store issues revisited - Event ID 623 at Information Store service startup".

Now there are two types of search folders (Temporary and Permanent) that can get created.  When you create a hidden search folder this is actually a “permanent” part of the database, it can be reused later when someone performs the same restriction. Search folders are very much like regular folders. Each search folder has a single row in the folders table. Instead of a message folder table, there is a search table with a name like “S-1-4309”. The S denotes that this is a search folder and the following [1-4309] is the FID of the search folder.

Search tables will contain a subset of message folder tables that have columns.  Ideally you want to have only a few columns and each row should be just a pointer to the “real” message in another folder.

Search folders can be created by a number of applications like Outlook, or any 3rd party application that issues searches for messages in an information store. The problem starts to manifest itself when a lot of search folders are created and never deleted by the application that creates them.

Having a ton of search folders will impact an exchange servers performance. When messages are created, modified, or deleted, all of the search folders linked will be updated immediately, within the same transaction as the original message operation. Since all search folders are updated in one big transaction, all search folders need to be locked before the transaction begins. When the exchange server starts to process batches of transactions it will begin to use up the stores Version Store cache to process these transactions.

There is a way that this can be controlled to a small extent and you can age out the views. For more information please see this article: How to Temporarily Delete Existing Search Folders.

I have also written a tool that will allow you to take an isinteg.pri file and search through it to look for users that have a very high amount of search folders.

Download to be posted soon

Here is what the output looks like:

**********************************************************
Find Search Folders
Dave Goldman - Exchange Escalations Services
Purpose: Find the highest search folder offenders
Time: 05/14/08 18:04:58
**********************************************************

Isinteg is from server name: server.company.com

Folder FID=0001-000000DF1A28
Parent FID=0001-0000004F959B
Search Fids found: 1
Folder FID=0001-000000DF77E0
Parent FID=0001-000000DF88C8
Search Fids found: 12
Folder FID=0001-000000DF77E1
Parent FID=0001-000000DF88C8
Search Fids found: 222 <- Denotes that there are a lot of search folders :)
Highest number of search folders found: 222
Highest offender is: Folder FID=0001-000000DF77E1
Parent Folder: Parent FID=0001-000000DF88C8
Total folders that do not contain search folders: 3822
Who has the highest search folder count in an isinteg dump

**********************************************************

1. Take the highest offenders Parent FID and search the isinteg.pri file for this..
2. Look in the ESM and match these items counts and you should have your offending mailbox.

c:\isinteg.pri closed.

3.  Searching for the following fid's takes me to objects that look like this with a massive amount of items in the inbox.

4. From here I can look in the ESM (Exchange System Manager) to match up the number of items and I have the user who keeps taking down the exchange server!

[2544] Folder FID=0001-000000DF77E1
       Parent FID=0001-000000DF88C8
       Root FID=0001-000000DF88C7
       Folder Type=1
       Msg Count=118,257
       Msgs Unread=101,783
       Msgs Submitted=0
       Rcv Count=0
       Subfolders=0
       Name=Contacts
       Comment=
       Restriction=
       Search FIDs=0001-000000E0EDB5,0001-000000E0EDB8,0001-000000E35105,0001-000000E35106,0001-000000E35109,0001-000000E3C29C,0001-000000E3C29D,0001-000000E3C29E,0001-000000E3C2A1,0001-000000E3C2A4,0001-000000E3C2CC,0001-000000E3C2CD,0001-000000E3E61A,0001-000000E3E61B,0001-000000E3E61C,0001-000000E3E62E,0001-000000E3E65D,0001-000000E3E693,0001-000000E40831,0001-000000E40832,0001-000000E40869

... Removed to save space ...

       Scope FIDs(search folder only)=
       Recursive FIDs=
       Search Backlinks=0001-000000E0EDB5,0001-000000E0EDB8,0001-000000E35105,0001-000000E35106,0001-000000E35109,0001-000000E3C29C,0001-000000E3C29D,0001-000000E3C29E,0001-000000E3C2A1,0001-000000E3C2A4,0001-000000E3C2CC,0001-000000E3C2CD,0001-000000E3E61A,0001-000000E3E61B,0001-000000E3E61C,0001-000000E3E62E,0001-000000E3E65D,0001-000000E3E693,0001-000000E40831,0001-000000E40832,0001-000000E40869,0001-000000E40894,0001-000000E40895,0001-000000E40896,0001-000000E40897,0001-000000E41E88,0001-000000E41E89

... Removed to save space ... 

Dave

OAB generation on a CCR cluster will fail with error 1021

OAB generation on a CCR cluster will fail with error 1021

There was a new bug found that stops the OAB from being generated with a 1021 while being hosted on a cluster server.

The typical setup has been 1 CCR running on windows 2008 and 1 to multiple Client Access Servers running on Windows 2008.

When you try to update OAB on the CAS server it will fail with error code 1021. This is what the application log event looks like:

Log Name: Application
Source: MSExchangeFDS
Date: 6/15/2008 3:16:36 PM
Event ID: 1021
Category: General
Level: Warning
User: N/A
Computer: OAB-Server
Description:
Process MSExchangeFDS.exe (PID=1232). Could not find directory \\OAB-Server\ExchangeOAB\238ag23-f2ab-305w-9fc3-52323c7cbab3. This is normal if the directory has never been generated. Otherwise, make sure this directory and share has read permission for the "Exchange Servers" group.

When we check the OAB folder on the Client Access Server it is empty.

What's broken
The under lying problem stems from a missed case in the Windows 2008 clustering code. With Windows 2008 clustering a file share is specific to either the Node name or one of the cluster name objects that it hosts. In this case if the share is shared by the node name it cannot be accessed by the CMS name.

The OAB generation process *will* succeed in generating the OAB on a CCR cluster running on Windows 2008, however it cannot be copied by the CAS therefor clients will not be able to download the OAB and the OAB directory will be empty.

Workaround until the fix is out
The workaround for now is to manually copy the OAB files to the CAS server file share so clients can access them. This is the same thing that FDS will do when it received a DS Status Notification that the OAB has been generated.

Dave

Changing the display name of active directory users

Some companies have requirements to change how their users display name show up in the active directory. We have a KB article [http://support.microsoft.com/default.aspx/kb/250455] where this does work for the following versions of Exchange:

• Microsoft Exchange Server 2003 Enterprise Edition
• Microsoft Exchange Server 2003 Standard Edition
• Microsoft Exchange 2000 Server Standard Edition
• Microsoft Windows Small Business Server 2003 Premium Edition
• Microsoft Windows Small Business Server 2003 Standard Edition

When a new user or contact object is created in Active Directory, the Full name field is always generated in FirstName LastName format. In turn, this field sets the Display Name field on creation, therefore, you end up with a FirstName LastName formatted global address list.

If you want, you can use an Active Directory editor such as Active Directory Service Interfaces (ADSI) Edit to modify the way in which the Display Name field is built. ADSI Edit not only changes the way this field is built, but also the Full Name field; therefore, users appear in the chosen format viewed within Active Directory Users and Computers.

We can change the way in which Display Name field or Full Name field are built by setting the value of the createDialog attribute of the CN=user-Display object under CN=DisplaySpecifiers, CN=409 object, where 409 is the Locale ID for U.S. English. If you are in a multi-lingual environment, you may need to make changes to the other codes.

For example, we can set the value of the createDialog attribute to %<sn>, %<givenName> to allow the Display Name and Full Name to be generated in the format of LastName, FirstName. For the detail information about how to do so, please click the link below to view the article at Microsoft TechNet:

Default display name modified: http://technet.microsoft.com/en-us/library/aa998290.aspx

On Windows Server 2003 with Exchange Server 2007 installed, when we create new mailbox in Exchange Management Console we can choose to create the mailbox for a new user, which allows us to create a new Active Directory user account directly from Exchange Management Console.

While Active Directory user accounts created from Active Directory Users and Computers appear in the expected format for Display Name and Full Name, Active Directory user accounts created from Exchange Management Console are not affected by the value of the createDialog attribute. The Display Name and Full Name are always generated in the default FirstName LastName format no matter what value you set for the createDialog attribute.

Now when it comes to Exchange 2007 this will not work. This is a by design limitation because  the Exchange Server 2007 Exchange Management Console does not recognize the value of the createDialog attribute of objects that have a displaySpecifier class.

How to work around this problem

As a work around you can create your Active Directory user accounts using the Active Directory Users and Computers mmc instead of the Exchange Management Console. Then, when you want to create mailbox you can choose the "Existing user" option to generate mailbox for the user account.

Dave

ISA Delegation breaks OAB downloads

We have had a few cases where customers were not able to download their OAB files externally due to mis-configurations on their ISA servers. By default an Exchange 2007 server's OAB Virtual Directory will have the following authentication method set:

ExternalAuthenticationMethods : {WindowsIntegrated}

Integrated Windows authentication uses the NTLM, Kerberos, and Negotiate authentication mechanisms. These are secure forms of authentication because the user name and password are hashed before being sent across the network.

ISA has a very cool feature called Authentication Delegation. By using this feature the ISA Server will forward the client's request to the Outlook Web Access server, and authenticates itself to the Outlook Web Access server using the client's credentials. The Outlook Web Access server will revalidate those credentials, typically using the same authentication provider.

NOTE: The Web server must be configured to use the authentication scheme that matches the delegation method used by ISA Server.

ISA Server has the following Authentication Delegation methods. After ISA validates the credentials, you can configure publishing rules to use one of the following methods to delegate the credentials to the published servers:

• No delegation, and client cannot authenticate directly
• No delegation, but client may authenticate directly
• Basic
• NTLM
• NTLM/Kerberos (Negotiate)
• SecurID
• Kerberos constrained delegation

If you are not careful and setup your delegation rules incorrectly they will not match your web server, specifically the OAB Virtual Directory you will fail to download the OAB. If you check your ISA Server you will see the following ISA Event ID:

Event ID: 21314
ISA Server tried to delegate credentials, but the Web site does not accept the credentials provided by the authentication delegation scheme configured in the Web publishing rule PUB: E2007 Outlook Anywhere. Verify that the credentials delegation scheme configured in the Web publishing rule matches an authentication protocol enabled on the published Web site.

How To Fix

1. Make sure your ISA delegation rules match your OAB Virtual directories ExternalAuthenticationMethods.

Dave

How to forward to Internet recipients without creating an internal mail-enabled contact

I often work with the HMC hosting team when weird OAB generation problems come about. This request was a bit different that normal. There was a hosting customer out there that wanted to be able to forward emails to another account that were not in their hosting domain but did not want to create a mail-enabled contact to get this to work.

For common knowledge we know recipient policies are using for incoming email routing, amongst other things. For Exchange 2003, if you use the ESM and go to the Exchange General Tab and select delivery options you can specify an alternate recipient. If you do this it will set the altRecipient attribute on the user and populate the DN of that object specified. When we send an email we will bind to that DN and read the necessary attributes off of the altRecipient account so we can send the email outbound.

Trying to set the fowardingAddress (which is not supported) will not work. Most people set the prefix of a proxy address which is not correct. See below for an example:

fowardingAddress = must also contain the DN of an object, not the suffix like SMTP:dgoldman@microsoft.com. This is not supported nor will work

targetAddress = must also contain the DN and so forth.

With all of this testing Fauzia Awan from the HMC team was able to come up with a solution to this problem.

All those folks using Exchange 2003 out there who do not want to make mail enabled contact for each external recipient that you want to set as forwarding address on  a user’s mailbox.. this might come in handy:

This assumes you already have an Internet SMTP connector with SMTP address space space *

1. In Exchange System Manger  Select Allow Automatic forward  checkbox on Global Settings->Internet Message Format ->Default->Properties>Advanced

2. Using ADSI Edit connect to Schema and then navigate to Schema attribute ms-Exch-Forwarding-Address properties and set isMemberOfPartialAttributeSet to True

3. Now using ADSiEdit set forwardingAddress attribute on mailbox user’s properties to the external recipient address to which you want the mail forwarded (for example johndoe@hotmail.com)

I want to thank Fauzia Awan and Mohammed Qassim from the HMC team for coming up with this workaround for everybody!!

Dave

How to prepare your organization for Exchange 2007 Address List Segregation

Before you can start to follow the white paper for Exchange 2007 Address List Segregation (http://technet.microsoft.com/en-us/exchange/bb936719.aspx) you must prepare your organization. Here is a small check list of things that need to be looked at before you start:

1. Have you followed any other KB articles or white papers to set up self hosting?

If the answer is yes to this you will need to undo everything you did so you can put your Exchange organization back to a normal state. If you do not do this and you try to follow the Exchange 2007 Address List Segregation white paper you will find that you will have mixed results and this will most likely result in a support call.

2. Have you changed any of the default permissions on the address list or global address lists?

If the answer is yes you will also need to revert these back to the installation defaults.

The way you can go about doing this is to use a tool called DSACLS. Dsacls.exe tool (Dsacls.exe) can be used to manage access control lists (ACLs) for directory services in Microsoft Windows Server 2003 and Microsoft Windows 2000 Server.

Dsacls.exe is included with the Windows Support Tools. To install the Support Tools, run Setup.exe from the Support\Tools folder on the Windows Server 2003 or Windows 2000 Server CD-ROM.

Dsacls.exe is a command-line tool that you can use to query the security attributes and to change permissions and security attributes of Active Directory objects. It is the command-line equivalent of the Security tab in the Windows Active Directory snap-in tools such as Active Directory Users and Computers and Active Directory Sites and Services.

WARNING: Changing the permissions from the default installed settings can cause your Exchange Organization to become un-useable.

If you have broken permissions or have added a Deny and you can no longer see an object you will need grant your admin account rights using DSACLS.

Example: DSACLS "CN=All Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" /N /G domain\administrator:RP 

By using the /N switch you are replacing the current access on the object instead of editing it.
By using the /G switch you are granting specified group (or user) specified permissions.

From here you will be able to view this object in ADSIEdit with your administrator account. This will allow you to check inheritance back and or add any other groups. It is recommended that you run the following to replace all of the permissions from the schema setting the object back to the default settings:

DSACLS "CN=All Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com" /S /N

This will need to be done for the following containers in order to reset the permissions:

• CN=CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com
• CN=All Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com
• CN=All Globlal Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com
• CN=Offline Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com

You might additionally need to reset the permissions for these containers as well

• CN=Addressing,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com
• CN=Address-Templates,CN=Addressing,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com
• CN=Address-Types,CN=Addressing,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com
• CN=Display-Templates,CN=Addressing,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com

Once you have reset the following containers all objects should have the following permissions:

CN=Address Lists Container and CN=Offline Address Lists Container
Authenticated Users: Special Permissions: List Contents

CN=Default Global Address List Permissions
Authenticated Users: Read and Open Address List

All Global Address List permissions should be as followed:

Authenticate Users Allow Aces - "Read", "Open Address List", "List Contents"
Exchange Servers Allow Aces - "Read", "Open Address List"
SYSTEM Allow Aces - "Read", 'Write", "Create All Child Objects", "Delete All Child Objects", "Open Address List"

If you are using Exchange 2007 you can use the Exchange 2007 Scripting Console.

1. First you need to set the container by typing the following: $container = "CN=Default Global Address List,CN=All Global Address Lists,CN=Address Lists Container,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=company,DC=com"

2. You need to add the access rights for the Authenticated Users by running the following command: Add-ADPermission $container -User "Authenticated Users" -AccessRights GenericRead, ListChildren -ExtendedRights Open-Address-Book

Once you run this command you will see the following output listed below:

Identity                   User                            Deny  Rights
\Default Global A... Domain\Authenticated  Users False Open-Address-Book
\Default Global A... Domain\Authenticated  False ReadProperty
\Default Global A... Domain\Authenticated  False ListObject, GenericExecute
\Default Global A... Domain\Authenticated  False ListChildren

Once this has been done you then should be read to follow the white paper to begin segregating your company.

Dave

Paged searches against Address Book in OWA lite not retaining DC session information during PageNext Operations

A while back I checked in a bug for fix that was affecting OWA lite clients. Basically the problem was that OWA lite clients could not search the Address book and return more than 1 page of results. When a user clicked the PageNext button it would cause an exception because the Session DC information was not retained between PageNext operations.

NOTE: This does not occur in the premium version of the OWA client

Once the exception is thrown you will see the following error in OWA:

Exception
Exception type:
Microsoft.Exchange.Data.Directory.ADPossibleOperationException
Exception message: Active Directory operation failed on daisy.butler.edu. This error could have been caused by user input or by the Active Directory server being unavailable. Please retry at a later time. Additional information: Active Directory rejected paged search cookie because a cookie handle was discarded by a Domain Controller or a different LDAP connection was used on subsequent page retrieval. Paged search needs to be restarted and will succeed.

Additional information:
The parameter is incorrect. Active directory response: 00000057:
LdapErr: DSID-0C09068F, comment: Error processing control, data 0, vece.

Call stack
Microsoft.Exchange.Data.Directory.ADSession.AnalyzeDirectoryError(Pooled
LdapConnection connection, DirectoryRequest request, DirectoryException de, Int32& retries, Int32 maxRetries) Microsoft.Exchange.Data.Directory.ADGenericReader.GetNextResultCollection(Type controlType, DirectoryControl& responseControl) Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextResultCollection()
Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextPage()
Microsoft.Exchange.Data.Directory.ADPagedReader`1.d__0.MoveNext()
Microsoft.Exchange.Data.Directory.SystemConfiguration.AddressBookBase.Pa
gedSearch(ADObjectId rootId, AddressBookBase addressBookBase, RecipientCategory recipientCategory, String searchString, Int32 itemsToSkip, String& cookie, Int32 pageSize, Int32& itemsTouched, Int32& lcid, String& preferredServerName, PropertyDefinition[] properties) Microsoft.Exchange.Data.Directory.SystemConfiguration.AddressBookBase.PagedSearch(ADObjectId rootId, AddressBookBase addressBookBase, RecipientCategory recipientCategory, String searchString, String& cookie, Int32 pagesToSkip, Int32 pageSize, Int32& itemsTouched, Int32& lcid, String& preferredServerName, PropertyDefinition[] properties) Microsoft.Exchange.Clients.Owa.Basic.Controls.AddressBookDataSource.LoadData(Int32 startRange, Int32 endRange)
Microsoft.Exchange.Clients.Owa.Basic.AddressBook.CreateListView()
Microsoft.Exchange.Clients.Owa.Basic.AddressBook.OnLoad(EventArgs e)
System.Web.UI.Control.LoadRecursive()
System.Web.UI.Page.ProcessRequestMain(BooleanincludeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Inner Exception
Exception type:
System.DirectoryServices.Protocols.DirectoryOperationException
Exception message: The server does not support the control. The control is critical.

Call stack
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut) System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout) Microsoft.Exchange.Data.Directory.PooledLdapConnection.SendRequest(DirectoryRequest request, LdapOperation ldapOperation) Microsoft.Exchange.Data.Directory.ADGenericReader.GetNextResultCollection(Type controlType, DirectoryControl& responseControl)

How to fix
You will need to upgrade to Exchange 2007 Rollup 1: http://support.microsoft.com/?kbid=945684

Dave

How to force Outlook 2007 to use a static autodiscover.xml file

Brian Tirch is any army contractor work very closely with the Beta team here at Microsoft. He wrote a great article on how to have the Outlook client use a static autodiscover.xml file. If you have time check out his blog here: http://exchange-genie.blogspot.com/2007/07/autodiscover-ad-attribute.html

Dave

OABInteg - New Information

As most people know we took down GotDotNet and have relocated most of our external tools and code to http://code.msdn.com or http://codeplex.com. I have relocated OABInteg to the following location: http://code.msdn.com/oabinteg. I have updated the web documentation on how to use the tool as well we can be found here: http://blogs.msdn.com/dgoldman/archive/2005/08/28/oabinteg-and-how-to-use-it-to-troubleshoot-oab-generation-issues.aspx.

New Changes to OABInteg

As per request from the military I have added a new logging switch: /v:3 (ErrorsOnlyLogging). By using this switch the following things will happen when you run the proxytest test.

1. All screen (command window) output will be the same as it is with /v:2 which means you will see everything. You can just minimize the output window to reduce the buffer size and view it as needed.
2. Logging will reflect the objects that have the problem either by display name or legacyExchangeDN depending on the problem.
3. Users that do not have a DisplayName, LegacyExchangeDN will be skipped from the gal so you will need to run the /v:2 switch for more logging to get to these objects.
4. You can use the /r:alias switch with the /v:3 for an ANR search for specific objects.
5. Logging to the c:\OABInteg.txt file will only contain objects that have the following problems:

*Total number of temp legacyExchangeDN's found: 5
**Total number of objects that are missing some main attributes: 126
**Total number of objects that mail and proxy attribute don't match: 12
**Total number of objects that do not have a domain value: 0
**Total number of objects that do not have a valid Unicode domain value: 0
**Total number of objects that do not have a valid SMTP Domain because first character is not greater than '/': 0
**Total number of objects that do not start with /o= or /O=: 1
**Total user objects that are missing the Primary Proxy address attribute: 0
***Total user objects with proxy addresses equal to or over 64 characters: 0
***Total objects with the '@' character in the legacyExchangeDN: 6
****Total objects with bad Active Directory Backlinks: 0
Total objects that have a legacyExchangeDN of ADCDisableMail: 1
Total objects that have a legacyExchangeDN of ADCDisableMailByADC: 0

NOTE: The ErrorsOnlyLogging switch can only be used with the proxytest only!

For more information on how to use the proxytest feature in OABInteg please see the following blog: http://blogs.msdn.com/dgoldman/archive/2007/03/08/how-to-use-oabinteg-s-oabfldcheck-and-proxytest-to-find-oab-issues.aspx

Dave

Address List and EAP filter upgrades with Exchange Server 2007

Evan Dodds from the Exchange Product Group wrote a great blog a while back with regards to LDAP / OPATH and filters. If you have had any problems upgrading your address lists or running the /ForceUpgrade command and they don't work, please check here to see why: http://msexchangeteam.com/archive/2007/01/11/432158.aspx

This is a must read!!

Dave

Changing the way Outlook displays it's address book columns.

I see this question pop up on the internal and external aliases a lot so I thought I would blog on it.

Question: Is there anyway to change the order and what columns in Outlook 2003 or 2007s address book? The default display shows the following: (Name, Business Phone, Office Title, Company, Alias, E-mail Type, E-mail Address)  and for some companies this is not very useful for us when looking up users on the GAL.

The answer to this is question is no. This is by default and can not be changed.

Dave

Exchange 2003 Address List Segregation Document

Over the last few months a great number of people have asked if we would be putting out a white paper on how to segregate address lists for Exchange 2003. We put a massive amount of time and effort into getting the Exchange 2007 version of this document ready and it is now released. There are no future plans to publish or create a 2003 version of this document.

There are a few things to note here:

1. If you are in need of address list segregation functionality, we highly recommend that you consider moving forward to Exchange 2007 to meet this need.
2. Microsoft never had produced a tested and supported solution for address list segregation, and that is why I wrote and fully tested with the development team the Exchange 2007 solution. The Microsoft Exchange product is an Enterprise Email solution and was never meant to be used for a hosting solution. This is why we created the HMC product. It is true that we did have some KB Articles and a hosting white paper at one time but they all have been pulled due to the number of service pack changes, hot fixes, security changes, etc. Over the last few years this support has been best effort, but due to the amount of problems that the documents have caused we will no longer provide that support.
3. All older Microsoft Exchange (Address List Segregation / Hosting KB Articles) have been pulled and are no longer valid.
4. All older Microsoft Exchange (Address List Segregation / White Papers, Technical Bulletins) have been pulled and are no longer valid.
5. All older Microsoft Exchange Hosting White Papers have been pulled and are no longer valid.
6. The only valid tested / approved Address List Segregation document is the Exchange 2007 address list segregation document that is now hosted on the Microsoft TechNet web site and is located here: http://technet.microsoft.com/en-us/library/bb936719.aspx

Outside using the Exchange HMC solution there will be no support for Exchange 2003 address list segregation.

This is the official stance from The Exchange Product Group.

If you have questions about Exchange 2003 / 2007 co-existence for address list segregation then please the following blog post which contains a FAQ around Address List segregation (and I am updating it frequently):

http://blogs.msdn.com/dgoldman/archive/2008/02/17/exchange-2007-address-list-segregation-document-updates.aspx

Dave

Exchange 2003 / 2007 Address List Segregation Document - Updates!!

Since the document has been out a few questions have come up and I wanted to try to answer them.

Question: Why is Exchange 2007 Service Pack 1 a requirement.

Answer: It is a requirement do to certain fixes that were added to SP1. We also wanted to make sure that customers are on the same platform that this was tested on. Since this was tested on SP1 it will be supported if you are *running* SP1. Applying this document to a system that doesn't have Service Pack 1 can yield different results and therefore might be a problem for you.

Question: What happens when you stand up a 2007 SP1 server in a existing 2003 organization?

Answer: Nothing. Applying this document in your environment will cause no problems if you are in a mixed environment. Once thing that you *will* have to consider is where you are going to host your Address Lists and OAB's (on Exchange 2003 or Exchange 2007). If your users are on Exchange 2003 you will not be able to host your Address Lists and OAB's on the Exchange 2007 server. The reason for this is that at the time of the generation we will read the search filter from the Exchange 2003 side and LDAP is not compatible with OPATH for Exchange 2007. With this regard you will have to move all of your Exchange 2003 mailboxes for that company over to Exchange 2007, then create your companies Address Lists and OAB's.

Question: Why can my Outlook users no longer see all of the Address Lists from within Outlook after I applied this document?

Answer: This is by default. By adding the 'All Users Security Group' and applying a 'Deny for Read and Open Address List' you are blocking the NSPI calls that Outlook makes to the All Address Lists Container. This was done to prevent users from one address list so they can not see users in another.

Question: Where is the Exchange 2003 version of this document?

Answer: This is not supported. We put out the Exchange 2007 document first as there was a greater need for this. The Exchange Product Group has decided to no longer support this.

Question: What is Supported? A "full segregated" environment. So there is ONLY ONE gal per company and a security group grants permissions? How can I implement, that company1 is using GAL1 and AL1, company2 is using GAL2 and AL2?

Answer: - This is what this document walks you through. Being fully segregated each company only has *1* gal. This is the purpose of segregation.

Question: But what if you still want to have a "default gal" containing everything ?. Why ?  Sample:

• Global Company with many sub-companies
• Subcompany1 users should use their segregated GAL/AL
• Subcompany2 users should use their segregated GAL/AL
• CEO and marketing of Main-Company should have a full GAL. (same with Blackberry Servers, Single Item Backups etc)

So by following this document there really is no way to configure one company with two or three GAL's and restrict only the "standard Users" to one GAL ?

Answer:  No. Either you follow this or you stay with standard exchange. What is not supported is trying to have the gal and trying to segregate that Default GAL. What you can do is make another OAB and then add all of the address lists to it and make sure that CEO is not part of any deny groups so he can see them in outlook.

Question: What if you read "319213 How To Use Address Lists to Organize Recipients in Exchange 2003", you can see an other permission model (deny on Address Lists).

Answer: This KB Article will soon be pulled and is no longer supported. Please do not follow it.

Question: What if I am in mixed mode, can I still use this document?

Answer: Yes, however to be supported all segregation will need to be done on the Exchange 2007 side. In order to do this there are a few steps involved.

1. MIXED MODE MIGRATIONS ONLY!!!! - Do not remove the permissions for the Default Global Address List until your migration is complete. You will not want to run the add-adpermissions powershell cmdlet until all users are on Exchange 2007.
2. You will be required to apply a security group to the Default Global Address List to stop users that have already been moved over to Exchange 2007 so they can not read the Global Address List. The security group will block read access as it does to the CN=All Address Lists Container.
3. Once your migration is complete you can remove the access with the powershell commands.

I will update this from time to time when I can.

Dave

Looking up Free/Busy information in a mixed org (E2K3/E2k7) will return a 4004 error.

For companies that have a mixed 2003/2007 environment and fall under one of the following states might see problems when querying legacy Free/Busy information:

1. Companies that are in the middle of a migration.
2. Companies that have already migrated and not realized migration problems such as changed attributes.

Event ID      : 4004
Category     : Availability Service
Source         : MSExchange Availability
Type            : Warning
Generated   : 27.09.2007 08:16:08
Machine       : ExchangeServer01
Message      : Process 2148[w3wp.exe:/LM/W3SVC/1/ROOT/EWS-1-128353572646987287]: Unable to find a public folder server for organizational unit (OU) CompanyUsers. The service will attempt to find a random server, which may take a longer time to service the request.

Looking deeper in to this event we can see the following:

<data name="PublicFolderServerNotFoundForOU">
<stringvalue>Process %1: Unable to find a public folder server for organizational unit (OU) %2. The service will attempt to find a random server, which may take a longer time to service the request.</stringvalue>
<eventmessageid>4004</eventmessageid>
<eventtype>Warning</eventtype>
<severity>Error</severity>
<facility>Interface</facility>
<language>English</language>
<category>Availability Service</category>
<level>Lowest</level>
<period>LogPeriodic</period>
<comment>Indicates a failure to find the server to look up free busy information for legacy mailbox(es).</comment>
</data>

Currently there are a few causes for this (More to be added later):

1. After the migration of the user the legacyExchangeDN still points to the decommissioned AG and that server no longer exists.
2. There are multiple servers and only one replica of the Free/Busy information.

Here is a high level overview on what happens when an Outlook client makes a Free/Busy request:

1. The Outlook 2007 client communicates with the Availability service for a Free/Busy request.
2. We will see if this is an Exchange 2007 mailbox and if it is the availability service will communicate directly with the users mailbox. If this is a legacy user we need to look up the user in the active directory so we can see what public folder store he has his data on.
3. The Availability service makes a query for that users legacyExchangeDN and homeServer attribute.
4. At this point we will make a connection to that server for the user in question.
5. Lookup the public folder server for this organizational unit - (Admin Group).
6. Look in our cache and report how many server objects we have that can be used.
7. Pick a random server from the list.
8. Check to see if we can communicate with this server. If we can not this server then gets added to the badServers list.
9. Make another query for another server.
10. At this point we will look for any server from any organizational unit - (Admin Group). Since this server might not contain the data that we are looking for add them to the badServers list as well.
11. As a last resort we look through the entire list and pick any server we can and then clear the badServers list.

Reason servers get added to the badServers list
If for any reason you have any connection issues or we can not find what we are looking for at the time of the query we will add the server to the bad list. Once this happens the server will stay inthe list unntil you restart the MSExchangeServicesAppPool, recycle the services or a successful query is made.

How to fix

Item #1
The problem here is that the legacyExchangeDN for the user is invalid. In order for the Availability service to work it needs to the correct legacyExchangeDN for the user so it can look up that users homeServer and then from there get the list of public folders. If we bind to an invalid legacyExchangeDN the domain controller we are querying will throw an DS_NO_SUCH_OBJECT error which gets returned back to exchange and then the query fails. Once the legacyExchangeDN is corrected this problem should go away.

Item #2
The fix is for you to put Free/Busy replica's on each of your servers in that administrative group. This is not an optimal fix but is required to fix this problem. Currently this is by design and there is no way to force the availability service to pickup Free/Busy data from a specific PF server.

Exchange 2007 Address List Segregation Document Will be Out in February!!!

I am sorry that I haven't posted in a while, as I spent most of the last couple months investing a ton of time in to getting this white paper finished for everyone. I just have finished the Address List segregation document. I just got clearance from Tom Di Nardo who is a Senior Technical Writer with the Exchange Product Group and the brains behind getting this document out to the world.  Tom has been helping me around the clock on this document that we will have this ready and released in our February technical refresh. This is a 50 page comprehensive document on how to set up address list segregation with Exchange 2007.

This document will cover the following:

1. Introduction to Address list segregation
2. Supported and Unsupported Configurations
3. Planning for Active Directory Partitioning
4. Global Address List Configuration
5. OWA and Outlook attribute configuration
6. Active Directory schema configuration
7. Permissions, Policy, User, Group and Organization, GAL and OAB configurations

Here is the link to the document: http://technet.microsoft.com/en-us/exchange/bb936719.aspx

NOTE: What this document is *not* a replacement solution for a HMC (Hosted Solution). This document is meant to be used for companies that need to separate out their internal support structure. If you are going to be hosting other companies or organizations you will want to go towards a Hosted Solution and this document is *not* for you.

I want to give a big thanks to the following people that made this possible:

1. Tom Di Nardo, Senior Technical Writer - Who spent I can't tell you how many hours writing, reviewing, writing scripts and testing this.
2. Michael Barta, Support Escalation Engineer, Microsoft CSS Enterprise Messaging Support - Who spent a *ton* of time putting the original draft together for me. Michael wrote a lot of the Powershell scripts as tested this as much as I did. Michael spent many hours with me and Exchange Development team to come up with the best solution.
3. All of you that waited patiently for this document for so long.

Together we made this possible for all of you.

Dave