Dgoldman's WebLog

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 2007's 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

Why hiding distribution memberships in Exchange 2007 is no longer supported.

In exchange 2007 there is no more RUS (Recipient Update Service). Because the RUS is not around to stamp acls on hidden distribution lists, we can no longer ensure the distribution list will still be hidden. When ADUC changes or updates a distribution list it will set canonical acls, and to hide the membership we need to set non-canonical acls.

Due to these limitations with Exchange 2007 and the Active Directory we no longer support hiding Distribution List Memberships. There is a new workaround that can be used which is explained later on in this blog.

With regards to the names of the groups, a QBDG (Query Based Distribution Group) is exactly the same as DDG (Dynamic Distribution Group). DDG does not “replace” QBDG. If you create a DDG in E2k7, it will show as QBDG in E2k3. If you create a QBDG in E2k3, it will show as DDG in E2k7. We just renamed the friendly name of the existing object :)

Truth be known hiding (static) Distribution Group membership never really worked to begin with due to limitations of Active Directory. If you were part of a distribution list that was hidden it was very easy for someone to pull up your account in the global address list via outlook and see what groups you are in!! As a part of a security audit by the product group, it was decided to remove this insecure feature from the product in favor of using the QBDG/DDG feature, which serves as reasonable (if awkward) mitigation”.

With Exchange 2007 dynamic distribution groups are expanded by the transport service to include any recipient(s) in the Active Directory service with attributes that match its filter. Note that a side effect of this dynamic membership means that a recipient that is not expected to be part of a dynamic distribution group could inadvertently become a member and start receiving messages sent to the dynamic distribution group if the recipient's properties are modified to match the filter. This could result in a recipient receiving messages that the recipient is not supposed to receive. Well-defined, consistent account provisioning processes will reduce the chances of this happening.

New Workaround!!
The work around in Exchange 2007 is now to create a DDG. Let me elaborate on this. To get this to work you need to do the following:

1. Stamp your users with a custom attribute or some other distinguishing, filterable characteristic. You can use custom attributes 1 - 15 for this.
2. Create a Dynamic Distribution Group which has a filter for the custom attribute (or characteristic/property) that you stamped on your user(s).
3. Send an email to your Dynamic Distribution Group.
4. If you want to truly hide this membership in the DDG, you also need to ACL the property that you're using to define the DDG filter. (Example: if you use CustomAttribute1 = "Org 1" as the filter criteria, you need to make sure you ACL down the CustomAttribute1 property in Active Directory Schema so that it's not readable by anyone but admins and the Exchange Servers (so transport can still do DDG expansions).

By default, all new dynamic distribution groups require that all senders be authenticated. This prevents external senders from sending messages to dynamic distribution groups. This default setting is different from previous versions of Exchange where, by default, new query-based distribution groups accepted messages from all senders.

To configure a dynamic distribution group to accept messages from all senders in Exchange 2007, you must modify the message delivery restriction settings for that dynamic distribution group. For more information about configuring message delivery restrictions, see How to Configure Message Delivery Restrictions.

For more information on how to create Dynamic Distribution Lists please refer to: http://technet.microsoft.com/en-us/library/aa996561.aspx

Thanks to Evan Dodds for his review!!

Dave

Setting the web.config tag <identity impersonate="true" /> will cause Exchange Poweshell cmdlets to fail and crash the MSExchangeServicesAppPool

When Exchange 2007 is installed it will create the following application pools within IIS 6.0:

• MSExchangeAutodiscoverAppPool         
• MSExchangeOWAAppPool                                         
• MSExchangeServicesAppPool                   
• MSExchangeSyncAppPool
• MSExchangeUMAAppPool

What is an Application Pool?
An application pool is a feature of IIS 6.0 that allows one or more applications to be configured to run with a level of isolation between different Web applications. If you want to isolate all of your custom Web applications you would create a separate application pool for each of your Web application and placing them in their corresponding application pool.

Each application pool will run in its own worker process, and by default the Exchange Application pools run under the identity of the local system.

In previous versions of IIS all worker processes ran under the Local System account. This account has system administrator privileges (god rights) on the local server. Because LocalSystem has god rights over a system it can cause security risks. In IIS 6.0 you can set the identity of the worker process at the application pool level.

What is an identity?
An Identity is the account that the application pool is running under. When you install IIS 6.0 all application pools run under the NetworkService account. The NetworkService user account has very low-level access rights.

The NetworkService account has the following privileges:

• Adjust memory quotas for a process
• Generate security audits
• Log on as a service
• Replace process level token
• Impersonate a client after authentication
• Allow logon locally
• Access this computer from the network

By running your application pools under the NetworkService you can minimize your servers security risks. In IIS you can configure your application pools to run under one of the following three accounts:

• NetworkService
• LocalSystem
• LocalService

When you install Exchange 2007 all Exchange application pools run under the LocalSystem account. This is needed for access across domains, etc. Often administrators have the need to create customer asp .net applications that need different access rights. One way to get this to work is to make some configuration changes to the web.config file for the application pool and change the following tag from:<identity impersonate="false" /> to: <identity impersonate="true" />

By default the web.config file in the exchange virtual directories have the impersonate flag set to false. When you set this tag to 'True' you are allowing code to impersonate a different Windows user, including when you run the Powershell cmdlets.

Windows authentication allows us to use the windows user accounts. This provider uses IIS to perform the actual authentication, and then passes the authenticated identity to your code. In this case we are running a cmdlet as the domain administrator and not the system's local service account. Once you do this the application pool will force a crash which is used to protect us from a security exploit. For those of you who like to debug managed code here is the call stack:

0:000> !clrstack

OS Thread Id: 0x117c (0)
Child-SP RetAddr Call Site
000000000681d6e0 0000064220206ef1 System.Environment.Exit(Int32)
000000000681d730 00000642243cc4ca Microsoft.Exchange.Common.ExDiagnostics.FailFast(System.String, Boolean)
000000000681d7a0 00000642243cc7e0 Microsoft.Exchange.Data.Directory.ConnectionPoolManager.BlockImpersonatedCallers()
000000000681d8b0 00000642243cdcc5 Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(Microsoft.Exchange.Data.Directory.ConnectionType, Int32 ByRef)
000000000681d900 00000642243cdde9 Microsoft.Exchange.Data.Directory.ADSession.GetConnection(System.String, Boolean, Boolean, Microsoft.Exchange.Data.Directory.ADObjectId ByRef, Int32 ByRef)
000000000681db20 00000642243d1b8b Microsoft.Exchange.Data.Directory.ADSession.GetReadConnection(System.String, Microsoft.Exchange.Data.Directory.ADObjectId ByRef, Int32 ByRef)
000000000681db60 00000642243d2a8f Microsoft.Exchange.Data.Directory.ADSession.Find(Microsoft.Exchange.Data.Directory.ADObjectId, System.String, Microsoft.Exchange.Data.Directory.ADObjectId, Microsoft.Exchange.Data.Directory.QueryScope, Microsoft.Exchange.Data.QueryFilter, Microsoft.Exchange.Data.SortBy, Int32, System.Collections.Generic.IEnumerable`1<Microsoft.Exchange.Data.PropertyDefinition>, Microsoft.Exchange.Data.Directory.CreateObjectDelegate, Microsoft.Exchange.Data.Directory.CreateObjectsDelegate)
000000000681df20 00000642243d2c54 Microsoft.Exchange.Data.Directory.ADSession.Find(Microsoft.Exchange.Data.Directory.ADObjectId, Microsoft.Exchange.Data.Directory.QueryScope, Microsoft.Exchange.Data.QueryFilter, Microsoft.Exchange.Data.SortBy, Int32, System.Collections.Generic.IEnumerable`1<Microsoft.Exchange.Data.PropertyDefinition>, Microsoft.Exchange.Data.Directory.CreateObjectDelegate, Microsoft.Exchange.Data.Directory.CreateObjectsDelegate)
000000000681df90 000006427f668a37 Microsoft.Exchange.Data.Directory.ADSession.Find[[System.__Canon, mscorlib]](Microsoft.Exchange.Data.Directory.ADObjectId, Microsoft.Exchange.Data.Directory.QueryScope, Microsoft.Exchange.Data.QueryFilter, Microsoft.Exchange.Data.SortBy, Int32, System.Collections.Generic.IEnumerable`1<Microsoft.Exchange.Data.PropertyDefinition>)
000000000681e0a0 00000642221a928a Microsoft.Exchange.Data.Directory.Recipient.ADRecipientSession.FindBySid(System.Security.Principal.SecurityIdentifier)
000000000681e180 00000642221a96c1 Microsoft.Exchange.Data.Storage.ExchangePrincipal.FromUserSid(Microsoft.Exchange.Data.Directory.Recipient.ADRecipientSession, System.Security.Principal.SecurityIdentifier)
000000000681e220 0000064280203d53 Microsoft.Exchange.Data.Storage.ExchangePrincipal.FromWindowsIdentity(System.Security.Principal.WindowsIdentity)
000000000681e260 0000064280203a42 Microsoft.Exchange.Services.Core.Types.ExchangePrincipalCache.CreateExchangePrincipal(System.Security.Principal.WindowsIdentity)
000000000681e2f0 00000642802037f5 Microsoft.Exchange.Services.Core.Types.ExchangePrincipalCache.GetFromCache(System.Security.Principal.WindowsIdentity)
000000000681e330 0000064280203107 Microsoft.Exchange.Services.Core.Types.CallContext.Initialize(System.Security.Principal.IPrincipal, Microsoft.Exchange.Services.Core.Types.AppWideMailboxSessionCache, Microsoft.Exchange.Services.AcceptedDomainCache, Microsoft.Exchange.Services.Core.Types.MailboxAccessType, Microsoft.Exchange.Services.Core.Subscriptions, System.Globalization.CultureInfo, System.Globalization.CultureInfo, System.String)
000000000681e3b0 0000064280202b0d Microsoft.Exchange.Services.Core.Types.CallContext..ctor(System.Security.Principal.IPrincipal, Microsoft.Exchange.Services.Core.Types.AppWideMailboxSessionCache, Microsoft.Exchange.Services.AcceptedDomainCache, Microsoft.Exchange.Services.Core.Types.MailboxAccessType, System.String, System.String, System.String, Microsoft.Exchange.Services.Core.SerializedSecurityAccessToken, Microsoft.Exchange.Services.Core.Subscriptions, System.Globalization.CultureInfo, System.Globalization.CultureInfo, System.String)
000000000681e440 000006428020276b Microsoft.Exchange.Services.RequestSoapHeaderServiceExtension.ConfigureCaches(Microsoft.Exchange.Services.Core.Types.MailboxAccessType, System.String, System.String, System.String, Microsoft.Exchange.Services.Core.SerializedSecurityAccessToken, System.String)
000000000681e540 0000064280202046 Microsoft.Exchange.Services.RequestSoapHeaderServiceExtension.ProcessSoapHeaders(System.Web.Services.Protocols.SoapMessage, System.Object)
000000000681e600 00000642801fad99 Microsoft.Exchange.Services.ServiceExtensionManager.DoAfterDeserializeRequest(System.Web.Services.Protocols.SoapMessage)
000000000681e690 0000000005432798 Microsoft.Exchange.Services.ServiceExtensionManager+<>c__DisplayClass1.<ProcessMessage>b__0()
000000000681e6e0 000006422087918b Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Microsoft.Exchange.Common.IL.TryDelegate, Microsoft.Exchange.Common.IL.FilterDelegate, Microsoft.Exchange.Common.IL.CatchDelegate)
000000000681e720 00000642801faccc Microsoft.Exchange.Diagnostics.ExWatson.SendReportOnUnhandledException(MethodDelegate, IsExceptionInteresting)
000000000681e770 0000064253282b49 Microsoft.Exchange.Services.Core.ServiceDiagnostics.TraceErrorOnUnhandledException(MethodDelegate)
000000000681e7b0 00000642532773fb System.Web.Services.Protocols.SoapMessage.RunExtensions(System.Web.Services.Protocols.SoapExtension[], Boolean)
000000000681e810 000006425326f611 System.Web.Services.Protocols.SoapServerProtocol.CreateServerInstance()
000000000681e860 000006425326fcfb System.Web.Services.Protocols.WebServiceHandler.Invoke()
000000000681e8d0 00000642bcaee322 System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
000000000681e930 00000642bcaf1e41 System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
000000000681e9f0 00000642bcaed472 System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)
000000000681ea90 00000642bcaf54b0 System.Web.HttpApplication+ApplicationStepManager.ResumeSteps(System.Exception)
000000000681eb50 00000642bcac103e System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext, System.AsyncCallback, System.Object)
000000000681ebb0 00000642bc8c4eb1 System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest)
000000000681ec50 00000642bc9525d8 System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest)
000000000681ec90 000006427f66a6f2 System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)

If you look in the application log you after you run a powershell cmdlet such as Test-OutlookWebServices you will see the following error:

Event Type: Error
Event Source: MSExchange Common
Event Category: General
Event ID: 4999
Date: 10/27/2007
Time: 3:08:56 PM
User: N/A
Computer: Exchange2007
Description:
Watson report about to be sent to dw20.exe for process id: 4228, with parameters: E12IIS, c-RTL-AMD64, 08.00.0685.020, WS, M.E.D.Directory, M.E.D.D.ConnectionPoolManager.BlockImpersonatedCallers, M.E.Common.FailFastException, 78ac, 08.00.0685.024

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The key piece of information here is the following: M.E.D.D.ConnectionPoolManager.BlockImpersonatedCallers.

How to Fix
1. Modify the web.config file in the root of the virtual directory and change the following tag from: <identity impersonate="True" /> back to: <identity impersonate="false" />.
2. Restart your Exchange application pool.
3. Re-run your Powershell cmdlet.

Dave

Deleting the All Rooms address list stops it from showing up in OWA.

During the Microsoft Exchange 2007 install we will create the default address lists and offline address lists. During that creation time we will populate the msExchResourceAddressLists attribute on the organization configuration object with the DN of the All Rooms address list.

This allows the All Rooms address list to be shown in the OWA when you click on the address list tab. Running the following Powershell cmdlet [Get-OrganizationConfig] will let you see that after you delete the All Rooms address list it is no longer linked.

[PS] C:\>Get-OrganizationConfig

Name : org
LegacyExchangeDN : /o=org
Heuristics : None
JournalingReportNdrTo :
ResourceAddressLists : {All Rooms DEL:47dd20dc-2efa-462b-b838-369eac589ddd}
IsMixedMode : False
ManagedFolderHomepage :
ForeignForestFQDN : {}
ForeignForestOrgAdminUSGSid :
ForeignForestRecipientAdminUSGSid :
ForeignForestViewOnlyAdminUSGSid :
ObjectVersion : 6903
SCLJunkThreshold : 4
MimeTypes : {text/html;htm, text/html;html, text/plain;tx
t, text/css;css, text/iuls;uls, text/scriptle
t;wsc, text/webviewhtml;htt, text/x-component
;htc, text/x-vcard;vcf, text/xml;xml, image/g
if;gif, image/jpeg;jpg, image/x-xbitmap;xbm,
image/bmp;bmp, image/pjpeg;jpg, image/png;png
...}
MicrosoftExchangeRecipientEmailAddresses : {X400:C=US;A= ;P=org;O=Exchange;S=MicrosoftExchange329e71ec88ae4615bbc36ab;, SMTP:MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@org.local}
MicrosoftExchangeRecipientReplyRecipient :
MicrosoftExchangeRecipientPrimarySmtpAddress : MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@org.local
MicrosoftExchangeRecipientEmailAddressPolicyEnabled : True
MinAdminVersion :
AdminDisplayName : {335A1087-5131-4D45-BE3E-3C6C7F76F5EC}
ExchangeVersion : 0.0 (6.5.6500.0)
DistinguishedName : CN=org,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=tpworld,DC=local
Identity : org
Guid : 847045b0-036f-42c1-86f5-846c6f9fb0eb
ObjectCategory : org.local/Configuration/Schema/ms-Exch-Organization-Container
ObjectClass : {top, container, msExchOrganizationContainer}
WhenChanged : 12/5/2007 1:22:22 PM
WhenCreated : 3/23/2007 11:06:54 AM
OriginatingServer : GC01.tpworld.local
IsValid : True

How to fix
1. Open ADSIEdit.
2. Naviagate to the All Rooms address list.
3. Copy the distinguishedName attribute.
4. Open your organization object [cn=YourOrg].
5. Look in the list of attributes for the msExchResourceAddressLists attribute.
6. Remove the current DN which is {All Rooms DEL:47dd20dc-2efa-462b-b838-369eac589ddd}.
7. Paste in the new distinguishedName attribute of the All Room's address list.

NOTE: If you have multiple domain controllers you need to replicate them around.
8. Run Get-OrganizationConfig to verify that the changes have taken place.

[PS] C:\>Get-OrganizationConfig

Name : org
LegacyExchangeDN : /o=org
Heuristics : None
JournalingReportNdrTo :
ResourceAddressLists : {All Rooms} <-- Fixed!!
IsMixedMode : False
ManagedFolderHomepage :
ForeignForestFQDN : {}
ForeignForestOrgAdminUSGSid :
ForeignForestRecipientAdminUSGSid :
ForeignForestViewOnlyAdminUSGSid :
ObjectVersion : 6903
SCLJunkThreshold : 4
MimeTypes : {text/html;htm, text/html;html, text/plain;tx
t, text/css;css, text/iuls;uls, text/scriptle
t;wsc, text/webviewhtml;htt, text/x-component
;htc, text/x-vcard;vcf, text/xml;xml, image/g
if;gif, image/jpeg;jpg, image/x-xbitmap;xbm,
image/bmp;bmp, image/pjpeg;jpg, image/png;png
...}
MicrosoftExchangeRecipientEmailAddresses : {X400:C=US;A= ;P=org;O=Exchange;S=MicrosoftExchange329e71ec88ae4615bbc36ab;, SMTP:MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@org.local}
MicrosoftExchangeRecipientReplyRecipient :
MicrosoftExchangeRecipientPrimarySmtpAddress : MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@org.local
MicrosoftExchangeRecipientEmailAddressPolicyEnabled : True
MinAdminVersion :
AdminDisplayName : {335A1087-5131-4D45-BE3E-3C6C7F76F5EC}
ExchangeVersion : 0.0 (6.5.6500.0)
DistinguishedName : CN=org,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=tpworld,DC=local
Identity : org
Guid : 847045b0-036f-42c1-86f5-846c6f9fb0eb
ObjectCategory : org.local/Configuration/Schema/ms-Exch-Organization-Container
ObjectClass : {top, container, msExchOrganizationContainer}
WhenChanged : 12/5/2007 1:22:22 PM
WhenCreated : 3/23/2007 11:06:54 AM
OriginatingServer : GC01.tpworld.local
IsValid : True

9. Have your users log out of OWA and log back in and when they click on the address list tab they should now see the All Rooms address list.

Dave

Creating a new mailbox in Exchange 2007 with the new-mailbox cmdlet fails with Address List Service not Available

When creating mailboxes in Exchange 2007 the mailbox API's must have access to a domain controller in order to apply recipient polices for stamping purposes. Under certain conditions creating a new mailbox with the Exchange 2007 ESM or using the following Powershell cmdlet (new-mailbox) will fail with the following error:

Event ID: 8325
Event Category: Address List Synchronization
Event Source: MSExchangeAL
Event Type: Error
Date: 5/1/2007
Time: 1:52:04 PM
Description: The service can't work properly because Email Address Policy 'CN=XXXX,CN=Recipient Policies,CN=Corp,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=OAB,DC=com' has an invalid filter rule (PurportedSearch). The error is 'Invalid token.'. Use the Exchange Management Console to correct this problem. New users, contacts, and groups won't be fully provisioned until this is fixed.

If you are running setup for the first time you might also see this error:

Event ID: 1002
Event Category: Microsoft Exchange Setup
Event Source: MSExchangeSetup
Event Type: Error
Date: 5/1/2007
Time: 1:46:43 PM
Description: Exchange Server component Mailbox Role failed. Error: The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error.

You might also see the following text in your ExchangeSetupLog file:

[11/10/2007 2:21:49 PM] [2] Applying RUS policy to the given recipient "MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e" with the home domain controller "COMPUTERNAME.domain.com".

[11/10/2007 2:21:49 PM] [2] [ERROR] The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error.

[11/10/2007 2:21:49 PM] [1] Exception : Microsoft.Exchange.Configuration.MonadDataProvider.MonadDataAdapterInvocationException: The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error. It was running command '$error.Clear(); $count=0; $ExchangeServers = Get-ExchangeServer -DomainController $RoleDomainController; foreach($server in $ExchangeServers) { if(($server.AdminDisplayVersion.Build -gt 641) -and ($server.IsMailboxServer -eq $true)) { $count++; } } if( $count -eq 1) { Set-OrganizationConfig -DomainController $RoleDomainController; }'. ---> Microsoft.Exchange.Data.Directory.RusServerUnavailableException: The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error.
at
Microsoft.Exchange.Data.Directory.Recipient.RecipientUpdateService.LocateServer()
at
Microsoft.Exchange.Configuration.Tasks.RecipientTaskHelper.ApplyRusPolicy(ADSystemConfigurationSession configurationSession, ADRecipientSession recipientSession, ADRecipient recipient, Fqdn domainController, String serverName, TaskVerboseLoggingDelegate logHandler, TaskWarningLoggingDelegate writeWarning)
at
Microsoft.Exchange.Configuration.Tasks.RecipientTaskHelper.ApplyRusPolicy(ADSystemConfigurationSession configurationSession, ADRecipientSession recipientSession, ADRecipient recipient, Fqdn domainController, String serverName, TaskVerboseLoggingDelegate logHandler, TaskErrorLoggingDelegate writeError, TaskErrorLoggingDelegate throwTerminatingError, TaskWarningLoggingDelegate writeWarning)

--- End of inner exception stack trace ---

at
Microsoft.Exchange.Configuration.MonadDataProvider.MonadCommand.ClosePipeline(MonadAsyncResult asyncResult)
at
Microsoft.Exchange.Configuration.MonadDataProvider.MonadCommand.EndExecute(MonadAsyncResult asyncResult)
at
Microsoft.Exchange.Management.Deployment.ComponentInfoBasedTask.ExecuteScript(Stringscript, Boolean handleError, Int32 subSteps, LocalizedString statusDescription)
at
Microsoft.Exchange.Management.Deployment.ComponentInfoBasedTask.GenerateAndExecuteTaskScript(InstallationCircumstances installationCircumstance)

[11/10/2007 2:21:49 PM] [1] [WARNING] An unexpected error has occurred and a Watson dump is being generated: The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error. It was running command '$error.Clear(); $count=0;
$ExchangeServers = Get-ExchangeServer -DomainController $RoleDomainController; foreach($server in $ExchangeServers) { if($server.AdminDisplayVersion.Build -gt 641) -and ($server.IsMailboxServer -eq $true)) { $count++; } } if( $count -eq 1) { Set-OrganizationConfig -DomainController $RoleDomainController; }'.

[5/18/2007 2:21:49 PM] [1] [ERROR] The Exchange server address list service failed to respond. This could be because of an address list or email address policy configuration error. It was running command '$error.Clear(); $count=0; $ExchangeServers = Get-ExchangeServer -DomainController $RoleDomainController; foreach($server in $ExchangeServers) { if(($server.AdminDisplayVersion.Build -gt 641) -and ($server.IsMailboxServer -eq $true)) { $count++; } } if( $count -eq 1) { Set-OrganizationConfig -DomainController $RoleDomainController; }'.

[11/10/2007 2:28:29 PM] [0] End of Setup

There are 6 causes for this error at this time:

1. The CN=Public Folders object is missing under CN=All Address Lists in the Active Directory directory service.

2. The Allow inheritable permissions from the parent to propagate to this object and all child objects check box is *not selected* on the CN=All Address Lists object and on the CN=Public Folders object. This checkbox must exist on both objects.

3. You are using an invalid LDAP search filter on your address list. LDAP queries are used in filter rules to specify the recipient membership of address lists and recipient policies. A malformed filter can cause the Recipient Update Service (in Exchange 2003) or (The RUS API's in Exchange 2007) not to process the email or recipient policy. This will cause new mailboxes in Exchange 2007 not to be created as well as your user account attributes to not update as expected. 

How to fix cause 3: If you using Exchange 2003 and you are trying to find users by groups you should be using the custom attributes that are available on the user object. By default if you use the Exchange Query Builder to create a filter for your Address List, Global Address List or Email policy it will look something like this:

(&(&(objectCategory=contact)(extensionAttribute1=fd)(&(&(&(|(&(objectCategory=person)(objectSid=*)(!samAccountType:1.2.840.113556.1.4.804:=3))(&(objectCategory=person)(!objectSid=*))(&(objectCategory=group)(groupType:1.2.840.113556.1.4.804:=14)))(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) )))(objectCategory=user)(extensionAttribute1=fd)))))

NOTE: extensionAttribute1 is what is on the Exchange 2003 side. On Exchange 2007 this maps to the CustomAttribute attribute.

Next from there the correct way to create the LDAP filter for an Address List is to do the following:

1. Right click your address list
2. Select the 'Advanced Tab' on the "Find Exchange Recipients Tab"
3. Select 'Field'
4. Select 'User'
5. Select 'Custom Attribute #'
6. Change the 'Condition" to: Is (exactly)
7. Add your value.

Once you have created your filter the way I listed above you will have something that looks like this: (&(objectCategory=group)(extensionAttribute1=YourCustomAttribute1-10))

The Windows Query Engine has a limitation when you try to add groups with an 'OR' and it will break the filter. You will need to modify the filter as below if you want to also add contacts and groups to your filter.

(|(&(objectCategory=user)(extensionAttribute1=YourCustomAttribute1-10))(&(objectCategory=group)(extensionAttribute1=YourCustomAttribute1-10))(&(objectCategory=contact)(extensionAttribute1=YourCustomAttribute1-10)))

1. Apply this filter to the All Address List in choice: (&(&(|(&(objectCategory=user)(extensionAttribute1=YourCustomAttribute1-10))(&(objectCategory=group)(extensionAttribute1=YourCustomAttribute1-10))(&(objectCategory=contact)(extensionAttribute1=YourCustomAttribute1-10)))))
2. Apply this filter to the Globla Address List in choice: (&(&(|(&(objectCategory=user)(extensionAttribute1=YourCustomAttribute1-10))(&(objectCategory=group)(extensionAttribute1=YourCustomAttribute1-10))(&(objectCategory=contact)(extensionAttribute1=YourCustomAttribute1-10)))))
3. Go to your Email policy in the Exchange 2003 ESM and pull up the Recipient filter and changed that filter to the same one as above. 

NOTE: The Email Policy custom search is linked to the PurportedSearch attribute on the Email Policy. This is what Exchange 2007 is looking for when it tries to stamp a user.

4. Replicate the domain controllers.
5. Mailboxes now are able to be created!!!

4. You modified an attribute of an address lists with an invalid value such as NOT SET. When the active directory resets an attribute value it will be set back to <Not Set>. In the cases that we have seen this in the object in question was the Default Global Address List.

5. The virtual server name is missing from the active directory. If this is the case you will see the following event id in the application log:

Event ID : 9317
Raw Event ID : 9317
Record Nr. : 4178596
Category : General
Source : MSExchangeSA
Type : Error
Generated : 3/12/2008 12:08:47 AM
Written : 3/12/2008 12:08:47 AM
Machine : ExchangeCluster-Node1
Message : Failed to register Service Principal Name for exchangeRFR; error code was c10379bc.

6. The System Attendant service has not started. Some times there can be a dependency problem and the System Attendant will not start even know your other Exchange services have.

7. Check to make sure that TCP Chimney functionality has been disabled. For more information on what the Scalable Networking Pack is: see here: http://www.microsoft.com/whdc/device/network/TCP_Chimney.mspx and http://msexchangeteam.com/archive/2007/07/18/446400.aspx.

To disable TCP Chimney, you can do this one of two ways and does not require a reboot.:

To Disable TCP Chimney, Navigate to the following registry key and set the value to 0. Note: You have to reboot the server after this registry change.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableTCPChimney"=dword:00000000

Or you can use the netsh command which I prefer without having to reboot:

Netsh int ip set chimney DISABLED

If that does help with the situation, you could also try disabling the following offloading keys under the above registry hive to disable the RSS features.

"EnableTCPA"=dword:00000000
"EnableRSS"=dword:00000000

Exchange 2007 uses OPATH filters instead of LDAP filters. For more information on OPATH you can see this blog: http://msexchangeteam.com/archive/2007/01/10/432143.aspx

Dave