[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

CONFIDENTIAL EXCHANGE SERVER "12" BETA 1 DOCUMENTATION

See the "Legal Notice" section later in this document for important information.

Welcome to the Beta 1 release of Microsoft® Exchange Server "12".

This document contains important and late-breaking information about the Beta 1 release of Exchange Server "12", including installation prerequisites, download instructions, known issues, where to find support and provide feedback, and legal information.

Note:
Unless you are a current and authorized participant in an Exchange Technology Adoption Program, this Beta 1 release is not intended for production use, and it is not supported in a production environment.

This document contains the following sections:

Prerequisites

Before you can install Exchange Server "12", make sure that your host computer meets the following hardware and software requirements.

Hardware Requirements

  • Processor   Any of the following:

    • 32-bit Intel Pentium or compatible 800 megahertz (MHz) or faster

    • 64-bit Intel Xeon Pentium 4

    • 64-bit AMD Opteron

  • RAM   512 megabytes (MB) is the recommended minimum.

  • Available disk space   At least 1 gigabyte (GB) of available space on the drive on which you are installing Exchange Server "12" and 200 MB of available space on the system drive.

Software Requirements

  • Microsoft .NET Framework 2.0   Exchange Server "12" is built on Microsoft .NET Framework 2.0. If not already present, this requirement is installed automatically by Setup.

  • Internet Information Service (IIS)   The World Wide Web Publishing service (W3SVC) is required for the Client Access Server and Mailbox Server Roles. In addition, the Client Access Server Role also requires ASP.NET.

  • Microsoft Management Console (MMC) 3.0   The most recent build of MMC needs to be installed. To download the latest MMC release, see Microsoft Management Console 3.0 Pre-Release (RC1 Refresh).

  • Exchange Organization Operation mode set to Native Mode   The Exchange Operation mode for the organization must be Native Mode.

  • Active Directory Domain Functional Level set to Windows 2000 Native or greater   This domain functional level is required to support the new Exchange Servers universal group.

  • Schema Master must be Microsoft Windows Server™ 2003 Service Pack 1 or greater   The server that holds the Schema Master Flexible Single Master Operation (FSMO) role needs to have Windows Server 2003 or greater installed.

  • Windows Server 2003 hotfix 904639   For more information about this hotfix that is related to 64-bit installations, see Microsoft Knowledge Base article 904639, "An access violation may occur when you try to run a 64-bit program that uses the interface remoting component of MDAC 2.8 on a computer that is running Windows Server 2003." The article includes links to the hotfix.

    Important:
    Installing the 32-bit version of Exchange Server "12" is supported in testing or training environments, but it is not supported in production environments. In production environments, you must install the 64-bit version of Exchange Server "12", except for the Unified Messaging Server Role. In Beta 1, the Unified Messaging Server Role is only available in 32-bit, and it is supported in production.

Download Exchange Installation Files

How to download Exchange Server 12 Beta 1

  1. Log on to the server where you want to install Exchange Server "12".

  2. On the drive where you want to download the Exchange installation files, create a directory called Exchange12. For example, C:\Exchange12.

  3. Go to the Microsoft Connect site. If you are installing Exchange on a 64-bit server, select the 64-bit download from the Microsoft Connect site.

  4. If you are installing Exchange on a 32-bit server, select the 32-bit download from the Microsoft Connect site.

  5. When prompted for the location to download the files, navigate to the Exchange12 directory that you created in Step 2, and click OK.

Known Issues

In this release of Exchange Server "12", the following known issues exist:

  • Some user interface elements are inconsistent with the documentation. Specifically, two differences in terminologies exist:

    • Exchange Management Console   In the Exchange program group on the Start Menu, the name of the shortcut for Exchange System Manager is Exchange Management Console. The Exchange Management Console is the new name for Exchange System Manager, and these names can be used interchangeably. In later releases of Exchange Server "12", it is expected that the final name will be Exchange Management Console.

    • Local Continuous Replication   In the user interface for Exchange Server "12", the term Local Continuous Backup is used. The new name for this feature is Local Continuous Replication. In later releases of Exchange Server "12", it is expected that the final name will be Local Continuous Replication.

  • There is no graphical user interface for configuring Bridgehead servers. Therefore, the Exchange System Manager user interface for Bridgehead servers is blank.

  • Although the Help file procedures for installing Exchange Server "12" state that Setup.exe will install MMC 3.0, this behavior does not occur. You must manually install MMC 3.0 before you start Setup.exe for Exchange Server "12". To download the latest MMC release, see Microsoft Management Console 3.0 Pre-Release (RC1 Refresh).

  • In the Beta 1 release of Exchange Server "12", you must install Exchange into a root domain. You cannot install Exchange Server "12" into a child domain. If a root domain is not available, we recommend that you install Beta 1 in a resource domain. This issue will likely be resolved in the next beta release of Exchange Server "12"; therefore, disregard this issue when making future Exchange Server "12" design decisions. For more detailed information about resource forests, see "Active Directory Forest Topologies for Exchange Server "12"" in the Exchange Server "12" Help documentation. For more detailed information about how to enable a linked mailbox, see "How to enable a linked mailbox for a resource" later in this document.

  • Currently, installing the first server that is running Exchange Server "12" in an existing organization forces a full offline address book (OAB) download for clients using offline address lists.

  • Beta 1 of Exchange Server "12" includes a script that is designed to return information on invalid recipient objects in your Exchange organization and, if possible, attempt to fix them. CheckInvalidRecipients.msh, which is located in the Scripts directory of your Exchange installation, attempts to fix the following two classes of problems:

    • Primary SMTP Address Problems   If a recipient has multiple SMTP addresses listed as their primary SMTP address, or if a user's primary SMTP address is invalid, the script tries to set the user's WindowsEmailAddress as their primary SMTP address. The user's WindowsEmailAddress is the address that Exchange Server 2003 recognizes as the primary address, but Exchange Server "12" does not.

    • Distribution Group Hidden Membership   If a distribution group has HideDLMembershipEnabled set to true, but ReportToManagerEnabled, ReportToOriginatorEnabled, and/or SendOofMessageToOriginatorEnabled are set to true, the membership is not actually hidden. The script will set ReportToManagerEnabled, ReportToOriginatorEnabled, and SendOofMessageToOriginatorEnabled to false to properly hide the distribution group membership.

  • The Exchange Server "12" Gateway Server Role has not finished the security pass, and is therefore unsupported as an external server or exposed to the Internet. Therefore, a server that is running Exchange Server 2003 should be used to accept mail directly from the Internet.

  • There is currently no user interface or command-line parameter to specify authoritative domain. The authoritative domain is the domain or domains for which the Exchange server will receive mail. To set this parameter, you must manually edit the domains.config file. For more detailed information, see "How to set a domain as authoritative for inbound e-mail" later in this document.

  • If any firewall, including Windows Firewall, is enabled on a server that is running Exchange that supports POP3 and IMAP4 clients, ports 5000-6000 must be open or you will experience connection issues.

  • On a server that has both the Client Access Server and Mailbox Server Roles installed, you cannot remove the Client Access Server before or at the same time that you remove the Mailbox Server. The Client Access Server must be removed first, and then the Mailbox Server can be removed.

  • When Exchange Server "12" is deployed for coexistence and interoperability with Exchange Server 2003, you must manually configure the required permissions. Exch50 data must be sent over an authorized connection. For information about how to configure the permissions, see "Exchange Server "12" and Exchange Server 2003 Interoperability" later in this document. For more detailed information about how to configure interoperability, see "How to Configure Interoperability Permissions in This Pre-Release Version of Exchange Server "12"" in the Help documentation.

  • For Exchange bridgehead servers in different forests to successfully exchange mail, you need a two-way forest trust between the forests and you must configure the access control on both servers to authorize the external forest servers for mail exchange. For more information about how to set up bridgehead servers to exchange mail with server in other forests, see “How to Set Up Cross-Forest Bridgehead Connections" later in this document.

  • Microsoft Operations Manager (MOM) does not properly detect the path to MSH.exe on bridgehead, gateway, and unified messaging servers that are not co-located on a computer with the Mailbox or Client Access Server Roles. This prevents MOM from running the diagnostic task commands test-ServiceHealth and test-UMConnectivity on these servers. To correct this, add the following registry value to the 32-bit registry on all Exchange Server "12" servers that do not have the Mailbox or Client Access Role installed:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Setup\

    Value: Services

    Type: REG_SZ

    Value data: path to your Exchange directory (for example, D:\Program Files\Microsoft\Exchange Server)

    To access and edit the 32-bit portion of the registry on the 64-bit version of Windows Server 2003, run %windir%\syswow64\regedit.exe.

  • During Exchange Server "12" setup, the prerequisite check looks for an ASP.NET registry key. This registry key remains after ASP.NET is uninstalled from the system. The presence of the registry key allows the prerequisite check to pass, even though ASP.NET is not installed. After the registry key is deleted, the prerequisite check operates correctly.

  • Currently, the Exchange Server "12" Exchange System Manager does not support modifying the Spam Confidence Level (SCL) parameter for a mailbox database. To work with the SCL parameter for the mailbox database, use one of the following methods:

    • If your organization has servers that are running Exchange Server 2003, use the Exchange Server 2003 Exchange System Manager.

    • If your organization does not have servers that are running Exchange Server 2003, use the latest version of the Exchange Server 2003 System Management Tools on a machine running Windows® XP with Service Pack 2. See the Exchange Server 2003 documentation for installation steps.

  • On a Gateway server, if the Exchange Gateway Manager is open when new send or receive connectors are created in the Exchange Management Shell, the Exchange Gateway Manager must be closed and then reopened for the connectors to be visible in the Exchange Gateway Manager. Connectors created using the Exchange Gateway Manager will appear dynamically after they are created.

  • Boolean parameters in the Exchange Management Shell require the use of a colon as a separator between the Boolean parameter name and the Boolean value. Omitting the colon will cause the command to fail. For example, the following syntax is correct: Set-SendConnector "Contoso.com Outbound" -DnsRoutingEnabled:$true The following syntax is not correct: Set-SendConnector "Contoso.com Outbound" -DnsRoutingEnabled $true

  • In the Exchange Management Shell, the only values that can be submitted to Boolean parameters are $true and $false. Currently, there is no error if an invalid value is submitted. Submitting invalid values such as true or false to a Boolean parameter may cause the command to interpret the value as $true, which may cause unexpected results if the Boolean value that was intended to be submitted was $false.

  • The syntax block conventions used in the Exchange Management Shell command line Help do not match the syntax block conventions used in the Exchange Server "12" Help file. For detailed accurate syntax block help, see the Technical Reference documentation in the Exchange Server "12" Help file located in Technical Reference\Language Reference\Exchange Management Shell.

  • When you attempt to copy a code sample from an Exchange Management Shell Reference Topic in the Exchange Server "12" Help file into the Exchange Management Shell, the command fails. This failure occurs because the code sample in the reference topic uses a different ASCII character than that expected by the Exchange Management Shell. As a work-around solution, you can copy the code sample into a text editor, such as Notepad. Then, replace all high-ASCII characters, which will appear as blocks, with regular hyphens. Finally, copy the code sample from Notepad into the Exchange Management Shell. In addition, you can go to the Web site where you downloaded the Exchange Server "12" Beta 1 product bits and separately download an updated version of the Help file (exchhelp.chm) which resolves the issue.

  • The topic "Configuring Bridgehead Server SMTP Connectors" in the Help file (exchhelp.chm) contains an Exchange Management Shell command procedure, and example that could lead an administrator to inadvertently configure an Exchange Server "12" server as an open SMTP relay. Running as an open relay enables unauthenticated systems to send unauthorized e-mail messages using your e-mail server. For this reason, the procedure and command example have been removed from the topic. Using the command: get-receiveconnector -server %COMPUTERNAME% | set-receiveconnector -AnonymousAllowed:$true -RelayControl:Open should only be used in a test lab environment that cannot be accessed from the Internet or any other untrusted network.

  • The Help topic "How to Create Bridgehead Server Connectors" explains how to configure connectors for interoperability between Exchange Server "12" bridgehead servers and Exchange Server 2003 bridgehead servers. This topic contains a procedural error. It is not necessary to create an SMTP connector from the Exchange Server 2003 routing group to the Exchange Server "12" default routing group. Instead, the routing group connector that is created between Exchange Server "12" and Exchange Server 2003 routing groups must be configured to be a two-way connector. In Step 1G of the documented procedure, click Yes to create a two-way connector. Step 2 is not needed.

  • Support for multipart/AppleDouble attachments is not implemented in Exchange Server "12" Beta 1. Outbound messages from Exchange Server "12" with a multipart/AppleDouble attachment fail to be delivered. Inbound mail to Exchange Server "12" with a multipart/AppleDouble attachment is delivered, but the attachment may be incorrectly formatted. Support for multipart/AppleDouble attachments may be added in the next beta release of Exchange Server "12".

  • If the mailbox database containing the System Attendant mailbox is deleted, move mailbox operations will fail on the server from which move mailbox is being run. The failure error is: "Error was found for <mailbox name> because: The information store could not be opened. The MAPI provider failed. MAPI 1.0 ID no: 8004011d-0289-00000000, error code: -1056636928". To resolve this error, create a database on the server, and the System Attendant mailbox will be automatically re-created.

  • New global rules that are created with Exchange System Manager are missing configuration information that was previously entered. This situation occurs when the first primary e-mail address on the recipient is not the primary SMTP address. The workaround is to either choose a different recipient, if possible, or create rules using the Exchange Management Shell.

  • The Japanese version of Exchange Server "12" Beta 1 only has a partially localized user interface, and it has no localized documentation.

  • The path for storage group and database files is localized in the Japanese version of Exchange Server "12" Beta 1. If you create a new storage group, new database, or if you attempt to move database or storage group locations, the operation will fail. To work around this issue, use the Browse button to manually select the paths when performing the above operations.

  • In both the English and Japanese language releases of Exchange Server "12", only the English version of Microsoft Office Outlook® 2003 is supported.

  • The Exchange Server "12" Beta 1 release does not include public folder management tasks. In this release, Exchange Server "12" public folders can be managed in the following ways:

    • If your organization has servers that are running Exchange Server 2003, use the Exchange Server 2003 Exchange System Manager.

    • If your organization does not have servers that are running Exchange Server 2003, use the latest version of the Exchange Server 2003 System Management Tools on a machine running Windows® XP with Service Pack 2. See the Exchange Server 2003 documentation for installation steps.

  • Setup /mode:RecoverServer functionality for the Client Access Server Role is currently limited to servers that are running the English version of Exchange Server "12". When the Client Access Server Role and the Mailbox Server Role are installed on the same server, Setup /mode:RecoverServer will only run on the English version of Exchange Server "12".

  • You may receive the error "RPC Server Not Found" when you attempt to configure agents on a computer that is running the Exchange Edge Server Role. This situation occurs because there are no connectors configured. Message Hygiene agents require that at least one Send connector and one Receive connector be configured. You must create one Send connector and one Receive connector, and then restart the Microsoft Exchange Transport service before you can configure agents on the Edge server.

  • When using Exchange Server "12" System Manager remotely to create or move databases and storage groups, you cannot select or browse the directory. Directory browsing is only available when managing storage groups and databases using the following methods:

    • Connect to the remote server using Remote Desktop Protocol, and then use the local Exchange System Manager on the remote server.

    • Use the following Exchange Management Shell command: 

      New-StorageGroup <SGName> -LogPathFolder <LogFolderName> -SystemPathFolder <SystemFolderName> 
Move-StorageGroupPath <SGName> -LogPathFolder <LogFolderName> -SystemPathFolder <SystemFolderName>
New-MailboxDatabase <MBDBName> -EdbFilePath <EdbFilename>
New-PublicFolderDatabase <PFDBName> -EdbFilePath <EdbFilename>
Move-DatabasePath <DBName> -EdbFilePath <EdbFilename>
  • You cannot administer servers that are running Exchange Server 2003 or Exchange 2000 Server from the Exchange Server "12" System Manager console.

  • You cannot administer Exchange Server "12" servers from the management console of a server that is running Exchange 200x.

  • Servers that are running the Exchange Server "12" Bridgehead Server Role do not allow unauthenticated SMTP mail submission and/or open relay in a default installation. If you need anonymous mail submission and/or open relay features for your testing environment, you must enable this feature. To enable this feature from the Exchange Management Shell, run the following command after setup of the Bridgehead Server Role is complete:

    get-receiveconnector -server %COMPUTERNAME% | set-receiveconnector -AnonymousAllowed:$true -RelayControl:Open"
  • Exchange Server "12" does not support the Exchange Server 2003 Short Message System (SMS)-based Always-up-to-Date solution for mobile devices. Mobile devices that currently use this feature will not be able to use it after their mailbox is migrated to Exchange Server "12".

  • Beta 1 of Exchange Server "12" does not provide support for synchronizing tasks. This situation does not affect users with devices prior to Windows Mobile 5.0. Windows Mobile 5.0 users will see Tasks as an available option on the device; however, even if the user selects Tasks, the device will not synchronize Tasks.

  • Exchange Server "12" does not support S/MIME for mobile devices. Users that are current using Windows Mobile 5.0 with the Microsoft Enterprise Feature Pack against Exchange Server 2003 Service Pack 2 will lose this capability after moving their mailboxes to Exchange Server "12".

  • If you are using Internet Security and Acceleration Server (ISA) between users and Outlook Web Access servers, the ISA Server rule called "Verify Normalization" needs to be turned off to enable Outlook Web Access document access functionality. Exchange Server "12" sends double-encoded spaces in document and folder names that contain spaces, which is a behavior that is blocked by ISA Server. For detailed steps to turn off Verify Normalization in ISA Server 2004, see Reverse Proxy Configurations for Windows SharePoint Services and Internet Security and Acceleration Server.

  • Outlook Web Access segmentation administrator tasks are not functional in Beta 1 of Exchange Server "12".

  • Outlook Web Access segmentation of Windows® SharePoint® Services and UNC access is currently done through the web.config file. For more information about working with the web.config file, see "Document Access" later in this document.

  • Outlook Voice Access is only available in U.S. English, and currently only enabled for the main menu and the calendar. Other menus such as e-mail, contacts, directory, and voice mail require telephone keypad entry. These menus will not respond to speech commands.

  • To enable Unified Messaging, an approved VoIP (Voice over IP) gateway is required to connect Exchange Unified Messaging to a PBX. Current approved gateways are manufactured by Intel and AudioCodes. Exchange Server Unified Messaging uses the VoIP protocols SIP and RTP for voice communication. Because traditional PBX systems do not support these protocols directly, a VoIP gateway is required to convert from traditional telephony protocols to VoIP protocols. For more information about VoIP gateways, see "Understanding Unified Messaging Subscriber Access" and "New Client Features in Unified Messaging" in the Help documentation.

  • Three scripts are available with Exchange Server "12" Beta 1 to install the German, French, and Japanese language packs for Unified Messaging; however, a bug in the Exchange Management Shell prevents these scripts from running properly. You can fix this issue and properly install the required language packs for Unified Messaging by following the procedure "How to Update the Unified Messaging Scripts" later in this document.

How to Set a Domain as Authoritative for Inbound E-Mail

To set an authoritative inbound e-mail domain

  1. Browse to the following folder, where C:\Program Files\Microsoft\Exchange Server is your exchange installation location:C:\Program Files\Microsoft\Exchange Server\TransportRoles\Shared\

  2. Open the domains.config file, and then edit it based on the examples in the file.

    <?xml version="1.0" encoding="utf-8" ?>

<!-- This file is used to store authoritative and non-authoritative domains; -->
<!-- those recipient domains for which domains we accept mail.               -->

<domains>
    <!-- Each domain for which the SMTP server should accept email is listed -->
    <!-- in this section. A domain can have an attribute that tells whether  -->
    <!-- the server is authoritative for the domain or not. Authoritative    -->
    <!-- means the server has access to information about the recipients,    -->
    <!-- and can run recipient filtering. Recipient in non authoritative     -->
    <!-- domains is just accepted and routed to another server, which may or -->
    <!-- may not be authoritative for that domain.                           -->

    <!-- Example entries:                                                    -->

    <!-- Example entry: Authoritative for northwindtraders.com               -->
    <!-- <domain name="northwindtraders.com" authoritative="true" />         -->

    <!-- Example entry: Authoritative for anything under northwindtraders.com -->
    <!-- <domain name="*.northwindtraders.com" authoritative="true" />       -->

    <!-- Example entry: Not authoritative for woodgrovebank.com              -->
    <!-- <domain name="woodgrovebank.com" authoritative="false" />           -->

    <!-- Example entry: An open relay                                        -->
    <!-- <domain name="*" authoritative="false" />                           -->

</domains>

How to Set Up Cross-Forest Bridgehead Connections

Before you begin, make sure that the following two prerequisites are in place:

  • Two-way forest trust must exist between the forests.   For more information, see When to create a forest trust.

  • Address spaces for the primary user address space cannot be divided between the two forests.   For example; forest 1 users can have f1.contoso.com as their primary address space with contoso.com as a secondary address space, and forest 2 users can have f2.contoso.com as the primary address space with contoso.com as a secondary address space.

Forest 1 steps

  1. Create a domain local group in the same domain as the bridgehead server in forest 1 with the name ExternalExchangeServers.

  2. Add the server in forest 2 to the ExternalExchangeServers domain local group. For example, add server1.f1.contoso.com

  3. Create a send connector with the following characteristics on a bridgehead server in forest 1 to send mail to forest 2:

    Setting

    Value

    Type

    ToEnterprise

    AddressSpaces

    Primary address space in forest 2. For example, f2.contoso.com.

    SmartHosts

    FQDN of the bridgehead server in forest 2. For example, server1.f2.contoso.com

    AuthenticationMechanism

    None

    XEXCH50Disabled

    False

  4. Create a receive connector with the following characteristics on the bridgehead server in forest 1 to receive mail from forest 2:

    Setting Value

    Type

    FromEnterprise

    XECH50Enabled

    True

    RelayControl

    Authorized

    TlsCertificateName

    “Exchange Edge Certificate”

  5. Using the Services snap-in, restart the Microsoft Exchange Transport service.
Forest 2 steps

  1. Create a domain local group in the same domain as the bridgehead server in forest 2 with the name ExternalExchangeServers.

  2. Add the server in forest 1 to the ExternalExchangeServers domain local group. For example, add server1.f1.contoso.com.

  3. Create a send connector with the following characteristics on a bridgehead server in forest 2 to send mail to forest 1:

    Setting Value

    Type

    ToEnterprise

    AddressSpaces

    Primary address space in forest 1. For example, foo.contoso.com

    SmartHosts

    FQDN of the bridgehead server in forest 1. For example, server1.foo.contoso.com

    AuthenticationMechanism

    None

    XEXCH50Disabled

    False

  4. Create a receive connector with the following characteristics on the bridgehead server in forest 2 to receive mail from forest 1:

    Setting Value

    Type

    FromEnterprise

    XECH50Enabled

    True

    RelayControl

    Authorized

    TlsCertificateName

    “Exchange Edge Certificate”

  5. Using the Services snap-in, restart the Microsoft Exchange Transport service.

How to Enable a Linked Mailbox for a Resource Forest

To enable a linked mailbox

  1. Create a disabled user in the resource forest by using Active Directory Users and Computers.

  2. Mailbox-enable the disabled user by using Exchange Server "12" System Manager or by using the enable-mailbox command in the Exchange Management Shell.

  3. Use Active Directory Users and Computers to associate the External NT Account. Perform this operation in the forest with users—not in the Exchange forest where the disabled user is located.

Exchange Server 12 and Exchange Server 2003 Interoperability

This procedure explains how to enable interoperability and allow sending of Exch50 data from Exchange Server 2003 to Exchange Server "12" Bridgehead servers and from Exchange Server "12" Edge servers to Exchange Server "12" Bridgehead servers. To accomplish this task, two universal security groups are created during Setup: Exchange2003Interop and EdgeInterop.

To enable interoperability between Exchange Server 12 and Exchange Server 2003

  1. In Active Directory Users and Computers, select the Exchange2003Interop group and add as members each Exchange Server 2003 server that has an Exchange Server "12" server as a remote bridgehead.

  2. Create a new user account, and add that account to the group EdgeInterop. The new user account does not need to be mail-enabled.

  3. On the Edge server, add the user account that you created in Step 2 to the send connector by using Exchange Management Shell commands.

Document Access

Document access is an Outlook Web Access feature that enables users to access documents on file shares and Windows® SharePoint® Services servers that are internal to the organization, for example, stored on internal servers behind a firewall. The following procedure explains how to configure Outlook Web Access for document access.

How to configure the Outlook Web Access Web.config file

  1. Go to the Web.config file, which is located in \\%InstallPath%\Microsoft\Exchange Server\ClientAccess\owa. The file includes the following section by default:

    <appSettings>
    <add key="ConnectionCacheSize" value="100" />
    <add key="MaximumIdentityArraySize" value="100" />
    <add key="ShowDebugInformation" value="1" />
    <add key="EnableRemoteDocumentsAccess" value="3" />
    <add key="BlockedDocumentStoreList" value="" />
    <add key="AllowedDocumentStoreList" value="" />
    <add key="BlockDocumentsFromList" value="True" />
    <add key="UsePhoneticNames" value="false" />
    <add key="EnableRemoteDocumentsAccessFromPublicComputers" value="True" />
    <add key="InternalFQDNSuffixList" value="microsoft.com" />
  </appSettings>

  2. Configure only the following keys by using the following information:

EnableRemoteDocumentsAccess   This key is used to deny/allow access to file and SharePoint servers. The valid values of this key are:

  • 0: No access to SharePoint or file servers

    1: Access to only SharePoint servers; no access to file shares

    2: Access to only file shares; no access to SharePoint servers

    3: Access to both SharePoint servers and file shares

  • The default value is 3, which provides access to both SharePoint and file shares.

BlockedDocumentStoreList   This key is used to read the comma-delimited list of servers from which documents will be blocked. For example, if you want to block access to all documents in the file server Contoso, add Contoso to the list.

  • The default value is empty string.

    Note:
    A server that is not in this list is a server from which you can access documents. For example, an organization has three servers: Contoso1, Contoso2, and Contoso3. If Contoso1 and Contoso2 are in the list, users can only access documents from Contoso3. Access to documents in Contoso1 and Contoso2 is blocked.

AllowedDocumentStoreList   This key is used to read the comma-delimited list of servers from which documents will be allowed. For example, if you want to allow access to all documents in the file server Contoso, add Contoso to the list.

  • The default value is empty string.

    Note:
    A server that is not in this list is a server from which you have blocked access to documents. For example, an organization has three servers: Contoso1, Contoso2, and Contoso3. If Contoso1 and Contoso2 are in the list, users can only access documents from Contoso1 and Contoso2. Access to documents in Contoso3 is blocked.

BlockDocumentsFromList   This key is used to select whether to use the BlockedDocumentStoreList or AllowedDocumentStoreList to determine which SharePoint or file servers may or may not be accessed through Outlook Web Access. It reads BlockedDocumentStoreList when True and AllowedDocumentStoreList when False.

  • The default value is True, which reads BlockedDocumentStoreList.

  • This setting allows the administrator to choose between BlockedDocumentStoreList (block only the documents in the list) and AllowedDocumentStoreList (block all documents but those in the list).

EnableRemoteDocumentsAccessFromPublicComputers   This key is helpful when a user logs in using Forms Based Authentication (FBA) and the user selects that he/she is logging in from a public computer. If a user is logging in from a public computer, it may be unsafe to allow access to internal file shares and SharePoint servers. In that case, setting this key to True blocks access to these documents. This key is an extra security feature for administrators.

  • The default value is True, which prevents access to the documents from file shares and SharePoint servers when a user logs in from public computer.

    Note:
    Non-FBA logons are treated as private. This means that if the user authenticates using Basic authentication, they will never see the logon page and they will not have a choice between public/private. In that case, if EnableRemoteDocumentsAccessFromPublicComputers is set to False, they will still be able to access SharePoint servers and file shares.

InternalFQDNSuffixList   This is a comma-separated list of fully qualified domain name (FQDNs) suffixes that are internal FQDNs for the organization. For example, the site http://docaccess.contoso.com is usually treated as an external site and we do not attempt to retrieve documents from it. However, if an administrator adds microsoft.com to InternalFQDNSuffixList, this site will be treated as an internal server.

  • The default value is microsoft.com.

How to Update the Unified Messaging Scripts

To update the Unified Messaging scripts

  1. Open the Exchange Management Shell script in a text editor such as notepad.exe, and then open the script for the language pack that you want to install. For example, open the installfrfr.msh script if you are installing the Unified Messaging Language pack for French.

  2. Locate the line in the script that states: $ums.Languages += “[language]”.

  3. In the $ums.Languages += “[value]” line, replace the text in the value, for example FRN, with the value for the language that is listed in the table below:

    “GER”

    3

    “JPN”

    2

    “FRN”

    4

    For example, in installfrfr.msh, replace $ums.Languages += “FRN”’ with $ums.Languages += 4.

  4. In the text editor, save the script.

  5. To install the Unified Messaging language pack, open the Exchange Management Shell and run the script that you edited.

Cluster Continuous Replication

To use cluster continuous replication (CCR), the cluster service account needs to have Exchange Server Admin authority.

In a CCR environment, we recommend that you limit to between 10 and 15 the number of storage groups and databases.

How to Move Storage Groups in a CCR Cluster

To move a storage group in a CCR cluster

  1. Stop the Microsoft Exchange Replication Service on the active and passive nodes.

  2. Remove the share for the log directory from the active and passive nodes.

  3. Use Move-StorageGroupPath -configurationonly to move the location of the log directory.

  4. Move the data on both nodes to the appropriate location.

  5. Restart the Microsoft Exchange Replication Service on both nodes.

How to Upgrade a Clustered Mailbox Server

To upgrade a clustered mailbox server

  1. Upgrade the passive node using the following command: setup.exe /mode:upgrade /c /t:<TargetDirectory>

  2. Restart the Microsoft Exchange Replication Service.

  3. Use Cluster Administrator to take the resource group containing the clustered mailbox server offline, and then move that resource group to the passive node.

  4. Upgrade the clustered mailbox server directory object by running the following command: exsetup.exe /mode:upgrade /cl /cn:<CMSName> /dc:<DCName>

  5. Verify that the Microsoft Exchange Replication Service is running on both nodes. If it is not running on the active or passive node, start it.

  6. Verify that all the logs present on the originally active node are present on the upgraded server prior to the next step.

  7. Use Cluster Administrator to bring the clustered mailbox server online.

  8. Upgrade the (now) passive node by running: setup.exe /mode:upgrade /c /t:<TargetDirectory>

  9. Verify that the Microsoft Exchange Replication Service is running on both nodes. If it is not running on the active or passive node, start it.

How to Uninstall a Clustered Mailbox Server

To uninstall a clustered mailbox server

  1. Stop the Microsoft Exchange System Attendant service on the server.

  2. Run: exsetup /mode:uninstall /cl /cn:<CMSName> /dc:<DCName>

  3. Manually delete any remaining Exchange data files in the file system.

  4. To subsequently remove the Exchange binary files from the node run: exsetup /mode:uninstall

How to Remove Exchange From a Passive Node

To remove Exchange from a passive node

  1. Run: exsetup /mode:uninstall

  2. Use Cluster Administrator to verify that the owners list for the Exchange resources no longer includes the passive node as a possible owner. If the passive node is still listed as a possible owner, remove the passive node from the possible owners list.

Cluster Continuous Replication and Local Continuous Replication Known Issues

In this release of Exchange Server "12", please be aware of the following known issues related to CCR:

  • If you use an IP address and network name that is already in use when creating a new clustered mailbox server, the error message is misleading: Exception: Microsoft.Exchange.Cluster.Handoff.ExsetdataUnknownException: Error of unknown type occurred while performing exsetdata operation; the original error code was 0xc00f0016.

  • Exchange Setup does not fail if the cluster service is not running. Instead, it installs a standalone node. Before performing the tasks to create a new clustered mailbox server, we recommend that you launch Cluster Administrator and verify that the cluster is online.

  • Uninstall fails if the System Attendant is online. The following error message is produced: Error of unknown type occurred while performing exsetdata operation; the original error code was 0xc1037b3f.

  • Performing New-ClusteredMailboxServer and then Remove-ClusteredMailboxServer repeatedly leaves many Exchange Server Administrators groups in Active Directory.

  • ExSetup on a cluster does not handle the datapath parameter correctly. You should install the clustered mailbox server to the default location and move the storage groups and databases.

  • If data files exist at the default database or storage group location when creating a new clustered mailbox server, ExSetup will fail with the following error message: The location of the log file is not available in the file system.

  • Upgrade Exchange Virtual Server and Remove Exchange Virtual Server context menu items appear in Cluster Administrator, but they should never be used.

  • When removing a clustered mailbox server, ExSetup does not report an error or suspend operations if a mailbox database with mailboxes exists on the clustered mailbox server. The uninstall process is initiated and partially completes, leaving a System Attendant resource. To complete the uninstall process, disable the mailboxes and re-run the uninstall command.

  • New databases must always be created locally on the active node. Failure to do so leaves the resources with incorrect ownership, which can prevent databases from coming online on the active node. If the system gets into this state, use Cluster Administrator to change the ownership of the database resource from the passive node to the active node.

  • CCR uses file shares to access the transaction logs. The permissions on this file are not restricted in Beta1. To restrict access use Windows Explorer to set the share permissions for each log directory on both the active and passive node as follows: Read access for the machine account of the other node.

  • If a clustered mailbox server fails over from the active node to the passive node and no databases are brought online on the passive node, when the active node returns, the clustered mailbox server does not automatically return to the active node 1. You must manually move the clustered mailbox server back to the active node.

  • Get-StorageGroupCopyStatus for storage groups that do not have any databases will report a status of broken.

  • In a local continuous replication (LCR) configuration, the system may not accurately report the state of the copy until after it is seeded. The system incorrectly reports the state as healthy under some conditions.

  • LCR and CCR do not correctly handle resets of the log generation number. To reset the log generation numbers in an LCR configuration, we recommend that you disable LCR for that storage group, reset the log generation numbers, and then re-enable LCR for the storage group. In a CCR configuration, avoid this operation.

  • In an LCR configuration, the Exchange Management Shell tasks must be run on the Exchange server. In a CCR configuration, Exchange Management Shell tasks must be run on a node in the cluster.

  • On any LCR activation that involves data loss, content indexing catalogs must be manually deleted. The catalog files must be manually moved if an LCR copy is used in a lossless activation.

  • Content indexing is not supported in a CCR configuration.

  • Documentation for the Start-ClusteredMailboxServer command exists in the Exchange Management Shell reference topics. This command should not be used under any circumstances.

Web Services Configuration

Availability Service Configuration

To configure the Availability service on Client Access Servers

  • If you are running ISA Server 2004 and you want to enable the Availability service for external clients, the /EPI virtual directory must be available to external clients. To make the /EPI virtual directory available, you must manually add /epi/* to the ISA Server Web publishing rule.
To configure cross-forest free/busy access for non-Exchange Server 12 forests

  • To enable Exchange Server "12" users to access free/busy information for non-Exchange Server "12" users in other forests, run the following command on a Client Access Server in the source forest for each Exchange forest that contains non-Exchange Server "12" user mailboxes:

    Add-AvailabilityAddressSpace -ForestName <forestname> -AccessMethod PublicFolder

    Replace <forestname> with the fully qualified domain name (FQDN) of the target forest.

    Note:
    This command should be run only once per non-Exchange Server "12" forest. Do not run it for every install of a Client Access Server Role.

    Note:
    For cross-forest free/busy information in non-Exchange Server "12" forests, Inter-Organization Replication (IORepl) should be set up in order to replicate free/busy information between the forests. For more details about how to set up IORepl, see "Installing, configuring, and using the InterOrg Replication utility."

Autodiscovery Configuration

The Autodiscovery service is a Web service that allows clients to query for their settings. Currently, only Outlook 12 supports this feature. This feature enables Outlook 12 to automatically create a mail profile based on the SMTP address of the user.

For Autodiscovery to work, the Autodiscover virtual directory on the default Web site must be available. Outlook 12 adds “autodiscover” to the domain portion of the SMTP address and uses that to locate an Autodiscovery server.

For example, an SMTP address of donhall@contoso.com means that Outlook searches for the following addresses in this order:

  • Autodiscover.contoso.com

  • contoso.com

To configure Autodiscovery

  1. In order for Autodiscovery to work, the Autodiscover virtual directory needs to be created and enabled for Secure Sockets Layer (SSL):

    1. Using the Internet Information Service snap-in, create a new Web site named "Autodiscovery Web Site".

    2. Export the existing autodiscover virtual directory under the default Web site to a file.

    3. Create a new autodiscover virtual directory from file under the 'Autodiscovery Web Site' and bind the virtual directory to a second IP address or network interface.

    4. Configure the Autodiscovery Web site to require 128-bit SSL using the autodiscover Internet namespace and certificate.

  2. For each Client Access Server that is part of an NLB cluster, open the Exchange Management Shell and run the following command: 

    set-webservicesvirtualdirectory <CAS name>\epi –Externalhostname:”<external host name>”
    Note:
    Replace <CAS name> with the Client Access Server (CAS) name in the NLB. Replace <external host name> with the server name that is visible on the Internet for the CAS server.

Outlook 12 will not be able to connect to Autodiscovery or the Availability Web Service if the client does not trust the server’s SSL certificate. You must have a valid certificate on every CAS server.

How to troubleshoot Outlook 12 connections to Autodiscovery

  • If Outlook 12 is not able to connect to Autodiscovery after you install your certificates, you can set the following registry key on Outlook 12:

    HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover\ShowCertErrors = (reg_dword) 0x01

    Note:
    Setting ShowCertErrors to 0x01 will enable the certificate warning dialog in Outlook 12. When Outlook 12 attempts to connect to a server with an invalid SSL certificate, a dialog box will appear that allows the client to view the certificate of the server that Outlook 12 is connecting to. Then, the user can install the certificate on the client machine. Setting this registry key to 0x00 enables this dialog box.

In test environments you may want to configure Autodiscovery to work without a valid server certificate. In this case, you should turn off the SSL-required setting on the Autodiscovery Web site and set the following registry key on the Outlook computer:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover\UseSSL to 0x00

This key will make Outlook use HTTP instead of HTTPS when it connects to Exchange. Do not use this configuration in a production environment.

Service Discovery for Web Services

Exchange Server "12" CAS setup automatically enables the server for services discovery for Web services including Availability Service (AS). If you do not want your CAS server to service AS and other Web Services requests, you can disable services discovery by removing the entry that is added by default during setup in Active Directory for this server.

To disable service discovery for Web Services on a CAS server

  • To disable service discovery for Web servers on the CAS Server Role, run the following command:

    remove-webservicesvirtualdirectory <CAS name>\epi
    Note:
    Replace <CAS name> with the name of your CAS server.

Feedback and Support

The Exchange team welcomes your feedback. If you are a Beta 1 participant using Microsoft Connect, please use http://connect.microsoft.com to submit your feedback either through the bug reporting tool or by using the Beta 1 newsgroups. Instructions for how to access the bug reporting tool and newsgroups can be found at http://connect.microsoft.com.

For support of the Beta 1 release, please visit http://connect.microsoft.com and submit your support questions by using the Beta 1 newsgroups.

Legal Notice

This document supports a preliminary release of a software product that may be changed substantially prior to final commercial release, and is the confidential and proprietary information of Microsoft Corporation. It is disclosed pursuant to a non-disclosure agreement between the recipient and Microsoft. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2006 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows Mobile, Windows Server, Windows Vista, Active Directory, Outlook, and SharePoint Services are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.