Historically the method used to provide this segmentation varied between versions of Exchange as the product evolved in design and implementation and until now had not been supported with Exchange 2010.

The Exchange Customer Experience Team has heard the feedback our customers have provided to us and are now working to incorporate a set of features that will provide a Global Address Segmentation capability directly into Service Pack 2, which will be available to customers in the second half of 2011. We plan on posting more about Service Pack 2 in the next couple of weeks.

This decision was taken in order to simplify the deployment and configuration of the feature for all customers by providing a consistent and controlled experience through the standard Exchange management interface.

As a result of the decision to build the functionality into the product, we have also decided that we will not release an updated version of the Configuring Virtual Organizations and Address List Segregation Whitepaper that was published for Exchange Server 2007.

This decision is not one that was taken lightly, but was considered necessary given the scope of the changes that will be introduced into the product with the introduction of the GAL Segmentation feature and the need to provide customers with a clear upgrade path which did not require them to revert a series of previously implemented manual changes.

If you are currently blocked from deploying Exchange 2010 because of a need for this feature in your environment we encourage you to watch for the updated guidance from Microsoft as the feature is developed, then plan your migration accordingly.

In order to provide transparency in these early stages of development, our intentions for this feature are:

This feature is not intended to enable the On-Premises configuration of Exchange 2010 to be used in place of the multi-tenant enabled version of the Exchange 2010.

Our intended audiences for this feature are organizations that:

• Require some form of sub-divided address book or who wish to create several 'virtual' organizations within a single Exchange Organization.
• Enable users to share some resources between these segmented user populations.
• Seek to control which objects are visible to a user when they open their address book picker.

The way we intend to deliver this feature is by using an "Address Book Policy" assignment model, rather than continuing with the ACL based GAL Segmentation concept we previously provided. This approach is not intended to provide complete tenant isolation as is provided in the Hosting mode available in Exchange 2010 SP1, rather it is intended to allow an administrator to grant access to certain views of the GAL rather than restricting views.

If you intend to resell Exchange 2010 mailboxes by using the feature we are introducing, in what is generally recognized as a hosting configuration, we strongly recommend that you instead evaluate the Hosting mode of Exchange available since the release of Service Pack 1. Should you choose to further customize the On-premises configuration to meet requirements for multi-tenancy your configuration may not be supported by the Exchange team. The hosting mode of the product has been designed with true multi-tenancy capability in mind and is our strategic platform that we recommend customers who wish to host Exchange mailboxes adopt going forward. Likewise, if you are interested in privately hosting Exchange for the rest of your company, it is strongly advised to consider the limitations and extra requirements associated with the multi-tenant version of Exchange and decide if you truly will need the full functionality or if you only require Address Book Policies.

We hope this announcement will be welcome news to many of our customers and look forward to receiving your comments and announcing more detailed information as we continue to develop the feature.

Kevin Allison
General Manager, Exchange Customer Experience

Please rest assure that there will be a public announcement in the next few weeks here on my blog site detailing all of our work around Address List Segregation for Exchange 2010, and the direction we will be taking.

I also want to be clear that installing Exchange 2010 SP1 will not help you with address list segregation and it is still not supported. You still have to wait until the official statement is released.

Thanks

Dave

Event Type: Error
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9373
Description: OALGen detected that the file '\\<SERVER name>\ExchangeOAB\<folder name>\a58e388b-7b23-4944-b042-58a7d0c6590f-data-1.lzx' is corrupted or missing. This indicates data tampering or disk problems. Restore files in this folder from the recent backup or clean up folder content and force a full OAB generation. - Default Offline Address Book

You must exclude specific directories for each Exchange server or server role on which you run a file-level antivirus scanner. This section describes the directories that you should exclude from file-level scanning for each server or server role.

Mailbox server role

• Exchange databases, checkpoint files, and log files across all storage groups. By default, these are located in sub-folders under the %Program Files%\Microsoft\Exchange Server\Mailbox folder. You can obtain the directory location by running the following commands in the Exchange Management Shell:
  • To determine the location of a transaction log and checkpoint file, run the following command: Get-StorageGroup -server <servername>| fl *path*
  • To determine the location of a mailbox database, run the following command: Get-MailboxDatabase -server <servername>| fl *path*
  • To determine the location of a public folder database, run the following command: Get-PublicFolderDatabase -server <servername>| fl *path*
• Database content indexes. By default, these are located in storage group sub-folders under the %Program Files%\Microsoft\Exchange Server\Mailbox folder.
• General log files, such as message tracking log files. These files are located in subfolders under the %Program Files%\Microsoft\Exchange Server\TransportRoles\Logs folder and %Program Files%\Microsoft\Exchange Server\Logging folder. To determine the log paths being used, run the following command in the Exchange Management Shell: Get-MailboxServer <servername>| fl *path*
• The Offline Address Book files that are located in subfolders under the %Program Files%\Microsoft\Exchange Server\ExchangeOAB folder
• IIS system files in the %SystemRoot%\System32\Inetsrv folder
• The temporary folder that is used with offline maintenance utilities, such as Eseutil.exe. By default, this folder is the location where the .exe file is run from. However, you can configure where you perform the operation from when you run the utility.
• The temporary folders that are used to perform conversions:
  • Content conversions are performed in the server’s TMP folder.
  • OLE conversions are performed in %Program Files%\Microsoft\Exchange Server\Working\OleConvertor folder.
  • The Mailbox database temporary folder: %Program Files%\Microsoft\Exchange Server\Mailbox\MDBTEMP
• Any Exchange-aware antivirus program folders

Client Access server role

• The Internet Information Services (IIS) 6.0 compression folder that is used with Microsoft Outlook Web Access. By default, the compression folder in IIS 6.0 is located at %systemroot%\IIS Temporary Compressed Files.
  For more information, see the Microsoft Knowledge Base article 817442, A 0-byte file may be returned when compression is enabled on a server that is running IIS.
• IIS system files in the %SystemRoot%\System32\Inetsrv folder
• The Internet-related files that are stored in the sub-folders of the %Program Files%\Microsoft\Exchange Server\ClientAccess folder
• The temporary folder that is used to perform content conversion. By default, this is the server’s TMP folder.

For more information please see: https://technet.microsoft.com/en-us/library/bb332342(EXCHG.80).aspx

For more information on how to restore the contents of your OAB directories please see this blog: https://blogs.msdn.com/dgoldman/archive/2009/08/28/event-id-9373-is-logged-in-the-application-log-when-you-update-the-offline-address-book-in-exchange-server-2007.aspx

Dave

1. We all know and agree that many customers are looking for this whitepaper to be completed. This *IS* a top priority for us, however this is going to take some time to complete.
2. There is *NO* guarantee that the whitepaper will be completed by the release of SP1 for Exchange 2010 which is targeted for the 2nd half of the 2010 calendar year.

I need to mention the support stances here.

1. There is *NO* support for Exchange 2003 address list segregation.
2. There is *NO* supported upgrade path from Exchange 2003 address list segregation to anything.
3. If you have a mixed organization (Exchange 2003 and Exchange 2007) you must have everything on Exchange 2007 for you to be in a supported configuration. For more information on this please see this blog: https://blogs.msdn.com/dgoldman/archive/2008/02/17/exchange-2007-address-list-segregation-document-updates.aspx This blog clearly defines the support stance and what needs to be done to migrate.
4. There *IS* support for a native organization using Exchange 2007 and address list segregation if you have followed the Exchange 2007 address list segregation whitepaper.
5. There is *NO* supported upgrade path from Exchange 2007 using Address List Segregation to Exchange 2010 using Address List Segregation.
6. There is *NO* support at this current time for Exchange 2010 using Address List Segregation until the whitepaper has been approved and published to the web.
7. If you are using the 2007 address list segregation whitepaper to host customers and you run in to a problem, you will be told that you are using an unsupported configuration. At this point you will need to remove the address list segregation in order to receive support. This is documented in the 2007 Address List Segregation whitepaper https://technet.microsoft.com/en-us/exchange/bb936719(EXCHG.80).aspx#Unsupp

“It is also important to understand that any attempt to use this whitepaper to configure Exchange 2007 for a commercial "hosting" solution is not supported. This whitepaper is not a replacement for the Microsoft HMC (Hosting and Collaboration) software. The information that is provided in this whitepaper is meant for internal segregation use only.”

If you are planning on using Exchange 2010 and you currently have Exchange 2007 using Address List segregation *YOU MUST* remove all address list segregation from your organization to avoid running into the bug that we are currently working on at this time. PLEASE HEED THIS WARNING!!

In order to revert your organization back to a default exchange installation permission set you can follow this blog: https://blogs.msdn.com/dgoldman/archive/2007/05/16/missing-permissions-on-the-address-lists-container-breaks-the-oab-generation-process.aspx and https://blogs.msdn.com/dgoldman/archive/2008/04/03/how-to-prepare-your-organization-for-exchange-2007-address-list-segregation.aspx

I mentioned that I would speak about the nature of this problem. Due to the architectural changes in Exchange 2010, Address Book queries are performed in a different way than we did in prior versions of Exchange. I am not going to explain this in full, however you can view this blog for those new component changes: https://blogs.msdn.com/dgoldman/archive/2010/03/15/exchange-2010-address-list-segregation-update.aspx

The problem that I ran in to was that if you already had the deny permission set on the default global address list from using the 2007 Address List segregation white paper and you have installed Exchange 2010 the exchange server will not have the ability to read the default global address list. At this point the default global address list object would be removed from all of the objects showInAddressList attribute. Here is what happens once this occurs:

1. Users will start missing from the default global address list
2. Users in their respective companies will no longer show up in that companies global address list
3. Users can show up in another companies global address list
4. Outlook users crash upon logging in to their mailbox

Your only option to fix this

1. Keep your Exchange 2010 servers intact.
2. You will need to reset the ACL's on the default global address list. This means you will need to reapply the 'Read' and 'Open Address List' for the Authenticated Users group.
3. You will need to open up powershell and run the following command "update-globaladdresslist"
4. Run Get-Mailbox | set-mailbox -ApplyMandatoryAttributes

WARNING: In the event that this does not fix it for any objects in your organization this becomes a manual fix from here. You will need to look up the object that is still having a problem using ADSIEdit.msc and look at the showInAddressList attribute. You will need to add the legacyExchangeDN for the default global address list and this will fix the problem for that object.

NOTICE: This blog has been approved by the Microsoft Exchange Product Group.

Dave

For more information please see: KB Article 972076  (https://support.microsoft.com/kb/972076/ ) Description of Update Rollup 2 for Exchange Server Service Pack 2

To resolve this problem, follow these steps: Install Update Rollup 2 for Exchange Server 2007 Service Pack 2 on the Exchange server.

1. Locate the Web.config file in the following folder:
%ProgramFiles%\Microsoft\Exchange Server\ClientAccess\exchweb\EWS
2. Open the Web.config file in Notepad, and then locate and add the following line between the <appsettings> element and the </appsettings> element: <add key="UseLocalReplicaForFreeBusy" value="true" />

NOTE: If the value of the key "UseLocalReplicaForFreeBusy" is true, Exchange Server 2007 CAS checks if there is a replica for the Exchange Server 2003 users on a local public folder server. If there is a replica available, Exchange Server 2007 CAS uses the replica instead of a low bandwidth WAN connection.

3. Save the Web.config file and then restart the Exchange Web Service on the Exchange Server 2007 server.
4. Do the same change in the Web.config file located in: %ProgramFiles%\Microsoft\Exchange Server\ClientAccess\OWA

Dave

There are two locations for this directory:

1. Exchange 2007 - x:\Program Files\Microsoft\Exchange Server\ExchangeOAB
2. Exchange 2010 - x:\Program Files\Microsoft\Exchange Server\V14\ExchangeOAB

If this folder is deleted, OABGen will check for it and re-create it.

The following permissions are set to this folder:

• Allow SYSTEM Full Control
• Allow Administrators: Full Control
• Allow Exchange Servers:
  • Traverse Folder
  • List Folder
  • Read Attributes
  • Read Extended Attributes
  • Read Permissions
  • CONTAINER_INHERIT (folder and subfolders permissions)
• Allow Exchange Servers:
  • Read Data
  • Read Attributes
  • Read Extended Attributes
  • Read Permissions
  • CONTAINER_INHERIT + OBJECT_INHERIT (folder, subfolders and files permissions)

Dave

I will keep everyone posted.

Dave

Around the E14 Service Pack 1 time frame we will be making the following changes:

1. The 9320 Event ID we be changed to log at a Low event and not Lowest.
2. The 9359 Event ID will be changed from the a Warning category to Informational category.

This is by DESIGN. These warnings are 100% expected and can be ignored. These new changes will reduce the amount of logging noise in the application logs.

Dave

With that being said I wanted to post some information that is a *must read*. This information is pretty generic, however you must be aware of the changes in the Exchange product before you start playing with Address List Segregation on an Exchange 2010 platform.

Exchange 2010 now has an Address Book Service - In earlier versions of Microsoft Exchange prior to Exchange Server 2010, the Exchange server provided a referral service that told Outlook clients where they could find a domain controller that registered the NSPI service as a connection point. This referral would direct the Outlook client NSPI address book queries to a global catalog server. In addition, some Outlook Anywhere connections could also point the Outlook client back to the local server, and then the local server’s NSPI calls will be proxied to a global catalog server in the local site.

The Outlook client expects to find this referral service on the same server that's used for mailbox access. In Exchange 2010 now both mailbox access and directory access are handled by the Client Access server.

When an Outlook client contacts a Client Access server there are a few possible things that can happen.

1. If the user's mailbox is on an Exchange Server 2007 Mailbox server or an Exchange Server 2003 server, the directory request is referred to the user's mailbox server.
2. If the user's mailbox is on an Exchange 2010 Mailbox server, then one of two actions happens.
3. If the user's mailbox is in the same site as the Client Access server, the request is referred to the Client Access server.
4. If the user's mailbox is in a different site, the request is referred to a Client Access server in the remote site.

Now for Exchange 2010, the Client Access server will facilitate both the Referral Service and the NSPI endpoint. These two components are necessary for directory access to flow through the Client Access server.

IMPORTANT NOTE: If your Client Access server roll is installed on a domain controller the Outlook will communicate directly with the domain controller. This will bypass the Client Access server all together and revert the Exchange functionality back to as it is in Exchange 2007. 

The Exchange 2010 Address List Segregation white paper is being tested on a multiple machine setup with the domain controller NOT hosting ANY exchange roles.

If you are running Exchange 2010 on a domain controller clients will by pass MAPI and Domain on the Middle Tier. THIS IS NOT SUPPORTED FOR ADDRESS LIST SEGREGATION for the reason that if you switch your roles from the domain controller to a new server you will break your address list segregation functionality.

Thanks

Dave

Dave