Dgoldman's WebLog

Understanding why error code 0X8004010F is thrown when trying to download an OAB

When it comes to downloading an OAB the following error code [ 0X8004010F ] is the biggest pain for everyone, and the most misunderstood error. The number one thing is to understand is that this error means MAPI_E_NOT_FOUND:

C:\dgoldman>err 0X8004010F
# for hex 0X8004010F / decimal -2147221233
ecNotFound ec.h
ecAttachNotFound ec.h
ecUnknownRecip ec.h
ecPropNotExistent ec.h
MAPI_E_NOT_FOUND mapicode.h
# 5 matches found for "0X8004010F"

With regards to downloading an OAB, if you see this error it means your OAB was not found. This can also be throw for a few different reasons based on your exchange configuration:

1. A mixed organization that is going through a migration (2000- 2003), (2000-2007), etc
2. You had public folder problems like: (replication, lost a public folder server and rebuilt it, had public folders rehomed)
3. You just starting using Outlook 2007 and are trying to use HTTP/RPC (Outlook Anywhere).

Here is a high level overview on the client server interaction when downloading an OAB.

1. Every morning at 5am or based on a custom schedule the Exchange server that is hosting the OAB will start an OABGen rebuild task.
2. The System Attendant invokes oabgen.dll to start the rebuilt and pass along the OAB to be built.
3. OABGen.dll will query a domain controller for the data needed to build an oab. While the data is being processed it will be split the data to different temp files residing on the c:\windows\temp directory.
4. OABGen.dll will make a connection to a public folder store and download last nights public folder OAB files so they can be compared. This is where we will create the OAB differential files.
5. OABGen.dll will make another connection to the public folder store it is associated with and posted a system message with the new files to the OAB Version 2, OAB Version 3 or OAB Version 4 folders. If you have Exchange 2007 the data will be posted to the local \\ExchangeOAB directory and then the FDS service on the CAS (Client Access Server) will copy over the new OAB files so they can be download by the client.
6. The msExchUseOAB attribute. This attribute contains the DN of the offline address list to be downloaded. This attribute resides in two places (1. The user object in the active directory - Domain Naming Context Container, and 2. on the information store object). When the outlook client starts up it will look at its own user object in the active directory to see if there is anything in the msExchUseOAB attribute, and if there is this will override the information store settings. Having this set to an offline address list that no longer exists will cause the download to fail. If there is nothing on the user object then a query for the msExchUseOAB attribute on the server object where the mailbox resides. The MAPI property equivelant for this is called PR_ADDRBOOK_FOR_LOCAL_SITE_ENTRYID and contains an EntryID that looks like the following: 0000000001A447390AA6611CD9BC800AA002FC45A0300B4CF3F5BB03DC0499AB07A96F707B1AB0000000000080000
7. The Outlook client will call the OpenFolder API on that EntryID which will corrosponds to the correct OAB root folder and then will try to open the OAB folders in the following format: OAB Version 4, OAB Version 3 or OAB Version 2.
8. Based on the service pack, version of the Outlook cilent and version of the Exchange Information Store (store.exe) the client will connect to one of the OAB folders. In order for an Outlook client to connect to the OAB Version 4 folders it must be on Exchange 2003 SP2 and Outlook SP2 or Outlook 2007. Based on this service pack / hot fix combination the Outlook client will attempt to connect to the latest version is had knowledge about.

For Outlook 2003 (all service packs)

1. For any reason if the client cannot connect to that the OAB folder it is looking for it will then attempt to connect to the next lowest version. Example (Connect to OAB Version 4 = failed, now try to connect to OAB Version 3 = failed, now try to connect to OAB Version 2 = failed), and now we throw the error: 0X8004010F.

Now this can be for a few reasons:

1. The mailbox store your client is residing on does not have an OAB associated with it.
2. The msExchUseOAB attribute is populate with a DN of an OAB that doesnt exist.
3. The msExchUseOAB attribute on the information store is blank.  If you look in the ESM this is the OAB that is associated with that mailbox store and this can be reset.
4. Someone has deleted the Default Global Address List. In this case this will break the link between the Default Offline Address List and the Default Global Address List and remove it from the information store object.
5. You have multiple public folder stores and the OAB generation process has posted them to a different public folder store than you thought. Replication has not taken effect yet, thus there will be no new files or OAB files to download.
6. Make sure that your SMTP connectors do not have restrictions blocking replicas from being passed to different public folder servers.
7. The OAB generation process had a problem and terminated. In this case the files would not be posted to the public folder store.
8. An administrator decommissioned the last Exchange server in a site and never pushed the replicas to another Exchange server.
9. A new OAB is created in the active directory and the information store never reads the active directory during its maintenance schedule. This will result in the OAB files never being generated and the Outlook client will fail to download anything.
10. The information store has an invalid EntryID that points to the legacy EX:/ folders. Again there is nothing for the client to download.
11. An outlook client logging in from one domain to another domain and attempting to log in to another users mailbox.
12. The OAB was never generated or some OAB folders are missing from the public folder store.
13. Multiple OAB Version folders exist of the same type.
14. Clients are attempting to download the OAB files from a public folder store that have not received the replicated updates.
15. The offline address book list object has a missing address list. 
16. The offline address book list object has an incorrect address list.
17. Send/As changes in the store affect users accounts with no mailbox full rights to another mailbox.

For Outlook 2007 (all service packs)

1. If you have installed Exchange 2007 in to an Exchange 2003 organization you need to make sure that you have added the replicas of OAB to the Exchange 2007 server.
2. Make sure public folder replication is working between servers. 
3. An Autodiscover DNS record has not be setup by your ISP therefor will break HTTP/RPC because you will not be able to connect.
4. You have set an invalid proxy setting in IE. Windows, Outlook and IE all use the same WinHTTP Proxy settings and if this proxy is incorrect all Outlook WinHTTP calls fill fail.
5. Make sure the OAB is public folder enabled and you have OAB Version 2, OAB Version 3 and OAB Version 4 checked off so your legacy clients can download the OAB files from the public folder store. 
6. Make sure that if you are using an Outlook 2007 client, your OAB is Web Distribution enabled and the OAB files have been replicated over to the Client Access Server. For more information on this process please see this blog:

http://blogs.msdn.com/dgoldman/archive/2006/10/23/outlook-client-fails-to-download-the-oab-with-error-0x8004011b.aspx and
http://blogs.msdn.com/dgoldman/archive/2006/08/25/How-Exchange-2007-OAB-Files-are-replicated-to-a-Client-Access-Server-for-download.aspx

7. If you are removing your last Exchange 2003 server from the org, please make sure that you follow our documentation on this process.

8. The OAB may not exist is if you have a cluster and that node that is currently inactive, and also is the only one set to generate the OAB.  For more information please see: http://blogs.msdn.com/dgoldman/archive/2007/02/08/oab-generation-on-a-cluster-server-fails-with-event-id-9395-or-9396.aspx

  Dave

How to get HideFromAddressBook to work on Exchange 2007

Often times customer have a need to create bulk contacts for their organization, but have business requirements to hide these contacts from the global address list. I am just listing two simple ways that you can hide them from the address list. These ways can be as complex as you want them to be depending on your powershell scripting.

You can create your bulk contacts by running the following command in powershell:

New-MailContact -ExternalEmailAddress 'SMTP:TestUser@YourCompany.com' -Name 'Test' -OrganizationalUnit 'YourDomain.com/Contacts/YourCompany' -FirstName 'Test' -LastNane 'User'.

Now that the contacts have been created the second part of this is to hide them from the global address list. There are a few different ways to do this and I only listed two (by searching the entire gal or or by DN).

General Filter: get-mailcontact * | set-mailcontact -hiddenfromaddresslistsenabled $true

By DN: get-mailcontact -OrganizationalUnit "DC=YourDomain,DC=COM,OU=TargetOU" | set-mailcontact -hiddenfromaddresslistsenabled $true

Dave

SearchFolderFinder has now been posted for download

Today I posted the SearchFolderFinder.exe on http://code.msdn.com/SearchFolderFinder. I hope that this will help aid everyone in troubleshooting Version Out Of Store Memory issues. For more information on this tool please see this blog: Exchange Search Folders.

Dave

Exchange search folders and performance ramifications

A while back I wrote a few blogs so I could get some detailed information out on how search folders work and how they can impact performance on exchange servers: Microsoft Exchange and search folders. I wrote it from the aspect on how it can cause 623 events which are JET_errVersionStoreOutOfMemory. One thing that I did not do was post any performance related information in the blog, however Mike Lagase is one of the performance guru's at Microsoft and works in my group. Being that many administrators are not verse in looking at performance monitor logs for these types of issue he wrote a fantastic blog. Please check it out: Search Folder Performance problem detection.

Dave

Update - Changing the display name of active directory users

Back on Thursday, June 19, 2008 3:06 PM I published a blog on Changing the display name of active directory users. I want to thank Amit Tank for taking the time to write up a wonderful repo and blog with the steps on how to achive this now. Please check out his blog: http://exchangeshare.wordpress.com/2008/08/17/exchange-2007-display-name-format

Dave

Why details template changes don't seem to show up on clients after being made

I wanted to elaborate a little on the topic of details templates and how they work. Details templates control the appearance of object properties that are accessed by using address lists. When a user opens an address list in Outlook, for example, the properties of a particular object are presented as defined by the details template in the Exchange organization.

There are two parts to the details templates that most people don't remember or realize.

1. They reside in the active directory and can be changed at any time.
2. Reside in the OAB files when they are downloaded by Outlook clients.

The details templates reside in the active directory and can be accessed via the ESM. You can open the Recipients Container | Details Templates | <Your Language>. For more information on how to modify them you can view my blog: http://blogs.msdn.com/dgoldman/archive/2007/02/14/how-to-add-edit-change-and-revert-address-and-details-templates.aspx

Here is where the confusion comes in to play. Depending on which Outlook client you are running you will see different results.

1. For legacy clients (OAB Version 2 and OAB Version 3) they will have to do a full OAB download to get the new template changes. Please read this blog on how legacy clients generate the OAB files (this includes the Tmplts.oab file): http://blogs.msdn.com/dgoldman/archive/2005/04/28/413043.aspx.
2. NOTE: To cause a full OAB download for a client you can go to the following location: C:\Documents and Settings\UserName\Local Settings\Application Data\Microsoft\Outlook and delete all of the *.oab files. This will cause the Outlook client to perform a full OAB download. You can also initiate this via the Send/Receive settings from within Outlook.
3. We made changes in Exchange 2003 service pack 2 that will allow Outlook clients to download the template changes if they are downloading OAB Version 4. For more information on the changes you can read this blog I wrote: http://msexchangeteam.com/archive/2005/08/01/408473.aspx, however the most important change I in the blog that I want to note is the following: OAB Templates will now be added to differential OAB download when they are updated. With the introduction of OAB v4, when an administrator changes or adds a template file on the Exchange server, Outlook clients will now have the ability to download this new template file when it downloads the diff file.

This does not matter for OAB Version 4 clients that are on an Exchange 2003 server that is running Service Pack 2, or an Exchange 2007 Server that is generated OAB Version 4 for Public Folder and Web Distribution. The clients *will* download the template changes as part of the differential OAB download.

I hope this helps

Dave

A great Exchange, SQL and IIS book to get

I was out a few weeks ago at the book store looking some more books and I came across the following book: The Best Damn Exchange, SQL and IIS Book Period (Best Damn) (Book Period) (Paperback). This is an outstanding book and is a damn good resource for all 3 core Microsoft servers (Exchange, SQL and IIS). I picked a copy of it up right there on the spot. This book is published by Syngress Publishing and was written by the following people:

• Henrik Walther (Author) - Runs / maintains (http://msexchange.org)
• Mark Horninger (Author) -  Is the president / founder of Haverford Consultants Inc. (http://www.haverford-consultants.com)
• Chris Adams (Author) - Is a program manager here at Microsoft.
• And countless others.......

As I read this book I found some material in the book that looked somewhat fimiliar when I got to the Exchange 2007 OAB section. To my surprise the authors of the book made a key reference to me on page 231!. There is a reader's tip on the page that states the following:

"When it comes to detailed information about OAB's, one of the best resources on the Internet is a blog run by Dave Goldman. Dave works as an Exchange Escalation Engineer (EE) for Microsoft in North Carolina and is, among other things, the guy behind the OABInteg tool, which is used to troubleshoot OAB issues. You can visit Dave's blog at http://blogs.msdn.com/dgoldman".

I just want to extend a great thanks to all of the technical contributors and authors of this book for including me and my work. If you don't have a copy of this book, you really should get one!

Dave

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 Link: https://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=FindSearchFolders&ReleaseId=1456

Here is what the output looks like if you are search for a mailbox that has a high item count and high search folders. The action plan for finding the mailbox with the high search folder count is listed at the end of this output.

**********************************************************
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 ... 

If you are looking for a mailbox that has a massive amount of search folders like the one above you can do the following:

1. Put the isinteg.pri in the root of your c:\.
2. Run the tool. and this will create a text file in the root of your c:\.
4. Look at the bottom of the log file and find the fid that has the most search folders.
5. Then open the isinteg.pri file and search down for that fid until you cant go anymore, this will be your offender,
6. Get the root fid from that and search up from the bottom and that is your mailbox 

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