Autodiscover failed on Outlook 2007 client with error 0x800c8203 after installing KB2412171

After installing KB2412171 on client computers I found another bug in this update.
Normally Outlook configure your Outlook profile on your primarily smtp address. But after this update this is changed to the user principal name. If you have not added user principal name to a mail user you will see dat autodiscovery wil fail.

Solution Uninstalling KB2412171

%windir%\System32\msiexec.exe /package <Office 2007 product code> /uninstall <patch code for the MSP from KB2412171> /Q /L*V %temp%\Remove_KB2412171.log Product codes (or “GUIDs”) for Office 2007 and Outlook 2007 are as follows: Standard: {90120000-0012-0000-0000-0000000FF1CE} Professional: {90120000-0014-0000-0000-0000000FF1CE} Professional Plus:{90120000-0011-0000-0000-0000000FF1CE} Enterprise:{90120000-0030-0000-0000-0000000FF1CE} Outlook 2007 Standalone: {90120000-001A-0000-0000-0000000FF1CE} Patch codes for the MSP files related to KB2412171 are as follows: {7961E819-93A5-40A8-8469-4BE2FBBFACEF}  (for the original patch) {752A0B7C-BD24-4362-AC86-AB63FEE6F46F} (for the re-release patch)

For my did this the trick
%windir%\System32\msiexec.exe /package {90120000-0030-0000-0000-0000000FF1CE} /uninstall {752A0B7C-BD24-4362-AC86-AB63FEE6F46F} /Q /L*V c:\Remove_KB2412171.log

Exchange 2010 Public Folder Database requirement

Current Status: Issue with mitigation

Unlike Outlook 2007 and 2010, Outlook 2003 clients rely on public folders. If a public folder database doesn’t exist, Outlook 2003 users will be blocked from connecting to their Exchange 2010 mailbox and receive the error message shown in Figure 8.


Figure 8:
Error message when an Outlook 2003 user connects to an Exchange 2010 mailbox

There are several reasons why a public folder database is required for Outlook 2003 client. First, Outlook 2003 in cached mode uses the “OFFLINE ADDRESS BOOK” system folder to download the offline address book (OAB) and the “SCHEDULE+ FREE BUSY” to retrieve and update free/busy information.


Figure 9:
Offline Address Book and Schedule+ Free Busy system folders

Second, if you’re installing Exchange 2010 into an existing Exchange organization running Exchange 2007, it’s important you add the Exchange 2010 public folder database to the replica list of the “SCHEDULE+ FREE BUSY” folder. If this step isn’t completed, users who use Outlook 2003 cannot publish their free/busy data in Exchange Server 2010. Instead hash marks appear in the free/busy data for these users. More information as well as the steps that can be used to remediate this issue can be found in the following KB article:

Special Thanks to Henrik Walther

Concern: Is having Outlook 2003 clients going to prevent me from deploying Exchange 2010

OVERALL STATUS: No, having Oulook 2003 clients is not a deployment blocker. However, you need to understand the following sections and make configuration changes as applicable.

Back since November 9th, 2009 where Exchange Server 2010 released to manufacturing (RTM), there have been a growing concern around whether enterprises are prevented from upgrading or migrating their current Exchange 2003 or Exchange 2007 based messaging infrastructure to Exchange 2010, if Outlook 2003 clients is used within the organization.

But in  this article includes are a few additional concerns about Exchange 2010 and Outlook 2003

Exchange 2010 lack support for UDP Notifications

Exchange 2010 Exchange Server name appears as Instance – <GUID>

Exchange 2010 & Outlook 2003 Offline Address Book (OAB)

Exchange 2010 RPC over HTTP Connectivity

Exchange 2010 Opening multiple shared calendars & additional mailboxes

Exchange 2010 RPC Encryption Requirement

Exchange 2010 Public Folder Database requirement

exchange 2010

Special Thanks to Henrik Walther

Exchange 2010 lack support for UDP Notifications

Current Status: Issue with mitigation


Important
With Exchange 2010 SP1 RU3 UDP notifications is being re-added to to Exchange 2010 (read more here). This means that the below symptoms will be resolved, once Exchange 2010 SP1 RU3 becomes available in March 2011.

With Exchange Server 2010, there is no longer support for User Datagram Protocol (UDP) notifications. When opening a mailbox using Outlook 2003, Outlook 2003 tries to register itself to receive new message notifications. By default Outlook 2003 tried to register for UDP notifications but since this notification method isn’t supported with Exchange 2010, Outlook 2003 will instead revert to polling the Exchange server for changes in the mailbox. Despite the fact that Outlook 2003 initiates the polling behavior, the Exchange server will dictate the polling frequency. By default Outlook 2003 polls the Exchange server every 60 seconds.

Since Exchange 2010 doesn’t support UDP based notifications, Outlook 2003 won’t be able to register itself using this method, which means changes made to any of the folders in the mailbox won’t be reflected before Outlook 2003 polls the Exchange server for changes. The result of this is that notifications about new messages etc. will be reflected in the Outlook 2003 client with delays of up to 60 seconds.
More specifically, you will see the following symptoms:

  • Outgoing e-mail messages stay in the Outbox for up to 1 minute
  • New e-mail messages do not arrive in the Inbox for up to 1 minute
  • Items that are deleted from folders do not disappear from the folder for up to 1 minute
  • Items that are moved from one folder to another folder take up to 1 minute to disappear from the original folder

Two methods exist to remediate the polling issue described above:

Method 1: Change the Polling Frequency

The issue can be remediated by installing Exchange 2010 Service Pack 1 which includes support for a new registry key that can be used to lower the polling frequency to 5 seconds.


Figure 3:
Lowering the polling frequency value


Note
The registry key doesn’t reinstate UDP in Exchange 2010; it only lowers the polling frequency.

Method 2: Enable Cached Mode in Outlook 2003 Clients

The cached mode synchronization process uses a different architecture to update folders versus Outlook 2003 clients in online mode. So another option is to enable cached mode for all Outlook 2003 clients within the organization.

The following KB article describes the symptoms and remediation in detail:

Update: Rollup 3 for Exchange 2010 SP1 is gereleased

Special Thanks to Henrik Walther

Exchange 2010 & Outlook 2003 Offline Address Book (OAB)

Current Status: Issue with mitigation

If the client machine on which Outlook 2003 is installed has been configured to use a proxy server), you must enable "Bypass proxy server for local addresses" under Internet Options > Connections > LAN settings or add the CAS server or CAS arrays to the exception list shown in Figure 10.


Figure 10:
Proxy server settings in Internet Explorer

If a proxy server is used in the organization and you haven’t done one of the following:

  • Enabled “Bypass proxy server for local addresses”
  • Added the CAS server or CAS array to the “Exceptions list”

The Outlook 2003 clients will get an error when trying to download the offline address book (OAB). For more information about the error messages and the steps necessary to remediate the issue, see the following KB article:


Note
This issue also affects Outlook 2007 and 2010 clients.

Outlook 2003 clients will also receive an error message when trying to download the OAB if the correct OAB hasn’t been specified for the Exchange 2010 database(s). For more information and steps required to remediate this issue, see the following KB article:

Special Thanks to Henrik Walther

Exchange 2010 RPC over HTTP Connectivity

In some situations Outlook 2003 users connecting to an Exchange mailbox using RPC over HTTP receive the following error message:

“Server Unavailable”

Although this is an Outlook 2003 specific client issue, the issue is not specific for Exchange 2010 organizations. It could also appear in organizations running Exchange 2003 or 2007.

The problem occurs if the RPC proxy server extensions do no load correctly. You can find more details and a description of how the issue can be remediated in the following KB article:

Special Thanks to Henrik Walther

Exchange 2010 Opening multiple shared calendars & additional mailboxes

Current Status: Issue with mitigation

Exchange 2010 SP1 together with the resolutions mentioned later in this section, allows you to open as many as 16 shared calendars or additional mailboxes simultaneously independent on whether the mailboxes are located on Exchange 2003, 2007, or 2010. If you have more than 16 calendars or additional mailboxes opened, you may randomly see error message similar to the one shown in Figure 4.


Figure 4:
Error message when opening more than 16 calendars

With Exchange Server 2010 RTM deployed into an Exchange 2003 or Exchange 2007 organization, it was a common issue that when an Exchange 2003 or Exchange 2007 user tried to open more than two additional Exchange 2010 mailboxes or shared calendars using Outlook 2003, she would receive one of the following error messages:

  • The set of folders could not be opened
  • The information store could not be opened
  • Unable to display the folder. The information store could not be opened

When an Exchange 2007 user tried to send an e-mail using Outlook 2003, she would sometimes also receive the following error message:

  • Task ‘Microsoft Exchange Server – Sending’ reported error (0x800C8100): ‘Unknown Error 0x800c8100’

These issues were resolved with Update Rollup 2 for Exchange 2007 Service Pack 2 and a hotfix that were released for Exchange 2003 SP2. More information about the issues and how they are resolved can be found in the following KB articles:

    Although the above mentioned issues were resolved, some customers, partners, and individuals in the Exchange communities reported they still experienced issues when trying to open approximately multiple shared calendars and/or additional mailboxes using Outlook 2003.

    For most organizations, the issue can be remediated by installing Exchange 2010 SP1 as this service pack includes a fix that makes it possible for an Exchange 2003, 2007, or 2010 user to open as many as approximately 16 shared calendars or additional mailboxes using Outlook 2003.


    Figure 5:
    By default approximately 16 Calendars can be opened using Outlook 2003

    If you have users that needs to open more than 16 shared calendars or additional mailboxes using Outlook 2003, you can adjust the RPC related throttling policy settings using the Set-ThrottlingPolicy cmdlet. Specifically, you need to increase the value for “RCAMaxConcurrency” which by default is set to “20”. The RCAMaxConcurrency parameter indicates how many concurrent connections an RPC Client Access user can have against a server running Exchange 2010 at one time.


    Figure 6:
    Default setting for the RCAMaxConcurrency throttling policy value

    For instance, to increase the value of the “RCAMaxConcurrency” setting in the default throttling policy from 20 to 2147483647, open the Exchange Management Shell and run the following command to first create a variable for the policy:

    $a = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}

    Then pipe the variable to the Set-ThrottlingPolicy commandlet:

    $a | Set-ThrottlingPolicy -RCAMaxConcurrency 2147483647


    Figure 7:
    Increasing the value for the RCAMaxConcurrency throttling policy setting

    In order to apply the changes, restart the “Microsoft Exchange Throttling” service on each CAS server in the organization.

    You can read more about Exchange 2010 SP1 throttling policies in the Exchange 2010 documentation on Microsoft TechNet.

    If you still have issues opening shared calendars or additional mailboxes, you may want to increase the value of the RCAMaxConcurrency throttling policy setting to 100 or even higher. Read more in Error message when Outlook 2003 clients try to open multiple shared calendars in Exchange Server 2010: "The connection to the Microsoft Exchange server in unavailable. Outlook must be online or connected to complete this action".

    If you see event 4696 with a description similar to the following logged in the application log on the Mailbox servers in the organization:

    "Mapi session "00cc8dde-64d7-4353-8050-00fc2057aae3: /O=xxxx/OU=xxxx/cn=Recipients/cn=ward" exceeded the maximum of 32 objects of type "session"."

    You need to increase the maximum allowed sessions per user and/or maximum allowed service sessions per user limit from "32" to "64" or even higher. See more information at: Exchange 2010 SP1 Store Limits.

    but when I tried to add the “szMaxAllowedSessionsPerUser and/or “szMaxAllowedServiceSessionsPerUser”, I still saw 9646 in the app log.

    Guess why? yes the registry keys are actually listed with wrong names in that article. Instead of:

    • szMaxAllowedSessionsPerUser
    • szMaxAllowedServiceSessionsPerUser

    You need to use:

    • Maximum Allowed Sessions Per User
    • Maximum Allowed Service Sessions Per User

    And then everything worked as expected…

    Hopefully the TechNet page is updated soon.

    Special Thanks to Henrik Walther

    Exchange 2010 RPC Encryption Requirement

    Current Status: Non-issue

    Exchange 2010 SP1
    With Exchange 2010 RTM, the RPC encryption requirement was an issue with mitigation. However, in Exchange Server 2010 Service Pack 1, the RPC encryption requirement has been disabled by default. This means that any new Exchange 2010 SP1 Client Access Servers (CAS) deployed in the organization won’t require encryption and Outlook 2003 clients will connect without the need to enable the RPC encryption feature in the Outlook profile.

    Important
    Having the RPC encryption requirement on an Exchange 2010 CAS server disabled doesn’t lower the security between Outlook 2007/2010 and any Exchange 2010 CAS server. RPC communication for these Outlook versions will remain encrypted as long as the client has the RPC encryption feature enabled. It’s only the requirement itself that is disabled on the Exchange 2010 CAS server.

    Exchange 2010 CAS servers deployed prior to Service Pack 1, or upgraded to Service Pack 1, will retain the existing RPC encryption requirement setting.

    Exchange 2010 RTM
    When upgrading or migrating an organization that fully or partly uses Outlook 2003 to Exchange 2010, we hear there are out of the box problems, when trying to connect an Outlook 2003 client to an Exchange 2010 RTM mailbox? We heard this is because an Exchange 2010 RTM Client Access Server by default requires an Outlook client to support RPC encrypted traffic in order to be able to connect.

    While it’s true the default configuration of an Outlook 2003 client doesn’t have support for RPC encryption, this requirement is fully supported with Outlook 2003.

    There are two methods that can be used in order to have Outlook 2003 clients connect to an Exchange 2010 RTM mailbox:

    Method 1: Enable the RPC encryption support in Outlook 2003

    If “Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server” is enabled under the “Security” tab in the Outlook 2003 profile (see figure 1), the client will be able to connect to an Exchange 2010 RTM mailbox.


    Figure 1:
    RPC Encryption enabled in Outlook 2003

    If you are working with or for a small organization, it may be acceptable the end user enables this feature manually, but if you have thousands of users in the organization, you would want to enable it using a group policy (GPO). The steps necessary to implement a GPO to enable this setting are included in this KB article.


    Important

    The “EnableRPCEncryption” registry key mentioned in the KB article was originally introduced via a hotfix for Outlook 2003 SP2. This means that clients that either runs Outlook 2003 SP2 or an older version of Outlook 2003 doesn’t respect this registry key. In addition, Outlook 2003 clients not running SP3 are not supported by Microsoft.

    Method 2: Disable the RPC Encryption requirement on the Client Access Servers

    Instead of enabling support for RPC encryption in the Outlook 2003 profiles, you also have the option of disabling the requirement for RPC encryption on all Exchange 2010 RTM Client Access Servers in the organization.

    This can be accomplished using the Set-RpcClientAccess cmdlet:

    Set-RpcClientAccess –Server Exchange_server_name –EncryptionRequired $False


    Figure 2:
    RPC Encryption requirement disabled on Exchange 2010 CAS servers

    As mentioned earlier Exchange 2010 SP1 servers that hasn’t been upgraded from Exchange 2010 RTM has the RPC encryption requirement disabled by default.

    The following KB article describes the symptoms and remediation in detail:

    The core Exchange 2010 TechNet documentation also describes the configuration that can be used to remediate the issue:

    Important
    Unmanaged client machines cannot be controlled using GPOs or login scripts. If you have unmanaged machines connecting to Exchange 2010 using Outlook 2003, one solution would be to send those users a script or a registry file which they can run manually on their machine to enable the RPC encryption setting.

    Special Thanks to Henrik Walther

    Exchange 2010 Exchange Server name appears as Instance – <GUID>

    Current Status: Issue – no issue

    A few customers, partners, and individual folks in the Exchange community have reported that a few of the Exchange 2010 users running Outlook 2003 randomly have issues connecting to their mailbox. After examining the mail profile in Outlook 2003, you can see the Exchange server name appears as Instance-<GUID> where <GUID> is a randomly generated GUID (or number). Re-resolving (‘Check Name’) the appropriate server name in the Outlook mail profile resolves the issue.


    Figure 11: Instance-GUID issue in Outlook 2003

    Note
    Seeing Instance-<GUID> in conversation between an Outlook 2003 client and an Exchange 2010 server is normal (when Instance-<GUID> appears inside Outlook in the folders list view on left hand side); It does NOT mean you are hitting this particular issue. You experience this issue if the Outlook mail profile gets updated to refer to the Exchange server as Instance-GUID.

    The problem behavior can be triggered by networking issues, patch applications, server reboots, etc. It requires Outlook 2003 to lose connectivity to Exchange and have a delegate mailbox logon attempted on a connection before the primary mailbox logon is attempted on that connection. This can affect users who are accessing shared mailboxes or folders of other users from their Outlook 2003 while connecting to Exchange 2010.

    Currently there is no proper resolution available for this issue. However, to remediate this issue temporarily, simply re-resolve the Exchange server name in the Outlook mail profile. If possible, you may also remove the shared mailboxes or shared folders (like calendars) from the profile, preventing this issue from occurring in the future or create a new mail profile in Outlook.

    Microsoft is working to investigate this issue for a fix. You can contact Microsoft Support to report this issue and request further assistance. Currently no KB article exists for this issue.

    Update:

    Microsoft has confirmed this to be a bug and the bug was assigned to the Outlook team within Microsoft. It has been fixed and a hotfix can be downloaded here: http://support.microsoft.com/kb/2510153

     

    Special Thanks to Henrik Walther & Jaap Wesselius

    Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG

    This white paper provides detailed information about publishing Microsoft Exchange Server 2010 using Forefront TMG or Forefront UAG to secure access for Outlook Anywhere when using NTLM Authentication.

    When you publish Exchange, Microsoft offers two software-based options: Microsoft Forefront Threat Management Gateway 2010 and Microsoft Forefront Unified Access Gateway 2010. Both options offer publishing wizards and security features to provide secure access to Exchange when it’s accessed from outside the safety of the corporate network.

    This white paper provides detailed information about publishing Microsoft Exchange Server 2010 using Forefront TMG or Forefront UAG, including how to choose between them for different scenarios, and provides specific steps you can take to configure Forefront TMG and Forefront UAG to publish Exchange 2010 while using NTLM authentication for Outlook Anywhere access.

    Download details Publishing Outlook Anywhere Using NTLM Authentication With Forefront TMG or Forefront UAG

    Translate »