Quantcast
Channel: You Had Me At EHLO…
Viewing all 607 articles
Browse latest View live

Supporting Windows 8 Mail in your organization

0
0

Windows 8 and Windows RT include a built-in email app named Mail (also referred to as Windows 8 Mail or the Windows 8 Mail app). The Windows 8 Mail app includes support for IMAP and Exchange ActiveSync (EAS) accounts.

This article includes some key technical details of the Windows 8 Mail app. Use the information to help you support the use of Windows 8 Mail app in your organization. Read this article start to finish, or jump to the topic that interests you. Use the reference links throughout the article for more information.

NOTE Mail, Calendar, People, Calendar, and Messaging are apps that are built in to Windows 8 and Windows RT. Although this article discusses the Windows 8 Mail app, please note that much of the information in this article also applies to the Calendar, People, and Messaging apps. This is because, when connected to a server that supports Exchange ActiveSync, the Calendar, and People apps may also display data that was downloaded over the Exchange ActiveSync connection.

Protocol Support

The Windows 8 Mail app lets users connect to any service provider that supports either of the following two protocols:

  • Exchange ActiveSync
  • IMAP/SMTP

POP is not currently supported.

Exchange ActiveSync

Exchange ActiveSync can be used to sync data for email, contacts, and calendar. The Windows 8 Mail app supports EAS versions 2.5, 12.0, 12.1, and 14.0. For detailed protocol documentation, see Exchange Sever Protocol Documents on MSDN.

NOTE All Windows Communications apps (Mail, Calendar, and People) can use the data that is synchronized with Exchange ActiveSync. After a user connects to their account in the Windows 8 Mail app, their contacts and calendar data are available in the other Windows Communications Apps and vice versa.

IMAP/SMTP

The Windows 8 Mail app supports the following IMAP and SMTP standards:

IMAP/SMTP can be used to send and receive email only. Contacts data and calendar data is not synchronized when IMAP/SMTP is used. Microsoft Exchange does not support Public Folders via IMAP. For more details about IMAP support in Exchange, see POP3 and IMAP4 (for Exchange 2010, see Understanding POP3 and IMAP4).

Sync Configuration

The Windows 8 Mail app can be configured to synchronize data at different times as follows:

  • Push email (default)
  • Polling at fixed intervals
  • Manually

If a push email connection can’t be established, it will automatically switch to poll at fixed intervals.

Push Email

Push email requires that accounts are either Exchange ActiveSync (which all support Push) or IMAP with the IDLE extension. Not all IMAP servers support IDLE, and it is supported only for the Inbox folder.

When a push connection can’t be established, Mail will change to polling on 30 minute intervals. Push email on Exchange ActiveSync requires that HTTP connections must be maintained for up to 60 minutes, and IMAP IDLE requires TCP connections to be maintained for up to 30 minutes.

Account Setup Features

Windows 8 and Windows RT users can add email accounts to the Windows 8 Mail app using the Settingscharm. The Settings charm is always available on the right side of the Windows 8 and Windows RT screen. (For more visual details about Charms & the Windows 8 user interface, see Search, share & more.)

NOTE This section provides an overview of Windows 8 Mail app account setup. For step-by-step procedures for setting up an account in the Windows 8 Mail app, see What else do I need to know? at the end of this guide.

To make it as easy as possible to add accounts, account setup only prompts the user to enter the email address and password for the account they want to set up. From that data, Mail attempts to automatically configure the account as follows:

  • The domain portion of the email address is matched against a database of well-known service providers. If it’s a match, its settings are automatically configured.
  • The domain portion of the email address is used to execute Exchange ActiveSync Autodiscover processes. For detailed information, see Autodiscover HTTP Service Protocol Specification on MSDN.
  • If still not configured, the user is prompted to provide detailed settings for their server.

Exchange ActiveSync

Screenshot: Exchange ActiveSync configuration in Windows Mail
Figure 1: Exchange ActiveSync (EAS) configuration in Windows Mail

Full details needed to connect to an Exchange server – needed only if Autodiscover failed

The information required to connect to a server via Exchange ActiveSync is:

  • Email address
  • Server address
  • Domain
  • Username
  • Password

IMAP/SMTP

Screenshot: IMAP/SMTP configuration in Windows Mail
Figure 2: IMAP/SMTP configuration in Windows Mail

The information required to connect to a server via IMAP/SMTP is:

  • Email address
  • Username
  • Password
  • IMAP email server
  • IMAP SSL (if your IMAP server requires SSL encryption)
  • IMAP port
  • SMTP email server
  • SMTP SSL (if your SMTP server requires SSL encryption)
  • SMTP port
  • Whether SMTP server requires authentication
  • Whether SMTP uses the same credentials as IMAP (If not, user must also provide SMTP credentials)

Security Features

Mail provides administrators with some level of security through Exchange ActiveSync policies. It doesn’t support any means of managing or securing PCs that are connected via IMAP.

Policy Support

Exchange ActiveSync devices can be managed using Exchange ActiveSync policies. Windows 8 Mail supports the following EAS policies. :

  • Password required
  • Allow simple password
  • Minimum password length (to a maximum of 8 characters)
  • Number of complex characters in password (to a maximum of 2 characters)
  • Password history
  • Password expiration
  • Device encryption required (on Windows RT and editions of Windows that support BitLocker. See What's New in BitLocker for details about BitLocker improvements in Windows 8.)
  • Maximum number of failed attempts to unlock device
  • Maximum time of inactivity before locking

Note that if AllowNonProvisionableDevices is set to false in an EAS policy and the policy contains settings are not part of this list, the device won’t be able to connect to the Exchange server.

Getting into Compliance

Most of the policies listed above can be automatically enabled by Mail, but there are certain cases where the user has to take action first. These are:

  • Server requires device encryption:
    • User has a device that supports BitLocker but BitLocker isn’t enabled. User must manually enable BitLocker.
    • User has a Windows RT device that supports device encryption but it is suspended. User must reboot.
    • User has a Windows RT device that supports device encryption, but it isn’t enabled. User must sign into Windows with a Microsoft account.
  • An admin on this PC doesn’t have a strong password: All admin accounts must have a strong password before continuing.
  • The user’s account doesn’t have a strong password: User must set a strong password before continuing.

ActiveSync Policy v/s Group Policy on domain-joined Windows 8 devices

If a Windows 8 PC is joined to an Active Directory domain and controlled by Group Policy, there may be conflicting policy settings between Group Policy and an Exchange ActiveSync policy. In the event of any conflict, the strictest rule in either policy takes precedence. The only exception is password complexity rules for domain accounts. Group policy rules for password complexity (length, expiry, history, number of complex characters) take precedence over Exchange ActiveSync policies – even if group policy rules for password complexity are less strict than Exchange ActiveSync rules, the domain account will be deemed in compliance with Exchange ActiveSync policy.

Remote Wipe

Mail supports the Exchange ActiveSync remote wipe directive, but unlike Windows Phones, the data deleted by this directive is scoped to the specified Exchange ActiveSync account. The user's personal data is not deleted. For example, if a user has an Outlook.com account for personal use and a Contoso.com account for work use, a remote wipe directive from the Contoso.com server would impact Windows 8 and Windows Phone 7 as follows:

DataWindows Phone 7Windows 8 Mail
Contoso.com emailDeletedDeleted
Contoso.com contactsDeletedDeleted
Contoso.com calendarsDeletedDeleted
Outlook.com emailDeletedNot deleted
Outlook.com contactsDeletedNot deleted
Outlook.com calendarsDeletedNot deleted
Other documents, files, pictures, etc.DeletedNot deleted

Account Roaming

To make it as easy as possible for users to have all of their accounts set up on all of their devices, Windows 8 uploads vital account information to the user’s Microsoft account. This information includes email address, server, server settings, and password. When a user signs into a new PC with their Microsoft account, their email accounts are automatically set up for them.

Passwords are not uploaded from a PC for any accounts which are controlled by any Exchange ActiveSync policies. Users will have to enter their password to begin syncing a policy-controlled account on a new PC.

Microsoft Accounts

Users are required to have a Microsoft Account, formerly known as Windows Live ID, to use the Windows Communications apps. This will usually be the Microsoft account that the user is signed into Windows with, but if they have not done so, they will be prompted to provide one before proceeding.

Microsoft accounts will automatically sync to Microsoft services using Exchange ActiveSync 14.0 when Mail starts. This will synchronize:

      • Email, if the user’s Microsoft account is also their Hotmail or Outlook.com account
      • Contacts from Windows Live
      • Calendar events

If the user’s Microsoft account is not a Outlook.com or Hotmail account (for example, dave@contoso.com), Mail will prompt the user to provide the password for their email account, which will be added automatically.

Data Consumption

By default, Mail only downloads the last two weeks of email. This is user configurable and can potentially download the user’s entire mailbox. For Exchange ActiveSync accounts, all contacts are downloaded and calendar events are downloaded only for three months behind the current date and 18 months ahead.

Additionally, messages are only partially downloaded to reduce bandwidth use as follows:

        • Message bodies are truncated to the first 100KB (20KB on metered networks). For more details see Engineering Windows 8 for mobile networks.
        • Attachments are not downloaded automatically.

Embedded images in email messages are downloaded on-demand as the user reads them, and attachments are downloaded on-demand as the user attempts to open them.

By default, Mail only downloads the user’s Inbox and Sent folders. Other folders are downloaded once the user accesses them for the first time.

Mail does not enforce any limits on how many or large of attachments users can send.

Limitations

The following features are currently not supported by Mail:

  • Mailbox connections using POP:  IMAP and EAS are supported.

    (Note, this does not mean that Windows 8 does not support POP3. This post is about the Windows 8 Mail app. )

  • Servers that require self-signed certificates: Users can work around the self-signed certificate limitation by manually installing the certificate on their Windows 8 or Windows RT device. For additional information about the self-signed certificates, see Self-Signed Certificates section below.

  • Opaque-Signed and Encrypted S/MIME messages: When S/MIME messages are received in Windows 8 Mail, it displays an email item with a message body that begins with “This encrypted message can’t be displayed.”

    To view email items in the S/MIME format, users must open the message using Outlook Web App, Microsoft Outlook, or another email program that supports S/MIME messages. For more information, see Opaque-Signed and Encrypted S/MIME Message on MSDN.

Self-Signed Certificates

Users may experience connectivity errors when trying to connect to an Exchange servers that require self-signed certificates. The user may receive the following error messages.

Unable to connect. Ensure the information entered is correct.

<Email address> is unavailable

NOTE This issue may occur because the Mail app cannot connect to Exchange by using self-signed certificates.

Consider the following options to resolve this issue.

    1. Option 1: Install a certificate that is signed by a Microsoft-trusted root certification authority (CA) on the server

      This enables Exchange to work for all clients without prompting. For more information about the trust root CAs, see the following topics on TechNet:

    2. Option 2: Install a server’s self-signed certificate on a device

      This enables Exchange to work for Windows 8 devices that have the certificate installed.

    Note To install a self-signed certificate for a domain’s certification authority, the administrator must provide a certificate file (.cer). The certificate can be installed to the trusted root certificate authority store for either of the following options:

    • For the current user This option does not require admin rights but must be completed for each user on the device.
    • For the local device This option requires administrator rights and needs to be done only one time for a device.

    The user or the system administrator can use the .cer file to install the certificate. To do this, use one of the following methods:

    • Command-line tool

      At an elevated command prompt, run the following command:

      certutil.exe -f -addstore root <name_of_certificatefile>.cer

      NOTE The command installs the certificate for all users on the device.

    • User interface

      1. Double-click the certificate file. A certificate dialog opens.
      2. Click Install Certificate. A Certificate Import Wizard window opens.
      3. Select the option to install the certificate for only the current user or for the local device.
      4. Select Place all certificates in the following store
      5. Click Browse to open the store selection dialog. Select Trusted Root Certification Authorities.
      6. Select the store, and then click Ok. You are returned to Certificate Import Wizard dialog, and the certificate store and certificate to be installed into that store are displayed.

    Troubleshooting Windows 8 Mail Client Connectivity

    If Windows 8 Mail users can't successfully connect to their accounts, consider the following:

    • Verify that the user is using the latest version of the Windows 8 Mail app. A user can check for updates to the Windows 8 Mail app by doing the following: from the Start screen, go to Store > Settings > App updates > Check for updates.
    • The user should wait a few minutes and try again.
    • If the account is a cloud-based email account that requires registration (for example, a Microsoft Office 365 account), the user must register their account before they can set up their account in Windows 8 Mail. If the user is a Microsoft Office 365 user, they register their account when they sign in to Office 365 for the first time. If the user is not an Office 365 user, the user registers their account when they sign in to their account using Microsoft account or Outlook Web App.

    TIP The user will see the following message if they haven't registered their account. In Windows 8 Mail, you will see the following message:
    “We couldn’t find the settings for. Provide use with more info and we’ll try connecting again.”

    For information about signing into Outlook Web App or the Office 365 Portal, see Sign In to Outlook Web App.

    After the user signs in to your account using Outlook Web App, the user should sign out, and then try to connect using Windows 8 Mail.

    What else do I need to know?

    Updates

    • 11/26/2012: Updated info about AllowNonProvisionableDevices setting in EAS policies.
    • 11/27/2012: Added links to EAS policy documentation.
    • 11/27/2012: Added info about Public Folder support in IMAP and link to IMAP documentation.

    Configure certificate-based authentication for Exchange ActiveSync

    0
    0

    In previous posts, we have discussed certificate based authentication (CBA) for Outlook Web App, and Greg Taylor has covered publishing Outlook Web App and Exchange ActiveSync (EAS) with certificate based authentication using ForeFront TMG in this whitepaper. Certificate based authentication can also be accomplished using ForeFront Unified Access Gateway.

    In this post, we will discuss how to configure CBA for EAS for Exchange 2010 in deployments without TMG or UAG.

    To recap some of the common questions administrators and IT decision-makers have regarding CBA:

    What is certificate based authentication?
    CBA uses a user certificate to authenticate the user/client (in this case, to access EAS). The certificate is used in place of the user entering credentials into their device.

    What certificate based authentication is not:
    By itself, CBA is not two-factor authentication. Two-factor authentication is authentication based on something you have plus something you know. CBA is only based on something you have.

    However, when combined with an Exchange ActiveSync policy that requires a device PIN, it could be considered two-factor authentication.

    Why would I want certificate based authentication?
    By deploying certificate based authentication, administrators gain more control over who can use EAS. If users are required to obtain a certificate for EAS access, and the administrator controls certificate issuance, access control is assured.

    Another advantage: Because we're not using the password for authentication, password changes don't impact device access. There will be no interruption in service for EAS users when the they change their password.

    Things to remember:
    There will be added administration overhead. You will either need to stand up your own internal Public Key Infrastructure (PKI) using Active Directory Certificate Services (AD CS, formerly Windows Server Certificate Services) or a 3rd-party PKI solution, or you will have to purchase certificates for your EAS users from a public certification authority (CA). This will not be a one-time added overhead. Certificates expire, and when a user’s certificate expires, they will need a new one, requiring either time invested in getting the user a new certificate, or budget invested in purchasing one.

    Prerequisites:

    You need access to a CA for client certificates. This can be a public CA solution, individual certificates from a vendor, or an Active Directory Certificate Services solution. Regardless, the following requirements must be met:

    • The user certificate must be issued for client authentication. The default User template from an AD CS server will work in this scenario.
    • The User Principal Name (UPN) for each user account must match the Subject Name field in the user's certificate.
    • All servers must trust the entire CAtrust chain. This chain includes the root CA certificate and any intermediate CA certificates. These certificates should be installed on all servers that may require them, to include (but not limited to) ISA/TMG/UAG server(s) and the Client Access Server (CAS).
    • The root CA certificate must be in the Trusted Root Certification Authorities store, and any intermediate CA certificates in the intermediate store on all of these systems. The root CA certificate, and intermediate CA certificates must also be installed on the EAS device.
    • The user’s certificate must be associated with the user’s account in Active Directory

    Client Access Server Configuration

    To configure the Client Access server to enforce CBA:

    1. Verify if Certificate Mapping Authentication is installed on the server.

    1. Right click on Computer in the start menu and choose Manage.
    2. Expand Roles and click on Web Server (IIS)
    3. Scroll down to the Role Services section. Under the Security section you should see Client Certificate Mapping Authentication installed.

    image

    • If you don't see Client Certificate Mapping Authentication installed, click add Role Services> (scroll) Security and select Client Certificate Mapping Authentication and then click Install.

    image

    • Reboot your server.

        2. Enable Active Directory Client Certificate Authentication for the server root in IIS.

        1. Start IIS Manager
        2. Click on the Server Name.
        3. Double click Authentication in the middle pane.

          image

        4. Right click on Active Directory Client Certificate Authentication and select Enable

          image

        5. When this is complete, restart the IIS Admin service from the Services console (or use Restart-Service IISAdmin" from the Shell).

          Important: IISreset does not pick up the changes properly. You must restart this service.

          image

        3. Require Client Certificates in Exchange management console.

        1. In the Exchange Management Console, expand Server Configuration and then select the Client Access server you want to configure
        2. On the Exchange ActiveSync tab, right click on the Microsoft-Server-ActiveSync directory and choose Properties.
        3. On the Authentication tab:
          1. Clear the Basic authentication (password is sent in clear text) checkbox
          2. Select Require client certificates

            image

        4. Modify the ActiveSync XML configuration file to allow Client Certificate Mapping Authentication.

        1. In IIS manager open the configuration editor under the Microsoft-Server-ActiveSync directory.

          image

        2. Browse the option for clientCertificateMappingAuth and set the value to True

          image

          image

        Once this is configured, all that's left to do is client configuration.

        Client Configuration

        You'll need to get the user’s certificate to the device. This will be accomplished in different ways for different devices. Some possibilities include:

        • Make the Trusted Root Certification Authority (Root CA) certificate available on a web site or other means of distribution.
        • Make the user’s certificate, including the private key, available on a website or other means of distribution.

          Caution: Use appropriate security measures to ensure that only the user who owns the certificate is able to access it from the device.

        • If the device supports external storage, you can place the certificate on a memory card or other external storage device and install it from the card.
        • Some devices have a certificate manager available for a host operating system. You can plug the device into your computer, run the certificate manager and install the certificate.

        Once the certificate is on the device, the user can configure the Exchange ActiveSync client (usually a mail app) on the device. When configuring EAS for the first time, users will be required to enter their credentials. When the device communicates with the Client Access Server for the first time, users will be prompted to select their certificate. After this is configured, if users check the account properties, they'll see a message similar to the following:

        Microsoft Exchange uses certificates to authenticate users when they log on. (A user name and password is not required.)

        Exchange Server 2003 Mailbox Coexistence

        This is an added step that requires some simple changes, and must be performed whether TMG is used to access Exchange 2010 or not. Use the following steps to enable this for access to Exchange 2003 mailboxes.

        1. Apply the hotfix from the following article (or one that has a later version of EXADMIN.DLL) to the Exchange 2003 servers where the mailboxes are homed.

          937031 Event ID 1036 is logged on an Exchange 2007 server that is running the CAS role when mobile devices connect to the Exchange 2007 server to access mailboxes on an Exchange 2003 back-end server

        2. The article instructs you to run a command to configure IIS to support both Kerberos and NTLM. You must run the command the command prompt using CSCRIPT, as shown below:

          1. Click Start> Run> type cmd and press Enter.
          2. Type cd \Windows\System32\AdminScripts and press Enter.
          3. Type the following command and press enter:

            cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders "Negotiate,NTLM"

      1. On the Exchange 2003 mailbox server, launch Exchange System Manager and follow these steps:

        1. Expand the Administrative Group that contains the Exchange 2003 server.
        2. Expand Servers> expand <server name>> Protocols> HTTPExchange Virtual Server
        3. Right click the Microsoft-Server-ActiveSync virtual directory and select Properties
        4. On the Access tab, click Authentication and ensure that only Integrated Windows Authentication checkbox is checked.
      2. Use the following steps to configure the Exchange 2010 to Exchange 2003 communication for Kerberos Constrained Delegation (KCD).

        1. Open Active Directory Users and Computers on the CAS
        2. Right click the CAS computer account > Properties
        3. In the Delegation tab, select Trust this computer for delegation to specified services only
        4. Select Use any authentication protocol option and then click Add
        5. In the Add Services window, click Users or Computers and enter the name of the Exchange 2003 server that the CAS is delegating to
        6. Click OK
        7. A list of Service Principal Names (SPN) will be displayed for your server.
        8. Select the appropriate HTTP SPN for the Exchange 2003 server. You'll need to add the correct SPN, HTTP/serverFQDN

          Note: You may need to add the SPN as per Setspn Overview

      3. Thanks to:
        DJ Ball for his previous work in documenting certificate based authentication for Outlook Web App (see How to Configure Certificate Based Authentication for OWA - Part I and How to Configure Certificate Based Authentication for OWA - Part II
        Mattias Lundgren, for starting the documentation process on certificate based authentication for EAS.
        DJ Ball and Will Duff for reviewing this document.
        Henning Peterson and Craig Robicheaux for reviewing this document.
        Greg Taylor for technical review.

        Jeff Miller

      Exchange Server 2013 Reaches General Availability

      0
      0

      Back in October, we announced that the Release to Manufacturing (RTM) build of Exchange Server 2013 was signed off. Since that time, we’ve been focusing our efforts on releasing the next version of Exchange through multiple distribution channels to our business customers.

      Today, we’ve reached another important milestone – The Exchange team is excited to announce the general availability of Exchange Server 2013. You can download the bits from TechNet today and evaluate the product for 180 days. You can also sign up for the Office 365 Preview to get the most current Exchange experience in the cloud in just a few minutes.

      For those of you who wish to roll out Exchange Server 2013 in greenfield environments, or in labs and test environments to evaluate new features and test with LOB applications, you can start right away. If you are running an Exchange 2010 or 2007 environment, you’ll need Exchange Server 2010 SP3 or 2007 roll up in order to upgrade. We know you are eager to get moving to the new version, so we are hard at work putting the finishing touches on Exchange 2010 SP3 and the roll up, which are on track for release in Q1 of calendar year 2013.

      If you haven’t already, we encourage you to learn more about Exchange Server 2013 by reviewing TechNet documentation or attending an Ignite training session. It’s a good idea to evaluate prerequisites and system requirements at this time, as well as become familiar with Exchange’s simplified building block architecture, so that you can get a head start on hardware sizing, planning and purchasing.

      The EHLO team has been adding more technical content on the new Exchange since the RTM announcement:

      …and we will continue to publish new Exchange articles to EHLO in the coming months, so keep checking back! Thanks again for your continued support, and please keep the feedback coming.

      Exchange Team

      Decommissioning your Exchange 2010 servers in a Hybrid Deployment

      0
      0

      Many organizations have chosen to configure a hybrid deployment with Exchange Online to take advantage of different features such as rich mailbox moves and cross-premises calendar free/busy sharing. This includes Exchange 2003, Exchange 2007 and Exchange 2010 organizations that require a long-term hybrid configuration with Exchange Online and organizations that are using a hybrid deployment as a stepping stone to migrating fully to Exchange Online. So, at what point should these organizations decide to get rid of their on-premises Exchange servers used for the hybrid deployment? What if they have moved all of the on-premises mailboxes to Exchange Online? Is there a benefit to keeping on-premises Exchange servers? While it may seem like a no-brainer, the decision to get rid of the on-premises Exchange servers is not simple and definitely not trivial.

      Mailbox Management

      Organizations that have configured a hybrid deployment for mailbox management and hybrid feature support have also configured Office 365 Active Directory synchronization (DirSync) for user and identity management. For organizations intending on keeping DirSync in place and continuing to manage user accounts from the on-premises organization, we recommend not removing the last Exchange 2010 server from the on-premises organization. If the last Exchange server is removed, you cannot make changes to the mailbox object in Exchange Online because the source of authority is defined as on-premises. The source of authority refers to the location where Active Directory directory service objects, such as users and groups, are mastered (an original source that defines copies of an object) in a hybrid deployment. If you needed to edit most mailbox settings, you would have to be sure the Active Directory schema was extended on-premises and use unsupported tools such as Active Directory Service Interfaces Editor (ADSI Edit) for common administrative tasks. For example, adding a proxy address or putting a mailbox on litigation hold when there isn’t an Exchange Management Console (EMC) or Exchange Management Shell (Shell) on-premises becomes difficult and these simple (and other more complex) tasks cannot be done in a supported way.

      Note: A hybrid deployment is not required in order to manage Exchange objects from an on-premises organization. You can effectively manage Exchange objects with an on-premises Exchange server even if you do not have an organization relationship, Federation Trust, and third-party certificate in place. This Exchange server gives you a supported method for creating and managing your Exchange recipient objects. It is recommended to use Exchange Server 2010 for management tasks since this will give you the option to create objects such as remote mailboxes with the New-RemoteMailbox cmdlet. The server role needed is at least a Client Access Server (CAS) role, for management tools to work properly.

      Online Organizations without On-Premises Exchange Servers

      Some Exchange Online organizations may have removed all Exchange servers from their on-premises organization and have felt the user management pain mentioned above first hand. Each situation is unique, but in many cases an Exchange 2010 server can simply be added back to the organization to simplify the management process. These organizations will need to ensure that a mail-enabled user is in place for all Exchange Online mailboxes in order to properly configure the mailboxes. Assuming DirSync is still deployed in the on-premises organization, duplicate object issues shouldn’t be a problem.

      Managing Users from the On-Premises Organization when Source of Authority is Online

      There are some organizations that have created an Office 365 service tenant and started to use Exchange Online only to realize they want to consolidate the user management tasks. There are also some organizations that came from hosted environments or migrated from Business Productivity Online Services (BPOS) where they did not manage their users from an on-premises organization. Now that they are in Office 365 and using Exchange Online, they want to simplify the user management process. In either case, if you have DirSync deployed and you are using Exchange Online, you should have an on-premises Exchange server for user management purposes.

      The process for changing the source of authority after the users are created in Office 365 would be to use the DirSync “soft match” process outlined here. This will allow organizations to manage the user account and Exchange Online mailboxes from the on-premises organization. Organizations need to verify that there was a mail-enabled user in the on-premises directory for the corresponding Exchange Online mailboxes. Organizations that haven’t had an Exchange server deployed previously will need to install an Exchange 2010 server. Office 365 for enterprises customers can obtain an Exchange Server 2010 license at no charge by contacting customer support. This license has limitations and doesn’t support hosting on-premises mailboxes.

      Removing the HybridConfiguration Object created by the Hybrid Configuration Wizard

      When a hybrid deployment is created using the Hybrid Configuration Wizard, the wizard creates the HybridConfiguration Active Directory object in the on-premises organization. The HybridConfiguration object is created when the New-HybridConfiguration cmdlet is called by the Hybrid Configuration Wizard. The object stores the hybrid configuration information so that the Update-HybridConfiguration cmdlet can read the settings stored in the object and use them to provision the hybrid configuration settings.

      Removing the HybridConfiguration object isn’t supported in Exchange Server 2010. There isn’t a cmdlet that will remove the HybridConfiguration object and the object can reside in Active Directory without adverse effects as long as the Hybrid Configuration Wizard isn’t run again.

      However, removing the HybridConfiguration object is supported in Exchange Server 2013. The new Remove-HybridConfiguration cmdlet will remove the HybridConfiguration object from the configuration container, however it will not disable or remove any existing hybrid deployment configuration settings.

      Although many people want to remove the HybridConfiguration object as part of their Exchange decommissioning plan, it isn’t critical and is optional.

      Removing a Hybrid Deployment

      The proper way to remove a hybrid deployment is to disable it manually. The following actions should be performed to remove the objects created and configured by the Hybrid Configuration Wizard:

      1. Re-point your organization’s MX record to the Office 365 service if it is pointing to the on-premises organization. If you are removing Exchange and don’t point the MX record to Office 365, inbound Internet mail flow won’t function.

      2. Using the Shell in the on-premises organization, run the following commands:

      Remove-OrganizationRelationship –Identity “On Premises to Exchange Online Organization Relationship”
      Remove-FederationTrust –Identity “Microsoft Federation Gateway”
      Remove-SendConnector “Outbound to Office 365”

      3. Using EMC, you can also remove the <your organization domain>.mail.onmicrosoft.com domain that was added as part of the email address policy for your organization.

      image

      4. OPTIONAL - Remove the remote domains created by the Hybrid Configuration wizard in the Exchange Online organization. From the EMC, select the Hub Transport in the Exchange Online forest node and remove all remote domains starting with “Hybrid Domain” shown below:

      image

      5. Remove the organization relationship from the Exchange Online organization with the following command. You must use Remote PowerShell to connect to Exchange Online connected to Exchange Online. For detailed steps, see Connect Windows PowerShell

      Remove-OrganizationRelationship –Identity “Exchange Online to On Premises Organization Relationship”

      6. OPTIONAL - Disable the Inbound and Outbound Forefront Online Protection for Exchange (FOPE) connectors created by the Hybrid Configuration Wizard. These connectors can be disabled using the FOPE Administration Console and the release option shown below:

      image

      Note: Removing or modifying objects with ADSIEDIT isn’t supported.

      Conclusion

      Most of the time the reason for most organizations that have configured a hybrid deployment, removing the last Exchange server from the on-premises environment will have adverse effects. In most cases, we recommend that you leave at least one Exchange 2010 Server on-premises for mailbox management unless you are getting rid of the on-premises messaging and identity management dependencies all together.

      Timothy Heeney

      Released: Update Rollup 5 v2 for Exchange 2010 SP2, Exchange 2010 SP1 RU8 and Exchange 2007 SP3 RU9

      0
      0

      Today the Exchange CXP team released the following update rollups to the Download Center. All three releases cover Security Bulletin MS12-080. Because this is a security release, the updates will also be available on Microsoft Update.

      Update Rollup 5-v2 for Exchange Server 2010 SP2

      This update contains a number of customer reported and internally found issues. For a list of updates included in this rollup, see KB 2785908 Description of Update Rollup 5 version 2 for Exchange Server 2010 Service Pack 2. We would like to specifically call out the following fixes which are included in this release:

      Note: Some of the following KB articles may not be available at the time of publishing this post.

      • 2748766 Retention policy information does not show "expiration suspended" in Outlook Web App when the mailbox is set to retention hold in an Exchange Server 2010 environment
      • 2712595 Microsoft Exchange RPC Client Access service crashes when you run the New-MailboxExportRequest cmdlet in an Exchange Server 2010 environment
      • 2750847 An Exchange Server 2010 user unexpectedly uses a public folder server that is located far away or on a slow network

      For DST Changes: http://www.microsoft.com/time

      Exchange Team

      Windows Management Framework 3.0 on Exchange 2007 and Exchange 2010

      0
      0

      Recently, Windows Update began offering the Windows Management Framework 3.0 as an Optional update. This includes all forms of update distribution, such as Microsoft Update, WSUS, System Center Configuration Manager and other mechanisms. The key bit here is that the Windows Management Framework 3.0 includes PowerShell 3.0.

      Windows Management Framework 3.0 is being distributed as KB2506146 and KB2506143 (which one is offered depends on which server version you are running - 2008 Sp2 or 2008 R2 Sp1).

      What does that mean to you?

      Windows Management Framework 3.0 (specifically PowerShell 3.0) is not yet supported on any version of Exchange except Exchange Server 2013 (which requires it). If you install Windows Management Framework 3.0 on a server running Exchange 2007 or Exchange 2010, you will encounter problems, such as Rollups that will not install, or the Exchange Management Shell may not run properly.

      We have seen rollups not installing with the following symptoms:

      • If rollup is installed through Microsoft Update, the installation might error with error code of 80070643
      • If rollup is installed from a download, the error displayed is “Setup ended prematurely because of an error."
      • In both cases, event log might show the error with an error code of “1603”

      Our guidance at this time is that Windows Management Framework 3.0 should not be deployed on servers running Exchange 2007 or Exchange 2010, or on workstations with the Exchange Management Tools for either version installed. If you have already deployed this update, it should be removed. Once the update is removed, functionality should be restored.

      Ben Winzenz

      Recipient Rate Limit Increase to 10K for Office 365 and Exchange Online

      0
      0

      In response to feedback from our customers, we have increased the recipient rate limit within Office 365 Enterprise (E1, E2, E3, E4, K1, and K2), Professionals and Small Businesses (P1), and Government plans (G1, G2, G3, and G4) to allow users to send email to up to 10,000 recipients per day. These new limits also apply to standalone Exchange Online plans (Kiosk, Plan 1, and Plan 2). Previously, the recipient rate limit for users of these plans had been set at a maximum of 1,500 recipients per day.

      Recipient rate limits exist to discourage users from sending large volumes of unsolicited commercial email, commonly referred to as spam. These limits protect our online service from becoming a source of spam and, as a result of these protections, keep our customers’ email messages flowing. Datacenter enhancements have allowed us to increase this limit while maintaining the same level of protection.

      These limits apply both to email messages sent within an organization and those delivered to external organizations. The best way to avoid exceeding the recipient rate limit is to use distribution groups when sending messages to large numbers of recipients. Distribution groups stored in the shared address book are counted as a single recipient toward the recipient rate limit. For more information, see Strategies to Support Bulk Email. Office 365 customers who need to send legitimate bulk commercial email — such as customer newsletters – should continue to use third-party providers that specialize in these services.

      If you would like more information on recipient rate limits, see Bulk Email and Daily Recipient Rate Limits. We made this change because of your feedback. Thank you for sharing your thoughts with us, and please keep it up!

      Thanks,

      Steve Chew

      Managing OAB in Exchange Server 2013

      0
      0

      The Exchange team blog article OAB in Exchange Server 2013 introduced the new Offline Address Book (OAB) generation and distribution architecture in Exchange Server 2013. Take a few moments to visit the article if you haven’t seen it yet or re-visit it for a quick refresher.

      The OAB management and administration is different in Exchange 2013 because of architecture changes. Additionally, the new Exchange Admin Center does not currently have options for managing OABs. This means that, at this time, you will need to use Exchange Management Shell for OAB-related tasks.

      This article takes you through commonly performed tasks in OAB administration and has a couple of real life scenarios to help understand the tasks better.

      Note: If you are in multi-forest Active Directory domain environment, make sure the Shell session has ViewEntireForest is enabled, else some of the commands in the article won’t return any output.

      Command to enable ViewEntireForest:

      Set-ADServerSettings -ViewEntireForest $true

      Creating a new OAB

      Creating a new OAB in Exchange 2013 no longer uses the -Server parameter. In order to create a new OAB, you should only specify the address lists to be required.

      The following example creates OAB for address list named “Global Address List FAB”

      New-OfflineAddressBook -Name OAB-FAB -AddressLists "Global Address List FAB"

      Identify the OAB generation server(s)

      The arbitration mailboxes in Exchange Server 2013 are assigned certain “Persisted capability” that defines the purpose/function of the arbitration mailbox.

      An arbitration mailbox with Persisted Capability “OrganizationCapabilityOABGen” is responsible for OAB generation. We will refer this mailbox as “Organization Mailbox” throughout the article.

      Exchange Server 2013 mailbox server hosting the Organization Mailbox will generate all OAB’s defined in the environment.

      For a non-DAG environment, use following command to identify the OAB Generation servers:

      Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,servername

      image

      For a DAG environment, identifying OAB generation server(s) is a two-step process.

      Step1: Identify the mailbox database hosting organization mailbox with OAB Gen capability.

      Use the following command to list the arbitration mailboxes with persisted capability of OABGen and database on which this mailbox is hosted:

      Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"} | ft name,database

      image

      Step2: Identify the mailbox server where the database hosting organization mailbox is mounted

      Use following command to identify active copy of mailbox database:

      Get-MailboxDatabaseCopyStatus db1

      image

      The server where database status is “mounted” is the current OAB generation server.

      Change the OAB generation server

      There are two methods of changing the OAB generation server.

      Move mailbox

      Move the organization mailbox to a mailbox database on a server intended to be designated as OAB Generation server.

      Example:

      DB1 is a single copy database present on the server Exch1 and hosts the organization mailbox. DB2 is mailbox database present on Exch2.

      The following command can be used to move the organization mailbox to DB2 and make Exch2 the OAB generation server.

      Get-Mailbox -Arbitration -database db1| where {$_.PersistedCapabilities –like “*oab*”} | New-MoveRequest -TargetDatabase db2

      This method is more suited for environments that have single copy of mailbox database hosting the Organization Mailbox.

      Activate the mailbox database on another server

      This method is suited for environments that have multiple copies of the mailbox database hosting Organization Mailbox.

      Example:

      DB1 hosts the Organization Mailbox and has copies on servers Exch1 and Exch2. DB1 is currently active on Exch1.

      The following command can be used to activate DB1 on Exch2 and therefore make it the OAB generation server:

      Move-ActiveMailboxDatabase DB1 -ActivateOnServer Exch2

      Note: Review guidelines mentioned in “Placement of Organization Mailbox” below before changing the OAB Generation server.

      Creating a new Organization Mailbox

      Administrators can create additional Organization Mailboxes for fault tolerance or for serving users in a geographically disbursed Exchange deployment.

      Creating a new Organization Mailbox is a two step process:

      Step1: Create a new arbitration mailbox

      New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com–DisplayName “OAB Mailbox for Seattle”

      Step2: Enable OABGen capability

      Set-Mailbox -Arbitration oabs -OABGen $true

      Note: Review guidelines mentioned in “Placement of Organization Mailbox” below before creating additional organization mailboxes.

      Changing the OAB Generation Schedule

      The OAB Generation till Exchange Server 2010 was based on a “Schedule” set on OAB properties. You might see a “Schedule” defined when viewing properties of Exchange 2013 OAB. But, the Exchange Server 2013 OAB generation does not take place according to the “Schedule” defined on OAB properties:

      image

      Instead, Exchange Server 2013 OAB Generation takes place according to OABGeneratorWorkCycle and OABGeneratorWorkCycleCheckpoint properties configured at the Mailbox Server.

      Example:

      image

      The values in the above screenshot mean OAB is generated once every day.

      Which Mailbox Server processed the OAB download request?

      The Exchange Server 2013 CAS role proxies the OAB download request to an appropriate Mailbox role server. The CAS role maintains log of each request it handles in the log files, present in folder %ExchangeInstallPath%\Logging\HttpProxy\OAB\

      These log files are an excellent tool to identify which mailbox server the CAS chose to serve the request.

      Information of some important fields from the log file:

      FieldDescription
      UrlStemUseful to identify the OAB being downloaded and also if this was a full download or incremental download
      AuthenticatedUserName of the User requesting the OAB
      AnchorMailboxDN of Organization Mailbox identified as the closest to serve the OAB request
      ServerHostNameCAS Server Name handling the request
      HttpStatusStatus code for Proxy action
      ProxyActionAction CAS Server performed for the request, it will be mostly “Proxy” for Exchange 2013 OAB
      TargetServerName of Mailbox role server to which request was proxied

      The log file can be imported in Excel for better readability.

      Example:

      image

      Forcing the OAB Generation

      The Exchange Server 2013 OAB generation can be forced to start immediately by two methods.

      Method 1: Update-OfflineAddresBook

      Below command will force OAB generation of an OAB named "Default Offline Address Book" across all organization mailboxes.

      Update-OfflineAddressBook "default offline address book"

      Note: This command initiates an RPC request to each mailbox server hosting an active organization mailbox.

      Method 2: Restart the Mailbox Assistant service.

      The Microsoft Exchange Mailbox Assistant service on Mailbox Role is responsible for generating OAB. Restarting this service generates all OAB’s defined in the environment on a specific mailbox server, if it’s hosting an active organization mailbox.

      Placement of Organization Mailbox

      Exchange Server 2013 CAS role proxies the OAB download request to a “nearest” mailbox server hosting an active Organization Mailbox. It can proxy the request in round robin fashion if it finds more than one organization mailbox active in same AD site. This might result in frequent full OAB download.

      Hence, current guidance is to plan organization mailbox placement such that you will have one organization mailbox active in an AD site. This applies to creating a new organization mailbox as well as to creating copies of mailbox database that hosts an organization mailbox.

      Scenarios

      The following scenarios discuss a real life situation to further explain the new OAB management methods.

      Scenario 1: Create a new Organization Mailbox

      Contoso has Exchange Server 2013 Mailbox & CAS role servers deployed at Dallas and Seattle sites. John, the Exchange Admin for Contoso, analyzes the http proxy log files on CAS servers and finds the OAB download request for Seattle users is going to Dallas servers. On further investigation, John finds he has just one Organization Mailbox present in Dallas, hence OAB download requests of all the users are going to Dallas server.

      He decides to create a new Organization Mailbox at Seattle site with following commands:

      Step1: Create a new Arbitration Mailbox

      New-Mailbox -Arbitration -Name "OAB Seattle" -Database DB2Seattle -UserPrincipalName oabs@contoso.com–DisplayName “OAB Mailbox for Seattle”

      Step2: Enable the Arbitration Mailbox with OABGen capability

      Set-Mailbox -Arbitration oabs -OABGen $true

      Scenario 2: Customize OAB Generation Schedule

      Ben is an administrator of Exchange 2013 deployment at Tail Spin Toys. The default OAB generation schedule does not suit them and they want to generate OAB approximately every fourth hour of the day.

      Ben will use following command to change properties of the mailbox servers that will be hosting the Organization Mailbox.

      Set-MailboxServer Exch1 -OABGeneratorWorkCycle 01.00:00:00 -OABGeneratorWorkCycleCheckpoint 04:00:00

      After a couple of days, John analyzes Event ID 17002 in application log and makes sure the OAB is generated every four hours.

      image

      Hopefully, you find this post useful! Let us know your feedback below!

      Bhalchandra Atre


      Exchange 2010 Calendar Repair Assistant

      0
      0

      Exchange 2010 had many new enhancements and improvements over prior versions of Exchange. One really cool feature was the introduction of the Calendar Repair Assistant (CRA). The CRA is a mailbox assistant that is configurable through the Exchange Management Shell and runs within the MS Exchange Mailbox Assistants service. Its intended purpose is to help maintain consistency of calendar meetings between an organizer and the attendees by comparing the meeting copies of the organizer and the attendees. Why did the Exchange Product Group build this really awesome component into Exchange 2010? I’m glad you asked. I want to take you on a journey back to…The Good Ole Days!

      The Good Ole Days

      In the “Good Ole Days” (or even as recently as last week), the Exchange support team logged numerous calls and cases on calendar meeting issues for prior versions of Exchange. Because of the flexibility allowed in terms of what end users can do with meetings in their calendars, meetings can become inconsistent across organizers and attendees calendars. These issues would range from inconsistent meeting times between organizers and attendees to meetings being “unknowingly” deleted from a user’s calendar. We saw cases where meetings would show up in Outlook but not a mobile device or vice versa. Sometimes meetings would be duplicated on a calendar or would lose their organizer. Delegates would reportedly make a change to a meeting but it wouldn’t show up on the mailbox owner’s mobile device. The list goes on. The troubleshooting of these issues, though normally pretty straight forward can be tedious and time consuming. I went ahead and included a troubleshooting reference guide for you below not only to point out how we would troubleshoot and identify these problems, but also just in case you’ve stumbled onto this blog and you’re experiencing something similar!

      Exchange calendar troubleshooting reference

      Getting to the most recent service pack and update of your Outlook client and Exchange Server is very important as doing that might actually address your reported problems. Depending on the type of issue you are experiencing, there are several different ways to troubleshoot. If you are trying to determine why a meeting keeps changing or is moved to the deleted items folder, etc. MFCMapi is a good tool to use. You can launch MFCMapi and connect to the mailbox profile of the user that is reporting the issue. Find the calendar item that you are looking for and save out the properties of that item to a text file. Search for the PR_LAST_MODIFIER_NAME, PR_LAST MODIFIED_DATE, PR_SENDER_EMAIL, and PR_SENT_REPRESENTING_NAME. These properties will paint a pretty good picture for you. Often times we’ve seen that the last user to modify the item is either a service account for a MAPI/CDO device, a delegate, or the mailbox owner themselves.

      Another great tool you can use to see what is happening to a meeting is Exchange Trace or “Trace Control” which can be found in the Exchange Troubleshooting Assistant in Exchange 2007 and 2010. You can setup your trace, check all of the boxes under “Trace Types” and then on the “Components to Trace” you will select “Store” with the following “Trace Tags”: tagCalendarChange, tagCalendarDelete, tagMtgMessageChange, tagMtgMessageDelete. You can then setup a mailbox filter for the mailbox in question and kick off the trace. At this point you will need to reproduce the issue (or wait until it reproduces). Once it does stop the trace. You’ll need to get with Microsoft support at this point to convert and analyze the trace for you.

      One of my colleagues over on the Outlook team, Randy Topken, created a great tool called CalCheck. It performs a wide variety of tests and is very helpful in troubleshooting Calendar issues. I won’t go through all of them as he has published everything you need to know here: CalCheck - The Outlook Calendar Checking Tool.

      There are many other issues that we have encountered, but this is a glimpse of the most common types of issues we have seen (and actually continue to see) and how we go about troubleshooting those problems. Hopefully this gives you a little insight as to why we were so excited to see the Calendar Repair Assistant in Exchange 2010. I’ve included some additional links to assist you in troubleshooting calendar below:

      CRA RTM

      Now let’s get to the heart of this article, THE CRA! The CRA was built to detect and correct calendar inconsistencies like I described above between a meeting organizer and attendees. The CRA must be configured through the Exchange Management Shell in order to run, as it is not enabled by default. Once enabled, the CRA will run against all mailboxes on the server you have configured it for. You can disable it for specific mailboxes by using the Set-Mailbox cmdlet and setting the CalendarRepairDisabled to True. In the RTM release of Exchange 2010, the CRA was a time-based assistant that was configured to run on a specified schedule and could not be throttled to adjust for server resource utilization. CRA made decisions only by comparing an organizer’s copy of a meeting with the attendee’s copy of the meeting. CRA uses the organizer’s meeting copy as the master and assumes it is the correct copy. It then checks attendee response status and assumes that the attendee’s response status is correct and updates the tracking information for the organizer. The problem was that CRA had no idea of how the inconsistencies occurred, meaning it didn’t take into account client intent i.e an attendee intentionally changes a meeting start time or location on their own calendar. One of the biggest issues we saw with this lack of client intent checking in RTM was if an attendee deleted a meeting from their calendar but did not send an update to the organizer, the CRA would recreate the meeting in the attendees calendar and would continue to do so until the attendee sent a response to the organizer (this has been corrected in SP1). When the CRA detects an inconsistency on a calendar, it issues a special meeting message called a Repair Update Message. The message is processed by the Calendar Attendant and then the message is placed in the user’s Deleted Items folder. Any repairs made are recorded in the CRA log (see Troubleshooting CRA below).

      CRA SP1 and later

      Exchange 2010 SP1 saw some pretty cool changes to the CRA. As mentioned earlier, in the RTM version CRA was time based and ran on a specified schedule. In SP1 and later this changed to a throttle based assistant to help prevent it from impacting server resources or end user experience. You can enable CRA with the Set-MailboxServer cmdlet. You will need to set the CalendarRepairWorkCycle and the CalendarRepairWorkCycleCheckpoint. The work cycle is the time span allocated for CRA to scan and process all mailboxes on the server i.e. if this is set to seven days, that means every mailbox on the server will be processed once every seven days. The throttling assistant calculates the slowest pace at which mailboxes can be processed by dividing the total number of mailboxes by the work cycle. There is also a built in mechanism to monitor certain resources like store and throttle the processing back if the load starts to rise. The checkpoint is the period of time in which the list of mailboxes in the CRA’s queue is refreshed during the existing work cycle, adding new mailboxes, moved mailboxes and mailboxes that have not processed yet into its queue. For example, the following command will set the CRA to check all mailboxes on the server once every seven days and refresh its work queue every day with the list of calendars that still need to process repairs within that seven day period:

      Set-MailboxServer –Identity MBXSRV1 –CalendarRepairWorkCycle 7.00:00:00 –CalendarRepairWorkCycleCheckPoint 1.00:00:00

      You can verify the settings for calendar repair options that are set for all mailbox servers by running the following in Exchange Management Shell:

      Get-MailboxServer | fl name,*calendar*

      Another great change in SP1 was the introduction of “client intent”. The CRA can now distinguish intentional versus unintentional inconsistencies between a meeting organizer and attendees. When the CRA is running against an attendee calendar, it will validate a meeting item against the organizer’s copy. If it is running against the organizer, it will validate the item against all attendees. The CRA will correct inconsistencies, but only for mailboxes on the server for which it is running. It reads from other Exchange 2010 mailbox servers, but each server enabled for calendar repair will have its own instance of the CRA running that is responsible for the mailboxes on that server. When the CRA finds an inconsistency, it goes about determining client intent by using snapshots of calendar items that are stored in something called the Calendar Version Store (CVS) and calendar metadata. Before a calendar item is changed, the Exchange 2010 copy on write functionality takes a snapshot of the calendar item and stores it along with additional metadata (like the source or the application that initiated the change) in the root of the Recoverable Items folder for a default 120 days before being purged. The Calendar Version Store maintains a historical record of these calendar item snapshots that are in the Recoverable Items folder. Client intent metadata is added to a calendar item as a named property: Name id = 0x0015 (dispidClientIntent), Named Prop GUID = 11000E07-B51B-40D6-AF21-CAA85EDAB1D0. Any non-zero Hex value represents an intentional change. Before a specific change is made to a calendar item, the snapshot is taken which preserves the existing metadata as well. When the CRA is determining client intent, it queries the Calendar Version Store. During the initial query, a special dynamic search folder is created called CalendarVersionStore in the root of the non-IPM subtree with a search scope of the IPM subtree and the Recoverable Items folder and criteria of all calendar items and meeting messages. Once this search folder is populated with the requested stored versions of a particular item from the Calendar Version Store, the CRA will go about determining client intent. It must first determine the target version of the particular item. It does this in one of two ways. The first method the CRA uses to determine the target version for client intent is when the resulting change, and not the state prior to the change, is important, ie an item is deleted. The Calendar Version store is sorted with the most recent item on top and then queried backwards. The oldest version found that is in the target state is used as the target version and it is the one whose client intent metadata is validated. Let’s say that item A is deleted and there are 4 snapshots of item A in the CVS. We will call them A4-A1. First A4 is queried and we see that it matches the target deleted state. Then A3 is queried and (for hypothetical purposes) we see it is also in the target deleted state. Then A2 is queried and the CRA determines that this snapshot is not in the target deleted state. Now the CRA will go back to A3 and review the metadata on it for client intent. Any non-zero entry on this item indicates an intentional change. The second method the CRA uses to determine the target version for client intent is when how an item transitioned into a certain state is important, ie the time or location on an attendee copy is different from the organizer’s copy. The main difference of this method is that it looks at the chain of snapshots from initial state to target state. If any snapshot in the chain does not show client intent, then the whole change is considered unintentional. Let’s say that the CRA finds that a meeting attendee for meeting B has a different time listed than the organizer. There are 5 snapshots of B in the attendees CVS, B5-B1. The CRA searches backwards (B5-B4-B3-B2-B1) and finds that B2 is the last snapshot with the same time as the organizer. It will then look at the metadata on B3-B5. If any of these have a zero entry, the entire chain is considered unintentional and will be corrected. All of the items in this chain must have a non-zero metadata client intent property value set for CRA to read this as an intentional change. In 2010 SP1, when the CRA detects an unintentional inconsistency it uses the same process (Repair Update Message) as it did in 2010 RTM. When the CRA detects an intentional location or time inconsistency, no repair action is taken on the calendar item. If there is an intentional missing organizer or attendee item, the CRA uses a special inquiry message to repair the item on the opposite calendar. For instance, if a meeting organizer deletes a meeting but doesn’t send out a cancellation, the meeting will still exist on the attendee’s calendar. The CRA will send a special inquiry message that is processed by the calendar attendant and trigger a normal meeting cancellation on the attendee’s calendar. For more information on CRA conflict detection and resolution logic see the “Conflict Detection and Resolution” section here: Understanding Calendar Repair

      Caveats

      • CRA does not run against resource mailboxes.
      • If the meeting organizer does not enable the “Request a response to this invitation” in OWA or “Request Responses” option in Outlook, calendar repair will not take place on that meeting.
      • If you set calendar repair to disabled for a specific mailbox, calendar repair will not take place for that mailbox. You can verify this with get-mailbox | ft name,CalendarRepairDisabled . If it’s set to true, then calendar repair is disabled.
      • If you disable the Calendar Version Store for a specific mailbox, then client intent cannot be determined. You can verify this get-mailbox | ft name,CalendarVersionStoreDisabled . If it’s set to true, then the Calendar Version Store is disabled.
      • The CRA only check calendar items for mailboxes that have the calendar attendant enabled (it is by default). This allows the Repair Update Message to be processed. See Set-CalendarProcessing.
      • The primary clients that write client intent metadata are OWA 2010 SP1 and Outlook 2010. Client intent for clients utilizing EWS or EAS may be limited. See Client Application Experience.
      • CRA will not change the meeting organizer, if it has been improperly changed.

      Troubleshooting CRA

      Troubleshooting calendar issues in 2010 can be approached in the same way as listed in the earlier troubleshooting section. There are some additional things you can look at when trying to see if the CRA processed a repair to a meeting and why. The first is the CRA log. It is stored on the mailbox server that it is running on and is located in <ExchangeInstallPath>\Logging\Calendar Repair Assistant and is in the format of CRA<date>yyyymmdd-<sequence>.<user>.log. Locate the CRA logs for specific users and then review them for any repairs that the CRA made. get-CalendarDiagnosticLog can be used to search the Calendar Version Store for a particular user and a particular item. Then you can use MFCMapi as outlined above to search the properties of the item and determine if there was positive client intent.

      Conclusion

      Hopefully I’ve shed a little light on the importance of the Calendar Repair Assistant. It is a critical component and has, in my opinion, reduced the number of cases in Exchange 2010 than what we saw for calendar issues in prior versions of Exchange. Troubleshooting, while you can still use the same techniques used in legacy versions of Exchange, has been simplified with the CalCheck, Calendar Repair Log, and using the Get-CalendarDiagnosticLog to pull calendar items from the Calendar Version Store for analysis on client intent cases.

      Additional resources

      I wanted to thank Mike Manjunath, Rob Whaley and Jonathan Runyon for their review of this blog post.

      Charles Lewis

      How to write an Exchange 2013 transport agent

      0
      0

      What is a Transport Agent?

      Transport agents allow Microsoft, developers in your organization and third-party vendors to hook into the Exchange transport pipeline with their code to process messages (e.g. an antivirus scanner for incoming email messages). Transport agents can process email messages that pass through the transport pipeline in many ways. An agent is a .Net assembly that has to be installed on the Exchange Client Access or Mailbox server. The agent is then loaded by the Exchange Transport service and invoked in the transport pipeline on the specified event. In Microsoft Exchange Server 2013, the transport pipeline is made of three different processes:

      • Front End Transport service:   This service runs on all Client Access servers and acts as a stateless SMTP proxy to route messages to and from the Transport service on a Mailbox server.
      • Transport service:   This service runs on all Mailbox servers and is virtually identical to the Hub Transport server role in previous versions of Exchange. Unlike previous versions of Exchange, the Transport service never communicates directly with the mailbox store. That task is now handled by the Mailbox Transport service. The Transport service routes messages between the Mailbox Transport service, the Transport service, and the Front End Transport service.
      • Mailbox Transport service:   This service runs on all Mailbox servers and consists of two separate services: Mailbox Transport Submission and Mailbox Transport Delivery. Mailbox Transport Delivery receives SMTP messages from the Transport service, and connects to the mailbox database using an Exchange remote procedure call (RPC) to deliver the message. Mailbox Transport Submission connects to the mailbox database using RPC to retrieve messages, and submits the messages over SMTP to the Transport service.

      Like the previous version of Exchange, Exchange 2013 transport provides extensibility through the Microsoft Exchange Server 2013 Transport Agents SDK. The Exchange 2013 version of the SDK is based on the Microsoft .NET Framework version 4.0 and allows third parties to implement the following predefined classes:

      • SmtpReceiveAgent
      • RoutingAgent
      • DeliveryAgent

      Note: This Article will concentrate mainly on how to implement and build a SmtpReceiveAgent. The SmtpReceiveAgentFactory and SmtpReceiveAgent classes provide support for the extension of the Microsoft Exchange Server 2013 Edge Transport behavior. You can use these classes to implement transport agents that are designed to respond to messages coming into and going out of the organization

      The following list explains the requirements for using transport agents in Exchange 2013.

      • The Transport service fully supports all the predefined classes in the SDK, which means that any transport agents written for Hub Transport server role in Exchange 2010 should work in the Transport service in Exchange 2013.
      • The Front End Transport service only supports the SmtpReceiveAgent class in the SDK, and third party agents can't operate on the OnEndOfData SMTP event.
      • The Mailbox Transport service doesn't support the SDK at all, so you can't use any third party agents in the Mailbox Transport service.

      Exchange 2013 updates to Transport Agent Management

      Due to the updates to the transport pipeline, the transport agent cmdlets need to distinguish between the Hub Transport service and the Front End Transport service, especially if Client Access server and Mailbox server are installed on the same physical server. All transport agent cmdlets now have the TransportService parameter. The values you can specify are Hub for the Hub Transport service and FrontEnd for the Front End Transport service. For example, to view the manageable transport agents in the Hub Transport service, run the command: Get-TransportAgent -TransportService Hub. To view the manageable transport agents in the Front End Transport service, run the command: Get-TransportAgent -TransportService FrontEnd. The TransportService parameter is available in all transport agent cmdlets:

      • Disable-TransportAgent
      • Enable-TransportAgent
      • Get-TransportAgent
      • Install-TransportAgent
      • Set-TransportAgent
      • Uninstall-TransportAgent

      StripIncomingLinkReceiveAgent

      This Transport Agent was designed and implemented to illustrate various Exchange 2013 transport agent functionality as well as stripping all the hyperlinks from the message body. This agent will illustrate the following functionality:

      1. Setting up the Visual Studio Environment to code and build the agent
      2. Adding Agent Event Handlers such as EndOfData and EndOfHeader to strip all the Hyperlink from the incoming message body
      3. Enumerate through all the message body part and select the text body part and then stripping the link.
      4. Removing any existing attachment from the message
      5. Skipping Health messages sent by the Exchange
      6. Process MimePart of the body
      7. Error Handling
      8. Implementing test unit to test various part of agent before installing on Exchange 2013.

      Setting up the Environment

      Visual Studio can be utilized to build and implement a transport agent. This lesson will show you how to build a transport agent to remove all HTML links from an incoming SMTP messages as well as illustrating on how to use the agent in the Exchange 2013 Front End Transport Service which was introduced in Exchange 2013.

      1. In Visual Studio 2012, Create a new project using Templates->Visual C#->Windows->Class Library and name the project StripIncomingLinkAgent

      2. Create a folder name Exchange under \StripIncomingLinkAgent\StripIncomingLinkAgent and copy the following DLLs from C:\Program Files\Microsoft\Exchange Server\Public

      Microsoft.Exchange.Data.Common.dll
      Microsoft.Exchange.Data.Transport.dll

      3. In Visual Studio 2012, Go to Solution Explorer, Right click the References and select “Add Reference…”

      4. Select Browse from the Reference Manager dialog and navigate to \StripIncomingLinkAgent\StripIncomingLinkAgent\Exchange

      5. Select both dll and click add and OK

      6. These two DLL will be used to integrate the agent to MSExchangeFrontEndTransport and MSExchangeTransport process.

      7. First step is to rename the Class1.cs generated by Visual Studio to a meaningful name (e.g. StripIncomingLinkReceiveAgent)

      8. Next Step is to create a ReceiveAgent class (naming the class StrinIncomingLinkReceiveAgent) which will inherit from SmtpReceiveAgent and add the proper references:

      using System;using System.Collections.Generic;using System.Linq;using System.Text;using System.Threading.Tasks;using System.Diagnostics;using System.IO;using Microsoft.Exchange.Data.Transport;using Microsoft.Exchange.Data.Transport.Smtp;using Microsoft.Exchange.Data.Transport.Routing;using Microsoft.Exchange.Data.Transport.Delivery;using Microsoft.Exchange.Data.Mime;using Microsoft.Exchange.Data.Transport.Email;using StripLink;using StripLink.Utilities;using StripIncomingLinkAgent.Configuration; 

      9. Before adding the business logic to our agent code and setup the agent call back, we need to setup a logging method to log events to the application event log:

      publicstaticvoid WriteLog(string message, EventLogEntryType entryType,
      int eventID, string proccessName) {try { EventLog evtLog = new EventLog(); evtLog.Log = s_EventLogName; evtLog.Source = proccessName;if (!EventLog.SourceExists(evtLog.Source)) { EventLog.CreateEventSource(evtLog.Source, evtLog.Log); } evtLog.WriteEntry(message, entryType, eventID); }catch (ArgumentException) { } catch (InvalidOperationException) { } }

      10. Next step is to register our call back with the Transport EventHandlers and create our agent:

      publicsealedclass StripLinkReceiveAgentFactory : SmtpReceiveAgentFactory
      {publicoverride SmtpReceiveAgent CreateAgent(SmtpServer server)
          {
              IConfigurationProvider config;
      
              config = new StaticConfigProvider
              {
                  ForceSinglePart = true,
                  ForceTextPlain = true,
                  FilterAuthenticated = true,
                  FilterTNEF = true,
                  HonorAntiSpamBypass = false,
                  SkipInternalMessages = false,
                  AlwaysFilterCAFETraffic = false
              };// To use the RegistryConfigProvider class - uncomment the line // below and comment above staticConfigProvider// config = new RegistryConfigProvider()returnnew StripIncomingLinkReceiveAgent(config);
          }
      }publicclass StripIncomingLinkReceiveAgent : SmtpReceiveAgent
      {privatestaticstring processName = "ExchagneStripIncomingAgent";privatestring machineName;private Process currentProcess;privatestaticstring FrontEndTransport = "ExchangeStripIncomingLinkFrontEndAgent";privatestatic RoutingAddress inboundProxy = new RoutingAddress(
      "inboundproxy@inboundproxy.com");privatebool m_IsTNEF = false;privatebool m_IsSummaryTNEF = false;/// <summary>/// Configuration provider. Should be set by constructor./// </summary>private IConfigurationProvider configProvider;publicstaticvoid WriteLog(string message, EventLogEntryType entryType, int eventID,
      string proccessName) { StripLinkHelper.WriteLog("ReceiveAgent: " + message, entryType, eventID,
      proccessName); }public StripIncomingLinkReceiveAgent(IConfigurationProvider config) { configProvider = config; this.OnEndOfData += new
      EndOfDataEventHandler(StripIncomingLinkEndOfDataHandler);this.OnEndOfHeaders += new
      EndOfHeadersEventHandler(StripIncomingLinkEndOfHeadersHandler); currentProcess = Process.GetCurrentProcess(); machineName = Environment.MachineName;if (currentProcess.ProcessName.ToLower().Contains("frontend")) { processName = FrontEndTransport; } }

      11. Now we can implement the Event Handler logic for End of Header event handler. We are keeping the Header Event handler simple. The code checks for health messages generated by Exchange and skip processing of those messages and it adds a marker to the header to notify the backend agent that header has been processed by frontend agent:

      privatebool IsHealthMessage(MailItem mailItem)
      {string domainName = mailItem.FromAddress.DomainPart;
          RoutingAddress adminEmailAddress = new RoutingAddress("Administrator@" + domainName);return (mailItem.Recipients.Contains(inboundProxy) ||
      mailItem.FromAddress.LocalPart.Contains("HealthMailbox") || mailItem.FromAddress.LocalPart.Contains("inboundproxy")); }privatevoid StripIncomingLinkEndOfHeadersHandler(ReceiveMessageEventSource source,
      EndOfHeadersEventArgs e) {try {if (IsHealthMessage(e.MailItem) &&
      !(currentProcess.ProcessName.ToLower().Contains("frontend")))return;// Add a header indicating that this was processed // by a Front End Server... StripLinkHelper.MarkAsProcessedByCAFE(machineName, e.Headers); }catch (Exception except) { WriteLog("EndofHeader Exception = " + except.ToString() + processName,
      EventLogEntryType.Error, 10, processName); } }

      12. End of Data Event handler has all the logic to parse the message body, create a single part (based on registry key value), convert the message to plain text (based on registry key value) and finally remove all the hyperlink from the message and save the body using StreamWriter:

      privatevoid StripIncomingLinkEndOfDataHandler(ReceiveMessageEventSource source,
      EndOfDataEventArgs e) {try { EmailMessage message = e.MailItem.Message; Body currentBody = message.Body;if(ShouldSkipMessage(e.MailItem, e.SmtpSession)) {// Message skipped, nothing to do.return; } // The following Actions are only valid for// pure mime messages (Not TNEF)if (!m_IsTNEF) {// Do we want to make it single part// (only Valid is no TNEF)// The goal here is to remove all other mime parts// (body types, attachments) to minimize // the surface area where hyperlinks can be found.// There is no point in removing hyperlinks in the body// if there is an HTML attachment in the email. :)if (configProvider.ForceSinglePart) {// Once again, we try to reduce the exposure to hyperlinks.// We do this by trying to get the lowest fidelity// body, and making that the only mimepart on the message.// We hope for Text/Plain body but it could be HTML. MimePart mimepartLowFidelity =
      StripLinkHelper.GetLowerFidelityBodyPart(currentBody);if (mimepartLowFidelity != null) {// We now remove any branches that do not contain// this node. Another option is to make the// message single part, however, this will// require merging headers of the source// part with the root part.// NOTE: This will break multipart/related messages // because they rely on the other parts// to store the other components (images, documents, etc).// This should not be an issue// if the target part is always text/plain. StripLinkHelper.MakeSingleBranch(mimepartLowFidelity); }else {// TODO: Decide what to do in this scenario...// Probably route to Admin...// This is the case for TNEF messages as there// is no MimePart associated with the body. WriteLog("Failed to get a low fidelity body.” +
      “Mime tree will not be simplified. Quarantine Message "
      +
      processName, EventLogEntryType.Error, 10, processName); source.Quarantine(e.MailItem.Recipients,
      "Could not find MimePart for the body.");return; } }// Force Plain text...if (configProvider.ForceTextPlain) { StripLinkHelper.ForcePlainTextIfNeeded(message); } }elseif(configProvider.ForceSinglePart) {// We do honor the ForceSinglePart for TNEF, we// assume this means we don't want any attachments// so for TNEF we simply remove the message attachments.// A seperate option could be added, TNEFRemoveAttachments// if this needs to be handle independent of// the ForceSinglePart settings. message.Attachments.Clear(); }// We now need to process the message. StripLinkHelper.ProcessEmailBody(message.Body);// TODO: For LegacyTNEF we thought we also needed to// filter the text/plain part that is included// for non-TNEF clients, but it appears modifying the body// also generates a new text/plain part so// the code below is not needed.//if (m_IsTNEF && !m_IsSummaryTNEF)//{// FilterTNEFTextPart(message);//} StripLinkHelper.MarkAsProcessedByFilteringAgent(message.RootPart.Headers,
      machineName); } catch (Exception except) { WriteLog("EndofData Exception = " + except.ToString() + processName,
      EventLogEntryType.Error, 10, processName); source.Quarantine(e.MailItem.Recipients,
      "StripIncomingLinkAgent - Error occurred: " + except.Message); } }

      13. Process Body method uses the regular expression class to remove any hyperlink or website address from the body of the message:

       

      publicclass TextToTextLinkProcessor : IHyperLinkProcessor
      {privateint m_LinkCount = 0;privateconststring s_RegExBodyString =
      @"((www\.|(http|https|ftp|news|file)+\:\/\/)
      [&#95;.a-z0-9-]+\.[a-z0-9\/&#95;:@=.+?,##%&~-]*[^.|\'|\# |!|\(|?|,| |>|<|;|\)])"
      ;privatebool m_bChanged = false;privatestring m_strReplacementText = string.Empty;publicbool WasChanged { get {return m_bChanged; } } publicvoid ProcessEmailBody(Body bodyMessage) { m_LinkCount = 0; string savedContent = string.Empty; Stream memStream; Encoding encoding = StripLinkHelper.GetEncodingFromBody(bodyMessage.CharsetName); if (bodyMessage.TryGetContentReadStream(out memStream)) {using (StreamReader streamRead = new StreamReader(memStream, encoding)) {// TODO: May also want to decide on size of message and// whether or not it should be processed if it is too large. savedContent = FilterText(streamRead.ReadToEnd()); }// Now write the new body only if it was changed/filtered.if (m_bChanged) {using (StreamWriter streamWriter = new
      StreamWriter(bodyMessage.GetContentWriteStream(), encoding)) { streamWriter.Write(savedContent); } } } } publicstring FilterText(string strText) { Regex rgx = new Regex(s_RegExBodyString, RegexOptions.IgnoreCase);string strFiltered = rgx.Replace(strText, new MatchEvaluator( match => {// If we got a match, mark it as changed. m_bChanged = true; m_LinkCount++;return m_strReplacementText; }));return strFiltered; }

      14. GetLowerFidelityBodyPart enumerates through all the available body type and return the plain text body:

      /// <summary>/// Finds the lowest fidelity MimePart associated to a Body,/// normally Text/Plain./// </summary>/// <param name="body">The body part that we want/// to find the lowest fidelity MimePart for.</param>/// <returns></returns>publicstatic MimePart GetLowerFidelityBodyPart(Body body)
      {// Nothing to work with if they are null...// Divided here for logging purposes..if (body == null)
          {returnnull;
          }elseif (body.MimePart == null)
          {returnnull;
      
          }
          MimePart bodyPart = body.MimePart; ;
      
          // If it is text already, then that's the lowest fidelity...if (body.BodyFormat == BodyFormat.Text)return body.MimePart;// Need to find lower fidelity body type at the same level.// If no parent, there are no children, so this would be the only// part at this level.// If it has a parent but the parent is not multipart then this will also// be the only child. so:// if (bodyPart.Parent == null || !bodyPart.Parent.IsMultipart)// The other option is to simply check that we have no siblings.if (bodyPart.PreviousSibling == null&& bodyPart.NextSibling == null)
          {return bodyPart;
          }// If we are here then we must have a parent and siblings. Get// the parent, find the lowest fidelity..
          IEnumerator<MimeNode> enumer = bodyPart.Parent.GetEnumerator();
          MimePart currentPart;while (enumer.MoveNext())
          {
              currentPart = (MimePart) enumer.Current;if (currentPart.ContentType.Equals(s_TextPlainContentType,
      StringComparison.OrdinalIgnoreCase)) {return currentPart; } }return bodyPart; }

      15. The complete Visual Studio project can be foundhere. You can build the project by simply selecting build from the “Build” pull down menu using the release version.

      16. Once the agent build is completed you can copy the StripIncomingLinkAgent from the \bin\release folder on the exchange server in the following folder:

      C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\SmtpAgents\StripIncomingLinkAgent

      17. Use the following cmdlet to install and enable the agent on the Front End Transport on CAS. Note: if your CAS and Mailbox servers are on separate machine then you need to launch a window powershell to prevent the powershell proxy:

      Launch a Window Powershell window and execute the following commands:

      C:\Program Files\Microsoft\Exchange Server\V15\bin> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
      Install-TransportAgent -Name "FrontEndStripIncomingLinkAgent" -TransportAgentFactory "StripIncomingLinkAgent.StripLinkReceiveAgentFactory" -AssemblyPath "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\SmtpAgents\StripIncomingLinkAgent\StripIncomingLinkAgent.dll" -TransportService FrontEnd
      Enable-TransportAgent -Identity "FrontEndStripIncomingLinkAgent" -TransportService FrontEnd

      18. User the following cmdlet to install and enable the agent on the back end Transport on Mailbox:

      Install-TransportAgent -Name "StripIncomingLinkAgent" -TransportAgentFactory "StripIncomingLinkAgent.StripLinkReceiveAgentFactory" -AssemblyPath "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\SmtpAgents\StripIncomingLinkAgent\StripIncomingLinkAgent.dll” -TransportService Hub
      Enable-TransportAgent -Identity "FrontEndStripIncomingLinkAgent" -TransportService Hub

      19. After installing the agent on back end, send an email from the pickup folder with a few link such as (www.msn.com, etc.)

      20. The agent will remove all the links from the email body. Please remember that this is a sample only.

      David Santamaria, Nasir Ali and Nasser Salemizadeh

      Exchange 2013 Server Role Architecture

      0
      0

      The Past: Exchange 2007 and Exchange 2010

      In 2005, we set out developing Exchange 2007. During the preliminary planning of Exchange 2007, we realized that the server architecture model had to evolve to deal with hardware constraints, like CPU, that existed at the time and would exist for a good portion of the lifecycle of the product. The architectural change resulted in five server roles, three of which were core to the product:

      1. Edge Transport for routing and anti-malware from the edge of the organization
      2. Hub Transport for internal routing and policy enforcement
      3. Mailbox for storage of data
      4. Client Access for client connectivity and web services
      5. Unified Messaging for voice mail and voice access

      E2007 Design
      Figure 1: Server role architecture in Exchange 2007 & Exchange 2010

      Our goal was to make these server roles autonomous units. Unfortunately, that goal did not materialize in either Exchange 2007 or Exchange 2010. The server roles were tightly coupled along four key dimensions:

      1. Functionality was scattered across all the server roles, thereby making it a requirement that Hub Transport and the Client Access server roles be deployed in every Active Directory site where Mailbox servers were deployed.
      2. This also necessitated a tight versioning alignment – a down-level Hub Transport or Client Access shouldn’t communicate with a higher version Mailbox server; in some cases this was enforced (e.g., Exchange 2007 Hub Transport servers cannot deliver messages to Exchange 2010 Mailbox servers), but in other cases they were not (e.g., an Exchange 2010 SP1 Client Access server can render data from an Exchange 2010 SP2 Mailbox server). The versioning restriction also meant that you could not simply upgrade a single server role to take advantage of new functionality – you had to upgrade all of them.
      3. The server roles were also coupled together from a geographical affinity perspective as well due to the middle tier server roles using RPC as the communication mechanism to the Mailbox server role.
      4. Similarly, from a user perspective, the server roles were also tightly coupled – a set of users that are served by a given Mailbox server, are always served by a given set of Client Access and Hub Transport servers.

      The functionality and versioning aspects are the key issues. To understand it better, let’s look at the following diagram:

      2010Island
      Figure 2: Inter-server communication across different layers of functionality

      As you can see from the above diagram, there are three layers: 1) Protocols 2) Business Logic and 3) Storage.  If you are familiar with the OSI model, you might believe the protocol layer is similar to the application layer and that data has to flow from the application layer through the other layers to get to the physical layer (or vice versa).  However, that is not the case in Exchange 2007 or Exchange 2010; a protocol can interact directly with the storage layer.  For example, the transport instance on Server1 (Exchange 2010 SP1) can deliver mail to the Store service on Server2 (Exchange 2010 SP2). The reverse is also true, the store can submit mail via the Store Submission service on Server2 to the transport service running on Server1. In either scenario, content conversion happens on the lower version server (as content conversion in this example happens within the transport components).  While a newer version interacting with an older version may not be problematic, the same cannot be said when the reverse is true as the older version simply does not know about any changes that exist in the newer version that may break functionality (hence, why we put in blockers in certain circumstances, or provide guidance on upgrade procedures).

      The end result is that in Exchange 2007 and Exchange 2010 deployments, the server roles are deployed as a single monolithic entity.

      The Present: Exchange Server 2013

      When we started our planning for Exchange Server 2013, we focused on a single architectural tenet – improve the architecture to serve the needs of deployments at all scales, from the small 100 user shop to hosting hundreds of millions of mailboxes in Office 365. This single tenet drove us to make major architectural changes and investments across the entire product. This shift is in part, because unlike when we were designing Exchange 2007, we are no longer CPU bound; in fact there is so much readily available CPU on modern server hardware, that the notion of dedicated server roles no longer makes sense as hardware ultimately is wasted (hence the recommendation in Exchange 2010 to deploy multi-role servers).

      In Exchange Server 2013, we have two basic building blocks – the Client Access array and the Database Availability Group (DAG). Each provides a unit of high availability and fault tolerance that are decoupled from one another. Client Access servers make up the CAS array, while Mailbox servers comprise the DAG.

      2013
      Figure 3: New server role architecture simplifies deployments

      So what is the Client Access server in Exchange 2013? The Client Access server role is comprised of three components, client protocols, SMTP, and a UM Call Router. The CAS role is a thin, protocol session stateless server that is organized into a load balanced configuration. Unlike previous versions, session affinity is not required at the load balancer (but you still want a load balancer to handle connection management policies and health checking). This is because logic now exists in CAS to authenticate the request, and then route the request to the Mailbox server that hosts the active copy of the mailbox database.

      The Mailbox server role now hosts all the components and/or protocols that process, render and store the data. No clients will ever connect directly to the Mailbox server role; all client connections are handled by the Client Access server role. Mailbox servers can be added to a Database Availability Group, thereby forming a high available unit that can be deployed in one or more datacenters.

      Unlike the past two generations, these two server roles do not suffer from the same constraints:

      1. Functionality is not dispersed across both server roles. All data rendering now occurs on the Mailbox server that hosts the active mailbox database copy. As we will discuss in more detail in a future article, the Client Access server role is merely a proxy.
      2. Versioning is also decoupled as a result of moving the data rendering stack to a single server role.
      3. Client Access servers and the Mailbox servers no longer leverage the chatty RPC protocol for client sessions, thereby removing the geographical affinity issues.
      4. From a user perspective, users do not need to be serviced by the Client Access servers that are located within the same Active Directory site as the Mailbox servers hosting the user’s mailboxes.

      If we return to the layering diagram, we can see how this changes:

      2013 islandv2
      Figure 4: Inter-server communication in Exchange 2013

      Instead of allowing communication between servers to occur at any layer in the stack, communication must occur between servers at the protocol layer. This ensures that for a given mailbox’s connectivity, the protocol being used is always served by the protocol instance that is local to the active database copy. In other words, if my mailbox is located on Server1 and I want to send a message to a mailbox on Server2, the message must be sent from Server1’s transport components to the transport components on Server2; content conversion of the message then occurs on Server2 as the message is injected into the store.  If I upgrade the Mailbox server with a service pack or cumulative update, then for a given mailbox hosted on that server, all data rendering and content conversions for that mailbox will be local, thus removing version constraints and functionality issues that arose in previous releases.

      Looking Ahead

      This article is the start of several articles focused on architecture and the investments we have made in Exchange Server 2013. Over the next several weeks:

      • We will delve into more specifics with respect to the server roles.
      • Discuss our investments with respect to storage.
      • Discuss sizing Exchange Server 2013.
      • Discuss load balancing and namespace planning.

      And for those of you that did not get a chance to attend MEC 2012, feel free to visit www.iammec.com/video and watch my technical architecture keynote.

      Conclusion

      Exchange Server 2013 introduces a new building block architecture that facilitate deployments at all scales. All core Exchange functionality for a given mailbox is always served by the Mailbox server where the mailbox’s database is currently activated. The introduction of the Client Access server role changes enables you to move away from complicated session affinity load balancing solutions, simplifying the network stack. From an upgrade perspective, all components on a given server are upgraded together, thereby virtually eliminating the need to juggle Client Access and Mailbox server versions. And finally, the new server role architecture aligns Exchange with being able to take advantage of hardware trends for the foreseeable future – core count will continue to increase, disk capacity will continue to increase, and RAM prices will continue to drop.

      Ross Smith IV
      Principal Program Manager
      Exchange Customer Experience

      Exchange 2013 Client Access Server Role

      0
      0

      In a previous article, I discussed the new server role architecture in Exchange 2013. This article continues the series by discussing the Client Access server role.

      While this Exchange server role shares the same name as a server role that existed in the last two Exchange Server releases, it is markedly different. In Exchange 2007, the Client Access server role provided authentication, proxy/redirection logic, and performed data rendering for the Internet protocol clients (Outlook Web App, EAS, EWS, IMAP and POP). In Exchange 2010, data rendering for MAPI was also moved to the Client Access server role.

      In Exchange 2013, the Client Access server (CAS) role no longer performs any data rendering functionality. The Client Access server role now only provides authentication and proxy/redirection logic, supporting the client Internet protocols, transport, and Unified Messaging. As a result of this architectural shift, the CAS role is stateless (from a protocol session perspective, log data that can be used in troubleshooting or trending analysis is generated, naturally).

      Session Affinity

      As I alluded to in the sever role architecture blog post, Exchange 2013 no longer requires session affinity at the load balancer. To understand this better, we need to look at how CAS2013 functions. From a protocol perspective, the following will happen:

      1. A client resolves the namespace to a load balanced virtual IP address.
      2. The load balancer assigns the session to a CAS member in the load balanced pool.
      3. CAS authenticates the request and performs a service discovery by accessing Active Directory to retrieve the following information:
        1. Mailbox version (for this discussion, we will assume an Exchange 2013 mailbox)
        2. Mailbox location information (e.g., database information, ExternalURL values, etc.)
      4. CAS makes a decision on whether to proxy the request or redirect the request to another CAS infrastructure (within the same forest).
      5. CAS queries an Active Manager instance that is responsible for the database to determine which Mailbox server is hosting the active copy.
      6. CAS proxies the request to the Mailbox server hosting the active copy.

      The protocol used in step 6 depends on the protocol used to connect to CAS. If the client leverages the HTTP protocol, then the protocol used between the Client Access server and Mailbox server is HTTP (secured via SSL using a self-signed certificate). If the protocol leveraged by the client is IMAP or POP, then the protocol used between the Client Access server and Mailbox server is IMAP or POP.

      Telephony requests are unique, however. Instead of proxying the request at step 6, CAS will redirect the request to the Mailbox server hosting the active copy of the user’s database, as the telephony devices support redirection and need to establish their SIP and RTP sessions directly with the Unified Messaging components on the Mailbox server.

      CAS Protocol Arch
      Figure 1: Exchange 2013 Client Access Protocol Architecture

      In addition to no longer performing data rendering, step 5 is the fundamental change that enables the removal of session affinity at the load balancer. For a given protocol session, CAS now maintains a 1:1 relationship with the Mailbox server hosting the user’s data. In the event that the active database copy is moved to a different Mailbox server, CAS closes the sessions to the previous server and establishes sessions to the new server. This means that all sessions, regardless of their origination point (i.e., CAS members in the load balanced array), end up at the same place, the Mailbox server hosting the active database copy.

      Now many of you may be thinking, wait how does authentication work? Well for HTTP, POP, or IMAP requests that use basic, NTLM, or Kerberos authentication, the authentication request is passed as part of the HTTP payload, so each CAS will authenticate the request naturally. Forms-based authentication (FBA) is different. FBA was one of the reasons why session affinity was required for OWA in previous releases of Exchange – the reason being that that the cookie used a per server key for encryption; so if another CAS received a request, it could not decrypt the session. In Exchange 2013, we no longer leverage a per server session key; instead we leverage the private key from the certificate that is installed on the CAS. As long as all members of the CAS array share the exact same certificate (remember we actually recommend deploying the same certificate across all CAS in both datacenters in site resilience scenarios as well), they can decrypt the cookie.

      Proxy vs. Redirection

      In the previous section, I spoke about CAS proxying the data to the Mailbox server hosting the active database copy. Prior to that, CAS has to make a decision whether it will perform the proxy action or perform a redirection action. CAS will only perform a redirection action under the following circumstances:

      1. The origination request is telephony related.
      2. For Outlook Web App requests, if the mailbox’s location is determined to be in another Active Directory site and there are CAS2013 members in that site that have the ExternalURL populated, then the originating CAS will redirect the request unless the ExternalURLin the target site is the same as in the originating site – in which case CAS will proxy (this is the multiple site single namespace scenario).

        Proxy-Referral
        Figure 2: Exchange 2013 Client Access Proxy and Redirection Behavior Examples

      3. For OWA requests, if the mailbox version is Exchange 2007, then CAS2013 will redirect the request to CAS2007.

      Outlook Connectivity

      For those of you paying attention, you may have noticed I only spoke about HTTP, POP, and IMAP. I didn’t mention RPC/TCP as connectivity solution that CAS supports. And that is for a very specific reason – CAS2013 does not support RPC/TCP as a connectivity solution; it only supports RPC/HTTP (aka Outlook Anywhere). This architecture change is primarily to drive a stable and reliable connectivity model.

      To understand why, you need to keep the following tenets in the back of your mind:

      1. Remember CAS2013 is an authentication and proxy/redirection server. It does no processing of the data (no rendering or transformation). It simply proxies the request to MBX2013 using the client protocol. In this case HTTP.
      2. CAS2013 and MBX2013 are not tied together from a user affinity or geographical perspective. You can have CAS2013 in one datacenter authenticate the request and proxy the request to a MBX2013 server in another datacenter. To enable this we had to change the communication protocols used between server roles. Moving away from RPC to the client protocols that are more tolerant of throughput & latency over WAN/Internet connections.
      3. For a given mailbox, the protocol that services the request is always going to be the protocol instance on the Mailbox server that hosts the active copy of the database for the user’s mailbox. This was done to ultimately uncouple versioning and functionality issues we’ve seen in the past two generations (i.e., have to deploy CAS2010, HT2010, MBX2010 together to get certain functionality and upgrading one doesn’t necessarily give you new capabilities and may break connectivity).

      The last item is tied to this discussion of why we have moved away from RPC/TCP as a connectivity solution. In all prior releases the RPC endpoint was a FQDN. In fact, the shift to the middle tier for RPC processing in CAS2010 introduced a new shared namespace, the RPC Client Access namespace. By moving RPC Client Access back to the MBX2013 role, this would have forced us to use either the MBX2013 FQDN for the RPC endpoint (thus forcing an Outlook client restart for every database *over event) or a shared namespace for the DAG.

      Neither option is appropriate and adds to the complexity and support of the infrastructure. So instead, we changed the model. We no longer use a FQDN for the RPC endpoint. Instead we now use a GUID. The mailbox GUID, to be precise (along with a domain suffix to support multi-tenant scenarios). The mailbox GUID is unique within the (tenant) organization, so regardless of where the database is activated and mounted, CAS can discover the location and proxy the request to the correct MBX2013 server.

      RPC Endpoint
      Figure 3:RPC Endpoint Changes

      This architectural change means that we have a very reliable connection model – for a given session that is routed to CAS2013, CAS2013 will always have a 1:1 relationship with the MBX2013 server hosting the user’s mailbox. This means that the Mailbox server hosting the active copy of the user’s database is the server responsible for de-encapsulating the RPC stream from the HTTP packets.  In the event a *over occurs, CAS2013 will proxy the connection to MBX2013 that assumes the responsibility of hosting the active database copy. Oh, and this means in a native Exchange 2013 environment, Outlook won’t require a restart for things like mailbox moves, *over events, etc.

      The other architectural change we made in this area is the support for internal and external namespaces for Outlook Anywhere. This means you won’t need to deploy split-brain DNS or deal with all Outlook clients using your external firewall or load balancer due to our change in MAPI connectivity.

      Third-Party MAPI Products

      I am sure that a few of you are wondering what this change means for third-party MAPI products. The answer is relatively simple – these third-party solutions will need to leverage RPC/HTTP to connect to CAS2013. This will be accomplished via a new MAPI/CDO download that that has been updated to include support for RPC/HTTP connectivity. It will be released in the first quarter of calendar year 2013. To leverage this updated functionality, the third-party vendor will either have to programmatically edit the dynamic MAPI profile or set registry key values to enable RPC/HTTP support.

      I do also want to stress one key item with respect to third-party MAPI support. Exchange 2013 is the last release that will support a MAPI/CDO custom solution. In the future, third-party products (and custom in-house developed solutions) will need to move to Exchange Web Services (EWS) to access Exchange data.

      Namespace Simplification

      Another benefit with the Exchange 2013 architecture is that the namespace model can be simplified (especially for those of you upgrading from Exchange 2010). In Exchange 2010, a customer that wanted to deploy a site-resilient solution for two datacenters required the following namespaces:

      1. Primary datacenter Internet protocol namespace
      2. Secondary datacenter Internet protocol namespace
      3. Primary datacenter Outlook Web App failback namespace
      4. Secondary datacenter Outlook Web App failback namespace
      5. Primary datacenter RPC Client Access namespace
      6. Secondary datacenter RPC Client Access namespace
      7. Autodiscover namespace
      8. Legacy namespace
      9. Transport namespace (if doing ad-hoc encryption or partner-to-partner encryption)

      As I previously mentioned, we have removed two of these namespaces in Exchange 2013 – the RPC Client Access namespaces.

      Recall that CAS2013 proxies requests to the Mailbox server hosting the active database copy. This proxy logic is not limited to the Active Directory site boundary. A CAS2013 in one Active Directory site can proxy a session to a Mailbox server that is located in another Active Directory site. If network utilization, latency, and throughput are not a concern, this means that we do not need the additional namespaces for site resilience scenarios, thereby eliminating three other namespaces (secondary Internet protocol and both Outlook Web App failback namespaces).

      For example, let’s say I have a two datacenter deployment in North America that has a network configuration such that latency, throughput and utilization between the datacenters is not a concern. I also wanted to simplify my namespace architecture with the Exchange 2013 deployment so that my users only have to use a single namespace for Internet access regardless of where their mailbox is located. If I deployed an architecture like below, then the CAS infrastructure in both datacenters could be used to route and proxy traffic to the Mailbox servers hosting the active copies.  Since I am not concerned about network traffic, I configure DNS to round-robin between the VIPs of the load balancers in each datacenter.  The end result is that I have a site resilient namespace architecture while accepting that half of my proxy traffic will be out-of-site.

      namespace
      Figure 4: Exchange 2013 Single Namespace Example

      Transport

      Early on I mentioned that the Client Access Server role can proxy SMTP sessions. This is handled by a new component on the CAS2013 role, the Front-End Transport service. The Front-End Transport service handles all inbound and outbound external SMTP traffic for the Exchange organization, as well as, can be a client endpoint for SMTP traffic. The Front-End Transport Service functions as a layer 7 proxy and has full access to the protocol conversation. Like the client Internet protocols, the Front-End Transport service does not have a message queue and is completely stateless. In addition, the Front-End Transport service does not perform message bifurcation.

      The Front-End Transport service provides network protection – a centralized, load balanced egress/ingress point for the Exchange organization, whether it be POP/IMAP clients, SharePoint, other third-party or custom in-house mail applications, or external SMTP systems.

      For outgoing messages, the Front-End Transport service is used as a proxy when the Send Connectors (that are located on the Mailbox server) have the FrontEndProxyEnabled property set. In this situation, the message will appear to have originated from CAS2013.

      For incoming messages, the Front-End Transport service must quickly find a single, healthy Transport service on a Mailbox server to receive the message transmission, regardless of the number or type of recipients:

      • For messages with a single mailbox recipient, select a Mailbox server in the target delivery group, and give preference to the Mailbox server based on the proximity of the Active Directory site.
      • For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox server in the closest delivery group, based on the proximity of the Active Directory site.
      • If the message has no mailbox recipients, select a random Mailbox server in the local Active Directory site.

      Conclusion

      The Exchange 2013 Client Access Server role simplifies the network layer. Session affinity at the load balancer is no longer required as CAS2013 handles the affinity aspects. CAS2013 introduces more deployment flexibility by allowing you to simplify your namespace architecture, potentially consolidating to a single world-wide or regional namespace for your Internet protocols. The new architecture also simplifies the upgrade and inter-operability story as CAS2013 can proxy or redirect to multiple versions of Exchange, whether they are a higher or lower version, allowing you to upgrade your Mailbox servers at your own pace.

      New Outlook Calendar best practices document for Outlook 2007, Outlook 2010 and Outlook 2013

      0
      0

      For about as many years as you’ve used Outlook, you’ve likely used the guidance in the older Outlook meeting requests: Essential do’s and don’ts article. However, if you read the older document, you almost certainly noticed that the document only generally applies to newer Outlook versions. Over the last few years, many enhancements were made to the Outlook Calendar. This made much of the guidance in the older document unnecessary.

      The newBest practices when using the Outlook Calendar document was created exclusively for Outlook 2007, Outlook 2010 and Outlook 2013 clients. It supplements (not replaces) the Essential do’s and don’ts document. The older document still applies to Outlook 2003 and earlier versions.

      Read the entire article carefully. You will notice there are many changes, including clearly marked sections directed at Exchange mailbox users.

      This newly published best practices document is the culmination of many months of work by numerous individuals and was developed with the help of the support and product teams.

      Abdias Ruiz

      Servicing Exchange 2013

      0
      0

      Six years ago Exchange took a bold step forward in product servicing. With Exchange Server 2007 we shifted to a cumulative model to deliver customer rollup updates (RU’s) instead of a traditional hotfix model. A primary benefit to customers was a simplified delivery mechanism where many updates could be delivered in a single package. Tracking and installing multiple individual packages was no longer required. Delivering a smaller update package more frequently also allowed customers to introduce changes in a controlled fashion more quickly. This servicing model has served many customers well but not all. A challenge for some customers has been that the rollup update model has not delivered security fixes separately, requiring customers to install additional fixes when applying a security fix.

      At the same time, the way customers use Exchange has encountered an equally dramatic shift. Many customers have moved their messaging environments entirely to the cloud and an increasing number are deploying hybrid environments with mailboxes split between on-premises and the cloud, functioning as a single Exchange Organization.

      Considering all of these points, the Exchange team is announcing a new servicing approach for the Exchange Server 2013 product. The new model attempts to take the best of what we’ve been delivering, address challenges where possible and recognize the shift in how customers deploy Exchange.

      Today we are announcing that routine product updates to Exchange Server 2013 will be distributed via quarterly Cumulative Updates (CU’s). Each quarterly CU package will be released as a full refresh of the Exchange product and will be installed as a build to build upgrade. Build to build upgrade is already familiar to Exchange customers as this is the mechanism used to deploy Service Packs in previous Exchange versions. The version of Exchange shipped to on-premises customers in each CU will be the same version we use to host Exchange Online on Office 365. Security updates will be delivered via independent packages that can be applied to a previously released Cumulative Update package or installed during the upgrade to the current Cumulative Update package.

      The primary benefits to customers with this approach include:

      • Predictable release cadence – CU’s will be delivered on a pre-determined schedule four times a year allowing customers to plan their deployments more deliberately. Lync and SharePoint also release CU’s at a regular cadence.
      • Dedicated security releases – Independent security releases will allow customers to quickly install an update with confidence knowing that only the fixes which address a particular problem will be included. In the event there are multiple security releases required for a particular CU, all fixes will be delivered in a single package simplifying the deployment of multiple security fixes.
      • Datacenter scale validation – On-Premises and Hybrid customers will be able to deploy CU’s knowing that the same code is already deployed in the Exchange Online service and has been validated against millions of mailboxes in the world’s largest and most demanding Exchange installation.
      • Improved support for hybrid deployments– System requirements will be better aligned because the on-Premises server and datacenter servers will be running identical code.
      • More rapid changes to language resources – In the RU model, language modifications to releases were limited to Service Pack releases. With the CU model, updates to language resources will be available in each release.

      Of course moving to the CU model changes some things that users of Rollup Updates have become accustomed to:

      • Larger update packages – Every update will be a full release of the product and as such will be a larger package than with previous update mechanisms.
      • Loss of server customization during upgrade – Similar to Service Pack installation, the CU model will not preserve web.config, registry changes or other custom configuration applied to servers. This does not represent a change in guidance from previous Exchange versions.
      • Installation failure recovery – In the unlikely event installing a CU fails and is unrecoverable, re-installation of the server will be necessary. No loss of mailbox or queue data should occur even in the unlikely event of an installation failure.

      The added benefit of a CU being validated in O365 prior to release to the general public does not replace the need for customer’s to complete due diligence in their own environments. This is especially true when 3rd party or custom developed applications have been integrated into a messaging system. The Exchange team continues to provide guidance that all customers test upgrades in a representative lab environment prior to deploying into their production environment.

      The Exchange team is excited to deliver what we believe is an enhanced model of servicing to our Exchange Server 2013 customers. The Exchange team is targeting a release date of 2013 Q1 for the first CU package. Below you will find answers to what we believe are some of the most commonly asked questions regarding the introduction of CU’s.

      Q: Will CU’s contain product fixes only or will new features be included as well?

      A: CU’s will be used to deliver fixes for on-premises and online customer reported issues as well as items identified by the Exchange team. Feature changes due to customer requested design changes may also be included which could add or modify existing functionality.

      Q: Will there continue to be Service Pack releases?

      A: Similar to previous releases, it is anticipated that periodic Service Pack updates may be provided.

      Q: Will AD schema changes be included in CU’s?

      A: AD schema updates may be included in a CU if required to support a change in functionality. AD Schema updates for Exchange are additive and always backwards compatible with previous releases and versions.

      Q: Will there be multiple security updates released for a given CU?

      A: The security updates released will be CU specific and will contain all of the fixes available at the time of release for a given CU in a single cumulative package. In the event that multiple releases have been made available for a given CU, only the most recent version of the security update package will be required to be installed and it will contain all previous fixes as well.

      Q: If I am installing the most recent CU available, will I need to apply security updates to that release.

      A: Not necessarily. When we release a CU it will contain all security updates currently available. Only if a security update is made available after the release of the CU, will it be necessary to apply an additional security update on top of a CU. Security updates will clearly indicate which CU they are intended to be used with.

      Q: Will the server version be updated during the install of a CU?

      A: Yes, this also addresses some customer feedback.

      Q: How long is a CU supported?

      A: A CU will be supported for a period of three (3) months after the release date of the next CU. For example, if CU1 is released on 3/1 and CU2 is released on 6/1, CU1 support will end on 9/1.

      Q: How do I recover from a failed installation of a CU?

      A: Exchange Server 2013 includes high availability options to prevent the loss of data or functionality due to the upgrade of a single server. Furthermore, Exchange Setup is engineered to be executed, repeatedly if necessary, until a server installation or upgrade is completed. The actual steps used to recover from a failed CU upgrade will vary based upon the point at which the failure occurs and customer configuration. Existing mechanisms used to recover from a failed service pack installation will be applicable and may include use of SETUP /m:RecoverServer or installing a new server object and reseeding or reattaching existing DB’s.

      Q: How will CU’s be made available?

      A: CU’s will be published on the Microsoft Download Center. Security updates for a CU will be made available on Microsoft Update and the Microsoft Download Center.

      Q: In a Database Availability Group configuration do all servers need to be at the same CU revision?

      A: Customers should plan their deployments such that all servers in a Database Availability Group are running the same CU revision for the version of the product they are using. During a CU upgrade, it is supported for individual servers in the Database Availability Group to be deployed with different CU versions. This is expected to be a temporary condition until all servers have been upgraded.

      Q: Do all servers in a Client Access Array need to be at the same CU revision?

      A: Similar to Database Availability Groups, co-existence of multiple CU revisions in a single array is supported during the upgrade process.

      Brent Alinger

      Released: Exchange Server 2010 SP3

      0
      0

      Earlier last year, we announced that Exchange 2010 Service Pack 3 would be coming in the first half of 2013. Later, we updated the timeframe to Q1 2013. Today, we're pleased to announce the availability of Exchange Server 2010 Service Pack 3, which is ready to download.

      Service Pack 3 is a fully slipstreamed version of Exchange 2010. The following new features and capabilities are included within SP3:

      • Coexistence with Exchange 2013:Customers who want to introduce Exchange Server 2013 into their existing Exchange 2010 infrastructure will need the coexistence changes shipping in SP3.

        NOTE: Exchange 2010 SP3 allows Exchange 2010 servers to coexist with Exchange 2013 CU1, which is also scheduled to be released in Q1 2013. Customers can test and validate this update in a representative lab environment prior to rolling out in their production environments as an important coexistence preparatory step before introducing Exchange Server 2013 CU1.

      • Support for Windows Server 2012: With SP3, you can install and deploy Exchange Server 2010 on computers that are running Windows Server 2012.
      • Support for Internet Explorer 10: With SP3, you can use IE10 to connect to Exchange 2010.
      • Customer Requested Fixes: All fixes contained within update rollups released before SP3 will also be contained within SP3. Details of our regular Exchange 2010 release rhythm can be found in Exchange 2010 Servicing.

      In addition to the customer reported issues resolved in previous rollups, this service pack also resolves the issues that are described in the following Microsoft Knowledge Base (KB) articles:

      Note: Some of the following KB articles may not be available at the time of publishing this post.

      2552121 You cannot synchronize a mailbox by using an Exchange ActiveSync device in an Exchange Server 2010 environment

      2729444 Mailboxes are quarantined after you install the Exchange Server 2010 SP2 version of the Exchange Server 2010 Management Pack

      2778100 Long delay in receiving email messages by using Outlook in an Exchange Server 2010 environment

      2779351 SCOM alert when the Test-PowerShellConnectivity cmdlet is executed in an Exchange Server 2010 organization

      2784569 Slow performance when you search a GAL by using an EAS device in an Exchange Server 2010 environment

      2796950 Microsoft.Exchange.Monitoring.exe process consumes excessive CPU resources when a SCOM server monitors Exchange Server 2010 Client Access servers

      2800133 W3wp.exe process consumes excessive CPU and memory resources on an Exchange Client Access server after you apply Update Rollup 5 version 2 for Exchange Server 2010 SP2

      2800346 Outlook freezes and high network load occurs when you apply retention policies to a mailbox in a mixed Exchange Server 2010 SP2 environment

      2810617 Can't install Exchange Server 2010 SP3 when you define a Windows PowerShell script execution policy in Group Policy

      2787500 Declined meeting request is added back to your calendar after a delegate opens the request by using Outlook 2010

      2797529 Email message delivery is delayed on a Blackberry mobile device after you install Update Rollup 4 for Exchange Server 2010 SP2

      2800080 ErrorServerBusy response code when you synchronize an EWS-based application to a mailbox in an Exchange Server 2010 environment

      Exchange 2010 SP3 FAQ

      Here are answers to some frequently asked questions.

      • Q. Does Exchange 2010 SP3 include the fixes in Exchange 2010 SP2 RU6?
        A. Yes. Service Packs are cumulative - they include all fixes included in previous RUs and service packs. Although Exchange 2010 SP2 RU6 was released on the same day as Exchange 2010 SP3, fixes in RU6 are included in SP3.

      • Q. Does Exchange 2010 SP3 include the security fix mentioned in Microsoft Security Bulletin MS13-012?
        Yes, fix for the vulneraiblity in MS13-012 is included in Exchange 2010 SP2 RU6, and (as stated above) fixes from SP2 RU6 are inclued in SP3. We recommend reviewing the related security bulletin before applying an update that contains security fixes.

      • Q. Why release RU6 for SP2 at all if all fixes are included in SP3?
        Exchange 2010 SP2 is a supported service pack (see Exchange Server Support Lifecycle). Customers typically deploy update rollups quickly but take longer to deploy service packs.

      • Q. Is Exchange 2010 SP3 compatible with WMF 3.0/PowerShell 3.0?
        A. No. Exchange 2010 SP3 does not support WMF 3.0/PowerShell 3.0. Although on Windows Server 2012 you can have WMF3/PS3, Exchange 2010 SP3 will require and use PowerShell 2.0.

      • Q. Does Exchange 2010 SP3 require an Active Directory schema update?
        A. Yes, as mentioned in Exchange 2010 SP3 Release Notes, an Active Directory schema is required.

      • Q. Can I install Exchange 2013 RTM in my Exchange 2010 organization after upgrading to Exchange 2010 SP3?
        A. As mentioned in the post, coexistence of Exchange 2013 in an Exchange 2010 SP3 org requires Exchange 2013 CU1, also scheduled for release in this quarter (Q1 2013).

      • Q. It's great that Exchange 2010 SP3 is supported on Windows Server 2012! Can I upgrade the OS my Exchange Server's running on from Windows Server 2008/2008 R2 to Windows Server 2012 after installing SP3?
        A. No. Upgrading the operating system after Exchange Server installation is not supported. You would have to uninstall Exchange, upgrade the OS, then reinstall Exchange. Or install Exchange 2010 SP3 on a fresh Windows 2012 install.

      • Q. Is MRM 1.0 supported on Exchange 2010 SP3?
        A. Yes, MRM 1.0 (Managed Folders) is a supported feature in Exchange 2010. We replaced MRM 1.0 management support in EMC with MRM 2.0 (Retention tags) in Exchange 2010 SP1. You can still use the Shell to manage MRM 1.0.

      • Q. Will I be able to restore and mount database backups created before a server is upgraded to SP3?
        A. Yes. When you restore and mount the database, it will be updated.

      • Q. Is Exchange 2010 SP3 supported with <My great third-party Exchange add-on/tool>?
        A. Please contact the partner / third-party software vendor for this info. We recommend testing in a representative non-production environment before you deploy in production.

      Exchange Team


      Released: Update Rollup 6 for Exchange Server 2010 SP2 and Exchange 2007 SP3 RU10

      0
      0

      Today the Exchange CXP team released the following update rollups to the Download Center. All three releases cover Security Bulletin MS13-012 (KB 2809279). Because this is a security release, the updates will also be available on Microsoft Update.

      Update Rollup 6 for Exchange Server 2010 Service Pack 2

      Update Rollup 10 for Exchange Server 2007 Service Pack 3

      Update Rollup 6 for Exchange Server 2010 SP2:

      This update contains a number of customer reported and internally found issues. In particular we would like to specifically call out the following fixes which are included in this release:

      Note: Some of the following KB articles may not be available at the time of publishing this post.

      2489941 The "legacyExchangeDN" value is shown in the "From" field instead of the "Simple Display Name" in an email message in an Exchange Server 2010 environment

      2779387 Duplicated email messages are displayed in the Sent Items folder in a EWS-based application that accesses an Exchange Server 2010 Mailbox server

      2751581 OAB generation fails with event IDs 9126, 9330, and either 9338 or 9339 in an Exchange Server 2010 environment

      2784081 Store.exe process crashes if you add certain registry keys to an Exchange Server 2010 Mailbox server

      Update Rollup 10 for Exchange Server 2007 SP3:

      This update contains a number of customer reported and internally found issues. In particular we would like to specifically call out the following fixes which are included in this release:

      2783779 A hidden user is still displayed in the Organization information of Address Book in OWA in an Exchange Server 2007 environment

      Note: Exchange 2007 SP3 RU10 allows Exchange 2007 servers to coexist with Exchange 2013 CU1, which is also scheduled to be released in Q1 2013. Customers can test and validate this update in a representative lab environment prior to rolling out in their production environments as an important coexistence preparatory step before introducing Exchange Server 2013 CU1.

      For DST Changes: http://www.microsoft.com/time

      Exchange Team

      Address Book Policies, Jamba Jokes and Secret Agents

      0
      0

      Since we added the Address Book Policy feature in Exchange Server 2010 Service Pack 2, one of the questions I frequently hear (related to ABP’s that is) is, “when are you adding ABP’s to Office 365?”

      Well dear reader, the quick answer is, as we deploy our next round of feature upgrades to Office 365, and more specifically to Exchange Online!

      There are few things to be aware of however, which is the reason for this post, but before we lose anyone who is not on Office 365, let me say that it’s not only a good thing for our Office 365 customers, it’s also good for those of you with Exchange on-Premises who are using ABP’s as we’re adding a new feature to better control what users experience when sending and receiving mail. More on that later on.

      So ABP’s and Office 365. The first thing to know is this feature is an Exchange Online only feature. Just so that’s clear.

      The second thing to know is that the ABP features are only available to customers with Office 365 for Enterprise (‘E’ plans) and Education (‘A’ plans). We are not making ABPs available to small business (P Plan).

      The third thing that happens when we add support for this feature to Office 365 is that it allows you to create custom additional Address Lists (ALs), Global Address Lists (GALs), Offline Address Books (OABs), as well as ABPs within your tenant. So even if you don’t use ABPs, you can add additional custom Address Lists to your tenant if you so choose.

      For example, you could create an Address List containing all the users with mailboxes in Chicago, and have Outlook and Outlook Web App (OWA) show that additional Address List. You don’t need ABPs, just the smarts to create a new Address List (we still recommend using custom attributes for filtering as they are consistent on all the mail enabled objects).

      The fourth thing, and wow, these things just keep coming don’t they, is that we are creating a limit to the number of ABPs and OABs you can create by default. Why? Well, these things all consume resources and when you are a tenant on a multi-tenant shared platform you have to ensure one tenant doesn’t consume all the available resources. One way of doing that is by restricting the number of objects or actions one tenant can take.

      The default for Office 365 for Enterprise customers is to allow 10 GALs, 10 OABs, 10 ABPs and 40 ALs.

      So that’s ABPs in Exchange Online. I’ll add that it’s all command line configuration; there’s no Exchange Administration Center UI for it, and there’s no AutoMagic directory/config sync between on-premises and the cloud. Though it’s pretty simple to re-use the commands you used for creating ALs, GALs etc. in on-premises, and just to re-run those same commands in the cloud to get the same results.

      Transport and ABPs

      Ok, now that really is all I have to say about ABPs in Exchange Online. Except for yet one more thing, and this is the bit that will also interest some on-premises customers, particularly those selling or providing a multi-tenant like offering to their company or customers.

      We have built a transport agent into Exchange that respects ABPs. Now I don’t mean respect as in “whoa, Mr. ABP dude, you rock and I bow down to your greatness”, no, I do not, as that would be ridiculous and anyone who even came up with a pathetic attempt at humour like that should be kicked swiftly in the OABs. I mean respect. R. E. S. P. E. C. T., find out what email can do for me.

      Let us break from song by understanding the issue.

      Well, take the case where you and I share different ABPs, we cannot see each other in the GAL, and yet we decide to Exchange email. Perhaps we didn’t know we were even on the same email system. We went for a beer one day, or perhaps a juice if you don’t drink beer (as an aside, one day when my daughter, 5 years old at the time, was upset as her brother was getting taken for a Jamba juice but she wasn’t. I told her they made Jamba juice by squeezing a small creature called a Jamba really hard to get the juice out, and that it takes a lot of fluffy cutesy little Jamba bunnies to make a 32oz super Aloha Pineapple Smoothie – suffice to say, no longer do we have an envy problem when her brother gets taken for a juice…why tell you this story? Well, it’s Valentine’s Day today and who doesn’t love a story about squeezing bunnies or suchlike on such an occasion?) and we decided to chat over email. You emailed me. When it arrived, in Outlook I saw a fully resolved Exchange object with your name next to it. Heck, I could even see your phone number. And job title. And office. I can’t see DL memberships or any of that, ABPs do take care of that, but I can see more than I should. Here’s an example of a mail sent from someone outside Chris Contoso’s ABP, but on the same Exchange system.

      g1
      Figure 1: The chief bottle officer

      Why is that? Because to Exchange we’re both just users in the same organization, and so as the mail was internal (at least to Exchange) it promotes/resolves the sender and recipient to fully resolved Exchange objects – i.e. it matches you to your GAL entry. Now OWA does the same, or rather, Exchange does the same, and OWA displays you as a fully resolved Exchange object, but the ABP code in 2010 prevented you, as an OWA user, from seeing more details than you should. Outlook didn’t work quite the same as you just saw.

      Why is all this an issue? Well, it’s potentially a data loss issue, if the two users discover more information from the GAL than they should.

      Now the way we suggested people solve this in 2010 was to write a transport agent, to send mail out and back in when certain conditions are detected – which makes the message appear to originate from the Internet, which means not internal, which in turns means, respect. Getting your due respect in this case meant developing or buying an agent, and, and this is the kicker, there were cases even an agent couldn’t solve – if you cc someone else internal to the Org on the mail for example. The bottom line was, the way the messages were processed inside Exchange, an agent developed externally, with a limited ability to interact with the message, could not get at it early enough. We needed to do this. We needed to teach Exchange respect.

      So what we have done is create an agent, which when enabled, and I’m explaining this at a very high level, examines each message submitted by a user, and looks up the ABPs of any recipients it finds, and buckets or groups the message by ABP, and then performs recipient resolution on them using the GAL specified within the ABP, not the entire directory, before it delivers the message.

      g2
      Figure 2: Address Book Policies at work

       

      The diagram above tries to convey the same concept in an easy to understand manner, recipients get to see different copies of the same message, with recipients resolved according to their ABP. This example is based upon the ABP guidance (Joint CEO Example), documented here. From that guidance you’ll also know that GALs can be a subset or a superset of each other depending upon how the filters are defined. The new agent doesn’t worry about that though, it simply groups by ABP, and then resolves each copy based upon the GAL associated with that ABP, so each copy is always correctly resolved.

      This is good all round I’m sure you’ll agree. Particularly in the cloud for the large number of educational customers we have – if students start emailing each other (as kids do, when not IM’ing, texting, facepoking, checking four squares or whatever it is these days) then they don’t get resolved to directory objects, even when inside the same tenant, as long as their GALs are scoped correctly. There are a few ways to plan for EDU Office 365 for Education customers with large numbers of schools/GALs but that’s a post for somewhere else.

      Enabling this stuff

      So the natural way to wrap this up is to explain how you can get the respect you want, you deserve and you need.

      So to enable this new found respect in Office 365 you do one thing:

      Set-TransportConfig –AddressBookPolicyRoutingEnabled $True

      It takes up to 30 minutes to kick in as we cache that setting for performance reasons.

      For our on-premises customers we will ship the agent in Cumulative Update 1 for Exchange Server 2013. You need to install and enable it.

      1. Firstly you install it using this easy to remember PowerShell one-liner (this example is copy and paste fodder (note the word breaks) assuming you have Exchange installed at c:\rossisagod);

        Install-TransportAgent -Name "ABP Routing Agent" -TransportAgentFactory "Microsoft.Exchange.Transport.Agent.AddressBook
        PolicyRoutingAgent.AddressBookPolicyRoutingAgentFactory" -AssemblyPath "C:\rossisagod\Exchange Server\V15\TransportRoles\agents\AddressBookPolicyRoutingAgent\
        Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.dll"

      2. Enable the ABP routing agent:

        Enable-TransportAgent "ABP Routing Agent"

      3. Restart the Transport Service.
      4. Run the following cmdlet to enable ABP routing:

        Set-TransportConfig –AddressBookPolicyRoutingEnabled $True

      5. You are finished. Off to the races we go.

      So there we go, another odd ball blog post to explain a tiny corner of the product that only some of you care about. But if you do care, and you read this far, thank you, and remember, the Jamba has feelings too, so squeeze it fast so it doesn’t suffer too much.

      Greg Taylor
      Principal Program Manager Lead
      Exchange Customer Experience

      Don’t miss the Virtual Launch Event for the New Office 365 for Business

      0
      0

      Join us at our Virtual Launch Event on February 27th as we celebrate the availability of a major new release coming to Office 365 for businesses.  If you are exploring cloud offerings, you do not want to miss this event.  You’ll hear from Kurt DelBene, President of the Microsoft Office Division, about Microsoft’s vision for productivity, enterprise social and the cloud.  We’ll demo new features in enterprise social and show how we’ve transformed the full Office experience you know into an always up-to-date service.  Finally, you’ll hear real world stories from our customers about their move to the cloud.  We’ll also answer questions via live chat as we go.

      I hope you’ll join me there.  Register now!

      Kirk Gregersen
      General Manager, Microsoft

      Exchange, Firewalls, and Support… Oh, my!

      0
      0

      Over the years Exchange Server architecture has gone through a number of changes. As a product matures over time you may see us change what is supported as we react to changes in the product architecture, the state of technology as a whole, or major support issues we see come in through our support infrastructure.

      Over the years a large volume of support calls have ended up being caused by communication issues between Exchange servers or between Exchange servers and domain controllers. Often times this results from a network device between the servers not allowing some port or protocol to communicate to the other servers.

      I tried to get Harrison Ford to co-write this article with me given his specific talents, but alas he was busy and regretfully couldn’t partake. Please allow me to start with the short version up front so there is no confusion about what we currently DO and DO NOT support before I lose some of you to;

      b1
      Image Courtesy of: http://knowyourmeme.com/memes/tldr

      Starting with Exchange Server 2007 and current as of Exchange Server 2013, having network devices blocking ports/protocols between Exchange servers within a single organization or between Exchange servers and domain controllers in an organization is not supported. A network device may sit in the communication path between the servers, but a rule allowing “ANY/ANY” port and protocol communication must be in place allowing free communication between Exchange servers as well as between Exchange servers and domain controllers.

      For Exchange Server 2010 this is already articulated at http://technet.microsoft.com/en-us/library/bb331973(v=EXCHG.141).aspx under Client Access Server Connectivity in the Client Access Server section in the following paragraph.

      “In addition to having a Client Access server in every Active Directory site that contains a Mailbox server, it’s important to avoid restricting traffic between Exchange servers. Make sure that all defined ports that are used by Exchange are open in both directions between all source and destination servers. The installation of a firewall between Exchange servers or between an Exchange 2010 Mailbox or Client Access server and Active Directory isn’t supported. However, you can install a network device if traffic isn’t restricted and all available ports are open between the various Exchange servers and Active Directory.”

      Why has this seemingly simple support statement become so muddied and confusing over the years? Maybe we didn’t make it blunt enough to start with, but there could be some other compounding points adding to the confusion.

      Confusion point #1…

      Exchange Server 2003 was the last version of Exchange Server to allow deploying (at the time) a Front-End server in a perimeter network (aka DMZ) while locating the Back-End server in the intranet. While this could be made to work it required a specialized set of rules that essentially turned your perimeter network security model into the following:

      b2
      Image Courtesy of: The Internet

      During the time of Exchange Server 2003 adoption of reverse proxies within perimeter networks was on the rise. Reverse proxies allowed customers to more securely publish Exchange Server for remote access while only allowing a single port and protocol to traverse from the Internet to the perimeter network, and then a single port and protocol to traverse from the perimeter network to the intranet.

      You could go from something complicated like this with endless port and protocol requirements….

      b3
      Figure 1: Legacy Exchange 2003 deployment with Front-End server in a perimeter network. What a mess. Who’s hungry?

      To something simple like this…

      b4
      Figure 2: Reverse proxy in the perimeter network and all Exchange servers within the intranet. Simplicity at its best!

      The resulting increase in simplicity as well as the drop in support cases was strong enough for Microsoft to determine during the lifecycle of the next major version of Exchange Server, 2007, that we would no longer support deploying what is now the Client Access Server role in a perimeter network. From that time on all Exchange servers, except for Edge Transport Server role, were to be deployed on the intranet with unfettered access to each other. We do have this documented in http://technet.microsoft.com/en-us/library/bb232184.aspx.

      Confusion point #2…

      TechNet includes a number of articles that document many if not all of the ports and protocols Exchange Server utilizes during the course of normal operation. These documents are often misunderstood as “configure your firewall this way” articles. The information is only being provided for educational purposes on the inner-workings of Exchange Server, or to aid with the configuration of load balancing or service monitoring mechanisms which often require specific port/protocol definitions to perform their functions correctly. In case you come across them in the future, here is a list of most of those articles.

      Exchange Network Port References

      Understanding Protocols, Ports, and Services in Unified Messaging

      I don’t trust my clients and I like restricting their access. Is that supported?

      This is a different story and yes there are things you can do here to remain supported. Exchange Server has for a number of revisions supported configuring static client communication ports for Windows based Outlook clients. After the client contacts the endpoint mapper service running on Windows under TCP Port 135 it will be handed back the static TCP port you have chosen to use in your environment. For Exchange Server 2010 you may be familiar with the following article describing how to configure static client communication ports for the Address Book Service and the RPC Client Access Service, thereby leaving you with 4 ports required for clients to operate in MAPI/RPC mode.

      • TCP 135 for the Endpoint Mapper
      • TCP 443 for Autodiscover/EWS/ECP
      • TCP <your choice #1> for the Address Book service
      • TCP <your choice #2> for the RPC Client Access service
      • UDP ANY from CAS to the Outlook 2003 client if you’re in online mode and utilizing UDP notifications.

      http://social.technet.microsoft.com/wiki/contents/articles/864.configure-static-rpc-ports-on-an-exchange-2010-client-access-server.aspx

      TechNet also has resources for versions prior to Exchange Server 2010: http://support.microsoft.com/kb/270836.

      Starting in Exchange Server 2013 the only protocol supported for Windows Outlook clients is RPC over HTTPS. This architectural change reduces your required port count to one, TCP 443 for HTTPS, to be utilized by Autodiscover, Exchange Web Services, and RPC over HTTPS (aka Outlook Anywhere). This is going to make your life easy, but don’t tell your boss as they’ll expect you to start doing other things as well. It’ll be our secret. Promise. I’ll go through some examples of supported deployments, but will keep it easy and only use Outlook clients. The same ideas apply to other POP/IMAP/EAS clients as well, just don’t restrict Exchange servers from talking to each other. A setup like the following Outlook 2010 / Exchange 2010 diagram would be entirely supported where we have a firewall between the clients and the servers. In all of the following examples I have chosen static TCP port 59531 for my RPC Client Access Service on CAS and Mailbox, and static TCP port 59532 for my Address Book Service on CAS. UDP notifications are also thrown in for fun for those of you running Outlook 2003 in Online Mode, which I hope is very few and far between these days. Domain controllers were left out of these diagrams to focus on communication directly between clients and Exchange, and load balancers were also kept out for simplicity.

      b5
      Figure 3: Firewall between clients and all Exchange servers. Supported if firewall is configured correctly to allow all necessary client access. AD not shown.

      However, if you attempted to do something naughty like the following diagram and for reasons unknown to us put a firewall between CAS and Mailbox then there had better be ANY/ANY rules in place allowing conversations to originate from either side between Exchange servers.

      b6
      Figure 4: Firewall between CAS and other Exchange servers. Supported only if the firewall is configured for unfettered access between Exchange servers, and Exchange servers and AD. AD not shown.

      Well what if you have multiple datacenters with Exchange and want to firewall everything everywhere because you believe that as the number of firewalls goes up your security must exponentially increase? We’ve got you covered there too, deploy it like this where you’ll see both MAPI/RPC and RPC/HTTPS user examples. I didn’t bother putting load balancers or Domain Controllers into any of these diagrams by the way. I’m putting faith in all of you that you know where those go.

      b7
      Figure 5: Firewalls between users and Exchange servers as well as between datacenters. Supported if the firewalls are configured to allow unfettered access between Exchange servers, between Exchange servers and AD, and appropriate client rules. AD not shown.

      Boy this is going to be easy when all of you migrate to Exchange Server 2013 and are only dealing with RPC/HTTPS connections from clients and SMTP or HTTPS between servers. Except for maybe those pesky POP/IMAP/UM clients…

      Figure 6 below depicts what Exchange 2013 network conversations may look like at a high level. A load balancer and additional CAS were introduced to show we don’t care what CAS a client’s traffic goes through as they all end up at the same Mailbox Server anyways where the user’s database is mounted. You may have read previously Exchange Server 2013 does not require affinity for client traffic and hopefully this visual helps show why.

      The one tricky bit to consider if placing a firewall in between clients and Exchange Server 2013 would be UM traffic as it is not all client to CAS in nature. In Exchange Server 2013 a telephony device first makes a SIP connection through CAS (orange arrows) which after speaking with the UM Service on Mailbox Server will redirect the client so it may establish a direct SIP+RTP session (blue arrow) to the Mailbox Server holding the user’s active database copy for the RTP connection.

      Blog - Exchange and Firewalls
      Figure 6: Showing at a high level SMTP, Windows Outlook Client, and UM traffic with a firewall between users and Exchange Server 2013.

      So, Microsoft, if you’re saying this should be simple then what can I do and remain in a supported state?

      The key here is to not block traffic between Exchange servers, or between Exchange servers and Domain Controllers. As long no traffic blocking is performed between these servers you will be in a fully supported deployment and will not have to waste time with our support staff proving you really do have all necessary communications open before you can start to troubleshoot an issue. We know many customers will continue to test the boundaries of supportability regardless, but be aware this may drag out your troubleshooting experience and possibly extend an active outage. We prefer to help our customers resolve any and all issues as fast as possible. Staying within support guidelines does in fact help us help you as expeditiously as possible, and in the end will save you time, support costs, labor costs, and last but not least aggravation.

      Brian Day
      Program Manager
      Exchange Customer Experience

      Update: Exchange Server TechNet Library URLs

      0
      0

      Many of you have seen our previous blog post announcing the Exchange documentation URL changes, and have provided us with your feedback on the matter. Starting off, we want to thank you for all of it; we learned quite a bit from it, and we think it’s fantastic that we have such passionate and vocal community.

      First, a little bit of history. How did we get here?

      As an enterprise product with a long lifecycle, product documentation for multiple Exchange versions is published on TechNet. If you look at Exchange documentation library, you will find content for Exchange Server 2013, Exchange Server 2010, Exchange Server 2007 and Exchange Server 2003.

      Exchange Server TechNet Library navigation

      As part of our content publishing process, we have historically used version-less URLs (URLs with no version info) that point to the most recent version of a topic. This has been our practice for both our IT Pro and Developer documentation for multiple releases of Exchange. Interestingly, we didn’t get any negative feedback, or really any feedback at all the previous time we made this switch, when we moved from Exchange 2007 to Exchange 2010.

      One could speculate as to why the previous switch wasn’t painful, but this one was, but the main point is — this last switch was.

      Where do we go from here?

      Taking all of the feedback we received into consideration, and based upon upcoming documentation publishing milestones, we have decided on the following course of action to prevent this sort of pain from happening with future product releases (the changes are not live yet, but will be starting tomorrow):

      - Bad news first: we will not be switching the documentation URLs back to where they were pre-November 2012. While this was a painful decision, we do not want to increase the pain more by doing another switch after 3 months.

      - Looking forward, we will make it so that all of our documentation exposes the version information in the URL. So, for Exchange 2010, that would mean that you will see (EXCHG.141) as part of the URL, and for Exchange 2013 you’ll see (EXCHG.150). These are the URLs that will be used in the navigation elements on TechNet and in links in the content. Version-less URLs will still point to the latest version of the specific article. However, as version-specific URLs will be available (and visible when you browse our documentation) for everything, we expect that the use of version-less URLs will decrease over time. In other words, any Library topics you link to (by copying from your browser's address bar) will have the version identifier.

      We are hoping that this course of action will provide the right balance of what a set of our customers want and our ability to still optimize discoverability of content across multiple product versions.

      Exchange Documentation Team

      Viewing all 607 articles
      Browse latest View live




      Latest Images