Monday, 3 December 2012

After migrating distribution list from exchange 2003 to exchange 2010, Owner of the DL can't have permission to manage the DL

After migrating distribution list from exchange 2003 to exchange 2010, Owner of the DL can't have permission to manage the DL

First of all we should make sure that all the DL should be convert to Universal and upgraded to Exchange Server 2010 and then follow the below steps to resolve the issues.

One question I got in response to my article “Group owners cannot manage distribution groups once migrated from Exchange 2003 to 2010” was the steps required to tweak the default role assignment policy so that the owners can modify the groups, but users cannot create or delete distribution groups.
Let me explain the steps required, which have to be done in the Shell. The permissions to create/modify/delete distribution groups are in the default role named “MyDistributionGroups”. Hence, all we need to do is to take away the role entries which gives users right to create and delete a distribution group (New & Remove-DistributionGroup cmdlets). But, we don’t want to mess with the default roles and hence we will create a new role which is a child of “MyDistributionGroups”. I will name it OwnersCanModifyDistributionGroups.
Run the command below in the Shell to create the role.
New-ManagementRole -Name OwnersCanModifyDistributionGroups -Parent MyDistributionGroups
Create a new management role
Now we need to remove the new & remove-distributiongroup cmdlets from the management role. Run the following in the Shell.
Remove-ManagementRoleEntry OwnersCanModifyDistributionGroupsNew-DistributionGroup
Remove right to create a DG
Remove-ManagementRoleEntry OwnersCanmodifyDistributionGroupsRemove-DistributionGroup
Remove right to delete DG
Now that the custom role is ready, we need to add it to the default role assignment policy. This assumes that you don’t have “MyDistributionGroups” role in the policy. If you have, you need to delete it. Easiest is to use the ECP & remove the check box (follow my article mentioned in the beginning) if you are not comfortable with Shell. Run the command below to add the role to the default policy.
New-ManagementRoleAssignment -Role OwnersCanModifyDistributionGroups -Policy "Default Role Assignment Policy"
Add the new role to default policy
That’s it. Users can now modify the distribution groups they own, but can’t create or remove distribution groups
 

Converting and upgrading distribution groups

Converting and upgrading distribution groups

When migrating to Exchange 2010 from Exchange 2003, you may be carrying over several mail-enabled non-universal groups. These groups will still function, but the administration of these objects within the Exchange tools will be limited. In addition, several distribution group features provided by Exchange 2010 will not be enabled for a group until it has been upgraded. This recipe covers the process of converting and upgrading these groups within the Exchange Management Shell.

How to do it...

  1. To convert all of your non-universal distribution groups to universal, use the following one-liner:
    Get-DistributionGroup -ResultSize Unlimited ` -RecipientTypeDetails MailNonUniversalGroup | Set-Group -Universal
  2. Once all of your distribution groups have been converted to universal, you can upgrade them using the following command:
    Get-DistributionGroup -ResultSize Unlimited | Set-DistributionGroup -ForceUpgrade

 

Daily Exchange Health Checklist

Daily Exchange Health Checklist

 
Here a few daily tasks that I perform each morning after a cup of coffee to ensure that my Exchange environment is running smoothly. This has proven very helpful in preventing many issues with my Exchange servers. I came up with the list while managing Exchange 2000/2003 environments but it still helps me with Exchange 2007 as well. Hope it will help others out there.
  • Check event viewer for warnings/errors on all Exchange Servers
  • Check for database fragmentation
  • Check postmaster mailbox for NDRs
  • Check exchange statistics
  • Check bad mail folder for trends
  • Check OS status on Exchange boxes
  • Check if plenty of disk space is available on all BE & FE servers
  • Check for cluster failover in cluster admin
  • Check message load in the queue viewer
  • Check OS/Exchange Services
  • Check results of real-time performance monitoring for all servers
  • Review event, performance vs. anti-virus logs
  • Track message for security project
  • Verify integrity of Exchange Store
  • Wednesday, 7 November 2012

    Installing, Configuring Exchange 2007 Edge Server (Part 2)

    Installing, Configuring Exchange 2007 Edge Server (Part 2)

     
    In Installing, Configuring Exchange 2007 Edge Server (Part 1) we started the installation of an Exchange 2007 Edge server at the DMZ.
    So far we installed the Exchange Edge role on a standalone Windows 2003 server. The server is still not connected to the rest of the Exchange organization running internally. Indeed we could employ Edge as the perimeter server even if we were not running Exchange internally. As is, Edge only requires port 25 communications and the configuration of send/receive connectors, to act as a relay to any SMTP server.
    However, quite obviously, Edge also includes special support for running together with an internal Exchange 2007 organization. This functionality is provided by the EdgeSync service. Running on an internal Hub transport server, EdgeSync pushes information to the Edge server. The following is some of the information transferred; more details are available from the article EdgeSync Replication Data:
    • Email routing configuration such as the list of accepted domains and connector configuration.
    • Recipient information that is especially useful for rejecting emails addressed to invalid recipients.
    • Safe Sender lists configured at each of the recipient mailboxes.
    Making this information available to the Edge server enables the immediate filtering of emails. Furthermore, once the system is deployed, an Administrator will be able to manage the Edge server from the internal network. Configuration changes are simply pushed by EdgeSync, reducing the need to log on to the Edge server directly.
    All this is achieved without compromising the need for isolation. EdgeSync only requires the opening of an additional port at the firewall separating the internal and perimeter networks. This is port 50636, a custom secure LDAP port to which ADAM is listening.
    Another point to notice is the fact that information only flows from the internal to the perimeter network and not the other way round. Again this meets our isolation requirements. If the information at the perimeter were to be poisoned, this information would not get propagated internally.

    DNS Configuration

    Before proceeding further we have to take care of name resolution. Both Edge and internal Hub servers need to be able to resolve each other's name through DNS. For this to work we will add host (A) records for each of the Edge/Hub transport servers.
    In a typical DMZ configuration the perimeter and internal networks run on different subnets. In our case we have these settings:
    Perimeter subnet: 192.168.0.0/255
    Edge Server Name: abcd.exchinbox.local
    Edge Server IP: 192.168.0.5

    Internal subnet: 192.168.10.0/255
    Hub Server Name: exchsrv.exchinbox.local
    Hub Server IP: 192.168.10.60

    We start from the internal DNS server. This is the one used by the Hub transport. Thus we add an A record for the Edge server named 'abcd'. We add this under the Forward Lookup Zone for exchinbox.local.
    Internal DNS Server

    Host Record Settings

    We now test name resolution and port 25 connectivity. This telnet command will verify both:
    telnet abcd 25
    Telnet test

    Note: If running Windows 2008, install the telnet client from Server Manager | Add Features, select the check box for the Telnet Client and complete the wizard.
    Now we move to the perimeter network and create an A record for the Hub named 'exchsrv'. If the perimeter were running its own DNS server, we would create the A record there, as we did for the internal network. Otherwise we just edit the hosts file located under:
    <Windows dir.>\system32\drivers\etc
    Here we add the line:
    192.168.10.60 exchsrv
    Hosts File

    We now perform the same telnet test to verify name resolution and connectivity from edge to hub:
    telnet exchsrv 25

    Creating an Edge Subscription

    It is now time to setup EdgeSync. This process starts from the edge server machine. At the Exchange Management Shell we run:
    New-EdgeSubscription -file c:\temp\EdgeSubscription.xml
    The file parameter identifies the path where an Edge Subscription XML file is to be created.
    New-EdgeSubscription

    On running the command we are greeted with a very informative warning that is worth reading:
    "Creating an Edge Subscription makes the configuration of this Edge Transport server ready to be managed via EdgeSync. Any of the following types of objects that were created manually will be deleted: accepted domains; message classifications; remote domains; and Send connectors. Also, the InternalSMTPServers list of the TransportConfig object will be overwritten during the synchronization process. The Exchange Management Shell tasks that manage those types of objects will be locked out on this Edge Transport server. You must manage those objects from inside the organization and allow EdgeSync to update the Edge Transport server. EdgeSync requires that this Edge Transport server is able to resolve the fully qualified domain names (FQDN) of the Hub Transport servers in the Active Directory site to which the Edge Transport server is being subscribed. Those Hub Transport servers must be able to resolve the FQDN of this Edge Transport server. You should complete the Edge Subscription inside the organization in the next "1440" minutes before the bootstrap account expires."
    Hitting 'Y' will complete this step and the Edge Subscription file is created. Here is what it looks like:
    XML Subscription File

    We now transfer this file to the Hub Transport server. Here at the Exchange Management Console under Organization | Hub Transport we select New Edge Subscription and follow the wizard that opens.
    Importing Edge Subscription

    Edge Subscription Wizard

    In the introductory step note the checkbox saying:
    'Automatically create a Send connector for this Edge Subscription'
    This will create the connectors necessary for emails to flow between Edge and Hub transports.
    Edge Subscription Warning

    The final wizard step reminds us to open port 50636 for the EdgeSync service to be able to push information to ADAM.
    "EdgeSync requires that the Hub Transport servers in Active Directory site Default-First-Site-Name must be able to resolve the IP address for abcd.exchinbox.local, and be able to connect to that host on ports 50636."
    Completing the subscription, we can immediately have a look at the new configuration elements that were created. Under Organization | Hub Transport | Edge Subscriptions we find the registration of the 'abcd' server.
    Subscription Configuration Object

    Under Organization | Hub Transport |Send Connectors we have two new send connectors:
    New Send Connectors

    EdgeSync in Action

    In my test environment EdgeSync kicked off immediately and completed the first synchronization. However I did come across reports claiming that the Microsoft Exchange EdgeSync service needed a restart. Don't forget EdgeSync runs at the internal Hub Transport and this is where you will find the service.
    Synchronization Service

    Thereafter synchronization will follow a fixed schedule:
    Every 1 hour - Configuration information
    Every 4 hours - Recipient information
    Every 5 minutes - Topology information
    We can easily verify whether the first synchronization pushed the expected information to the Edge server. From the Edge server management console, we check the list of accepted domains that were configured internally.
    Accepted Domains

    While we are at the Edge server, we can verify if configuration changes were locked as promised earlier on creating the Edge Subscription. Here I tried to edit one of the send connectors and was promptly blocked:
    Locked Configuration

    "This task may not be run on an Edge Transport server that is subscribed to an Active Directory site. You must perform this operation on a Hub Transport server in the subscribed Active Directory site. The changes will be replicated to the Edge Transport server when synchronization next occurs."
    Now let's see what happens when the configuration changes at the Hub Transport. Here at the "EdgeSync - Inbound to Default-First-Site-Name" Send Connector, I configured exchsrv.exchinbox.local as the smart host to be used by the Edge server for inbound emails.
    Smart Host Configuration

    This change won't be visible to the Edge server until the next synchronization cycle unless we force it to. From the Exchange Management Shell we first run:
    Test-EdgeSynchronization
    Test-EdgeSynchronization

    This returns a report showing that everything is synchronized except for the SendConnectorStatus.
    Next we run:
    Start-EdgeSynchronization
    Start-EdgeSynchronization

    This will force an immediate synchronization pushing the new Send Connector settings to the Edge. Of course the same cmdlets also come very handy when troubleshooting.

    Final Tips

    With the Edge Server role, Exchange 2007 provides a good DMZ citizen that is able to satisfy the isolation restrictions imposed by the perimeter network. This is achieved whilst retaining a good level of integration.
    EdgeSync provides the necessary link that allows us to manage the Edge server from the internal network. However it is important to understand the work that is going on behind the scene. If new recipient mailboxes are created or a new accepted domain is added, the Edge server won't know of these until synchronization kicks in. If this is an issue, we should force synchronization from the command shell with Start-EdgeSynchronization.
    Of course apart for port 25 don't forget to open port 50636 for EdgeSync to work. EdgeSync traffic only flows from the Hub to the Edge transport. Thus we only need port 50636 open at the firewall separating the internal network from the perimeter (in that direction).
    One of the areas where I see problems most often is name resolution. The Edge server needs to resolve the names of all hosts it will be interacting with, including those of the internal Hub transport. Same goes for the internal network. Here the Edge server name must also be resolvable through DNS.

    Installing, Configuring Exchange 2007 Edge Server (Part 1)

    Installing, Configuring Exchange 2007 Edge Server (Part 1)


    Despite the success in conquering internal corporate networks, earlier Exchange versions failed to replicate the same success at the DMZ. One reason for this was the Exchange server installation requirements that included IIS and Active Directory. These are often considered too cumbersome for hosts running internet facing services.
    Splitting functionality into distinct roles, allowed Exchange 2007 to provide the first DMZ friendly solution. The Edge server role was thus born, an SMTP transport where email hygiene applications filter emails before allowing entry and exit to/from the internal network.
    Today we walk through the installation of an Exchange Edge server. We also configure this to connect to the Exchange servers running internally.

    Network Layout

    We start our walk with a look at the network layout. A typical DMZ is shown below. Internet originating email is received by the Edge server. If accepted this is relayed to the internal Exchange Hub transport. In case of outgoing email, the Hub transport uses the Edge server as a smart host.
    DMZ

    The separation between DMZ and internal network limits the type of traffic between the two segments. In this setup, the Edge server machine cannot be a member of the internal domain. Furthermore the Edge is expected to only provide essential services so as to limit exposure to potential security attacks. These limitations are catered for by the Edge server installation requirements. In fact we will be installing Edge on a standalone Windows 2003 Server. Of course it is also possible to install this on Windows 2008. I will be highlighting some differences between to two platforms as we go along.
    For the purposes of this article, the internal network is already up and running. The internal domain name is exchinbox.local. An Exchange Hub transport server is also in place accepting emails for the domain adminstop.com.

    Edge Installation Requirements

    We start the Edge installation from a standalone Windows 2003 SP2 server. To satisfy the basic Exchange 2007 requirements we install the .NET Framework 2.0, MMC and PowerShell. With these bits out of the way, we look at some requirements specific to the Edge role.
    First we have to configure the DNS Suffix for the Edge machine:
    1. Open the properties for 'My Computer'
      My Computer Properties

    2. Select the Computer Name page and click Change
      Computer Name Property Page

    3. Click More
      Computer Name Properties

    4. Enter the DNS name of the internal domain. In our case exchinbox.local
      DNS Suffix

    5. Finally we restart the machine
    Next we have to make up for the lack of Active Directory services. Cutting the Edge server from the internal Active Directory is desirable from an isolation perspective. However AD also serves as the Exchange 2007 configuration repository. Thus a replacement that allows Edge to store its configuration is obviously required.
    Thus on Windows 2003 we install the Active Directory Application Mode ADAM service. Just like Active Directory this is an LDAP directory service. However this will only be used to store information relevant to Exchange.
    We download ADAM SP1 from the Microsoft download center. The Service Pack includes all the bits and can be installed directly on a machine where ADAM was never installed.
    There is nothing worthy of note regarding the installation of ADAM. It is just a matter of clicking Next, 'I Agree' and Finish.
    Note: ADAM is included with Windows 2003 R2. In this case use the Optional Component Manager to complete this installation.
    Note: If we were installing Edge on Windows 2008 instead of ADAM we would install Active Directory Lightweight Directory Services (AD LDS).

    Installing the Edge Server Role

    We now satisfied the installation requirements. Using the Microsoft Update Service we make sure we also have all the latest updates. Finally we are ready to install the Edge Server role.
    The usual Exchange 2007 installation Wizard greets us. Here we choose the Custom Exchange Server Installation option since Edge is not part of the typical installation.
    Custom Exchange 2007 Installation

    At the Role selection step we select the Exchange Server Role.
    Edge Server Role

    Note how on selecting the Edge role all other roles are grayed. Edge has to be installed on its own. All other roles are intended to run within the internal network. We should now be able to complete the installation as usual.

    Looking at ADAM

    As already discussed, in this setup ADAM is acting as the configuration repository for the Edge server. ADAM is really a sibling of Active Directory. Thus tools that we usually use against Active Directory are also available for ADAM. Let's use ADSI Edit to take a look at what ADAM is storing.
    1. Start MMC: Run | mmc.exe
      MMC

    2. Open, File | Add/Remove Snap-in | Add | ADAM ADSI Edit
      ADSI Edit

    3. Add the Snap-In and click OK to close the Add/Remove Snap-in dialog
    4. Now right-click the ADAM ADSI Edit node and select 'Connect To...'
      Connect to ADAM

    5. At the Connections Settings Dialog change the port to 50389. This is the default port ADAM listens to.
      ADAM Port 50389

    6. Hit OK to connect and we are ready to browse the directory. Here is the all too familiar Exchange Administrative Group object...
      Administrative Routing Group

    Final Tips

    Today we started the deployment of an Exchange 2007 Edge server. We looked briefly at the general characteristics of the DMZ, the network segment to home our installation.
    Next we looked at the installation requirements. These contribute greatly in making the Exchange 2007 Edge server role DMZ friendly. The requirements include ADAM. This fills up the void left by the lack of the Active Directory service, providing storage for the Edge server configuration. Once all requirements were satisfied, installing Edge was just a matter of selecting the custom installation type and the Edge server role.
    In the next part of this article we will proceed with the configuration and connection of the Edge server to the Exchange servers running internally.

    Installing, Configuring Exchange 2007 Edge Server (Part 2)

    Upgrading from Exchange 2003 to 2010

    Upgrading from Exchange 2003 to 2010


    Microsoft Exchange Server 2010 brings a new set of great technologies. No surprise many are excited and looking forward to plan and deploy this new messaging infrastructure. Today we cover the basic steps that should be performed in organizations currently running Exchange 2003.

    Prerequisites

    Prerequisites that must be met before we start the deployment:
    • Windows Server 2003 SP2 or later, Global Catalog servers in each site where Exchange Servers are located and Windows Server 2003 forest functional level.
    • Exchange 2003 Organization must be in native mode, with Exchange 2003 SP2 installed
    • In place upgrade is not supported, thus new hardware should be installed for the Exchange 2010 Servers. Hardware requirements may be found at the following link:
      http://technet.microsoft.com/en-us/library/aa996719.aspx
    • Operating Systems supported are Windows Server 2008 SP2 64-bit and Windows Server 2008 R2 64-bit Standard or Enterprise. Please note that Exchange Server 2010 is 64-bit only, i.e. there is no 32-bit version available for testing purposes and there are no 32-bit management tools. Management tools should be installed on a 64-bit operating system too.
    • If the organization has multiple sites, the first site to introduce Exchange 2010 should be the internet facing site. The upgrade then continues with non-internet facing sites.
    • If the solution design requires installing Exchange 2010 roles on multiple servers, then these should be installed in the following order:
      1. Client Access Server role
      2. Hub Transport Server role
      3. Unified Messaging Server role (optional, may be deployed later)
      4. Mailbox Server role
      5. Edge Server role (optional, may be deployed later)

    The Installation Process

    The installation process requires Active Directory to be prepared. In order to do that, the user should be member of the Schema Admins and Enterprise Admins security groups.
    When transitioning from Exchange 2003 to 2010, we transition the Exchange specific permissions using the command that follows.
    setup /PrepareLegacyExchangePermissions or setup /pl
    The Active Directory schema must be extended with Exchange 2010 specific attributes thus we run:
    setup /PrepareSchema or setup /ps
    The next command to run is:
    setup /PrepareAD or setup /p
    This performs multiple tasks. It verifies that the schema has been updated, assigns specific permissions in the configuration partition, creates the Microsoft Exchange Security Groups organizational unit (OU) in the root domain of the forest, and prepares the local domain for Exchange 2010.
    The last command of the preparation steps is:
    setup /PrepareDomain or setup /pd
    This also performs multiple tasks. It creates a new domain global group named Exchange Install Domain Servers in the current domain. Next it adds this group to the Microsoft Exchange System Objects container and to the Exchange Servers group at the root domain.
    Note: For detailed Active Directory preparation steps please check:
    Prepare Active Directory and Domains
    The Exchange 2010 installation steps were discussed in Installing Exchange 2010 Beta. Thus we proceed with the so called coexistence scenario i.e. the moment when there are both Exchange 2003 and 2010 versions present in our organization.
    In order to provide message transport coexistence between both versions, the setup will perform the following actions:
    • Ask for the Exchange 2003 bridgehead server to be identified
    • Create an Exchange Routing Group RG (DWBGZMFD01QNBJR) to host Exchange 2010.
    • Create routing group connectors between the Exchange 2003 bridgehead RG and the Exchange 2010 RG.
    • Create an Exchange Administrative Group AG (FYDIBOHF23SPDLT) to host Exchange 2010.
    Since Exchange 2007, administrative groups and routing groups are no longer used. The same also applies to Exchange 2010. Thus the RG and AG are only created to allow coexistence with Exchange 2003. Furthermore the groups are only visible from the Exchange 2003 System Manager console. It is not allowed to make any configuration or membership changes to both of these. Again, same as in Exchange 2007, Exchange 2010 uses Active Directory sites instead of Routing Groups to define the routing topology.
    Exchange 2003 System Manager

    Client Access Server Role Coexistence

    So far we completed the Exchange 2010 setup. We now configure the server roles.
    During the coexistence phase, we should change some DNS settings to provide a seamless transition. Let's assume our current Exchange 2003 server is accessed by name mail.company.com. After installing Exchange 2010, a legacy name should be assigned to identify the Exchange 2003 infrastructure, for example we use legacyname.company.com. This is done both at the internal and external DNS namespaces. In addition, the current DNS host name (mail.company.com) is assigned to the new Exchange 2010 server. Thus clients won't use the legacy name, they still continue to access their mailboxes without changing settings.
    A new certificate should be issued because of Exchange 2003 and Exchange 2010 coexistence. Wildcard certificates and certificates that support Subject Alternative Names may be used.
    We will assume that the primary external namespace for virtual directories is configured during the setup (for example mail.company.com). Clients will use this name to connect from the Internet.
    Coexistence between Exchange 2003 and Exchange 2010 Client Access will be provided by configuring the URL property on the /owa virtual directory. This is done from the Exchange Management Shell using:
    Set-OWAVirtualDirectory "MAIL2010\OWA (Default Web Site)" -Exchange2003URL https://legacyname.company.com/exchange
    If our company uses Outlook Anywhere, it should be enabled from the Exchange Management Shell using:
    Enable-OutlookAnywhere -Server:MAIL2010 -ExternalHostName:mail.company.com -SSLOffloading $false
    In addition, forms-based authentication on the Exchange 2003 front-end server should be configured in order to have single sign-on between both versions.
    The Offline Address Book generation service should also be moved to the Exchange 2010 CAS Role. From the Exchange Management Shell use the command that follows:
    Move-OfflineAddressBook "Default Offline Address List" -Server MAIL2010
    To enable Exchange 2010 and 2003 to communicate using Kerberos authentication, the configuration partition in Active Directory should be changed, so that the attribute msExchAuthenticationFlags of the Microsoft-Server-ActiveSync object is set to value 6.
    At this point in time, all clients are connecting to the new Exchange 2010 Client Access Server using the name mail.company.com. The mailboxes are still on Exchange 2003, so the Outlook Web Access experience is actually version 2003. They will connect to the new version of Outlook Web Access once their mailboxes are moved to Exchange 2010.

    Hub Transport Server Coexistence

    NOTE: If planning to employ the Exchange 2010 Edge Transport please skip this section. The following articles discuss deploying the Edge Transport server role. These were written for Exchange 2007 however they are still largely valid for Exchange 2010 as well:
    Installing, Configuring Exchange 2007 Edge Server (Part 1)
    Installing, Configuring Exchange 2007 Edge Server (Part 2)
    Deploy an Edge Transport Server in an Existing Exchange Server 2003 Organization
    Exchange 2010 provides two server roles for handling email transport, the Edge and Hub transport roles. In simple terms we can consider the Hub Transport to be the replacement for the Exchange 2003 transport functionality. Thus here we consider the transition from the Exchange 2003 transport to the Exchange 2010 Hub transport.
    After installing Exchange 2010, the mail from/to the internet still flows through the Exchange 2003 bridgehead. In order to reroute the mail transport to go through the new Exchange 2010 Server, the inbound and outbound traffic should be reconfigured, depending on the company messaging infrastructure.
    To allow inbound traffic from the internet, the SMTP gateway or firewall should point to the new Exchange 2010 Hub Transport server. In addition the Receive Connector at the Hub Transport should be configured to allow the "Anonymous users" permission group. In this manner the Hub Transport accepts incoming emails from external SMTP servers.
    Anonymous User Permissions

    To allow outbound traffic to the Internet, a Send Connector with * namespace should be configured to route outgoing messages directly or using smart host. This can be done from the Exchange Management Console or the Exchange Management Shell using the following command:
    new-SendConnector -Name 'Internet Connector' -Usage 'Internet' -AddressSpaces 'SMTP:*;1' -IsScopedConnector $false -DNSRoutingEnabled $true -UseExternalDNSServersEnabled $false -SourceTransportServers 'MAIL2010'

    Mailbox Server Role Coexistence

    At the Exchange 2010 Management Console, mailboxes located on Exchange 2003 Servers are classified as "Legacy Mailbox".
    Legacy Mailboxes

    The process of moving mailboxes to Exchange 2010 is called Local Move Request (local is for moving within the same forest). When moving from Exchange 2003, the user is disconnected during the move process. Unfortunately online mailbox moves as discussed in Exchange 2010 Online Mailbox Move, a Deep Dive, are only possible if the source mailbox is located on Exchange 2007/2010.
    Mailbox move requests can be performed using both Exchange Management Console and Exchange Management Shell. For example:
    New-MoveRequest -Identity 'user@company.com' -TargetDatabase EX2010DB01
    Once the mailboxes are moved, we should proceed with moving public folders. To discover public folder replicas, at the shell run the following:
    Get-PublicFolder -recurse | FL Name,Replicas
    The next step is to open the Exchange 2003 System Manager and to locate the Public Folder store database. Here right-click the database and choose Move All Replicas. When prompted to choose for a destination public folder database, select the one located on Exchange 2010.
    The process can be monitored using the same Exchange Management Shell command:
    Get-PublicFolder -recurse | FL Name,Replicas
    The Exchange 2003 Recipient Update Service should also be reconfigured to use Exchange 2010 Servers. This is done from the Exchange System Manager.
    At the end, mailboxes and public folder databases on Exchange 2003 servers should be deleted using the Exchange System Manager. This process does not delete the database files from the file system, so file deletion should be done manually.
    When all resources are moved to the Exchange 2010 Servers, the routing group connectors between the Exchange 2003 and 2010 routing groups should be deleted using the Exchange 2003 System Manager.
    Remove Routing Group Connector

    Finally Exchange 2003 can be removed from Control Panel | Add Remove Programs on Windows 2003.
    Uninstall Exchange 2003

    Conclusion

    Upgrading an Exchange Organization from version 2003 to 2010 is a process that requires analyzing the current messaging infrastructure and designing the new one.
    The two versions can coexist. If properly planned, keeping in mind legacy applications running on Exchange 2003, we can avoid service interruption.
    At the end, introducing Exchange 2010 should allow us to lower costs and at the same time improve productivity.

    Thursday, 18 October 2012

    Load Balancing Exchange 2010 Client Access Servers using an Hardware Load Balancer Solution (Part 3)

    Introduction

    In part 2 of this multi-part article, I showed you how to create and configure the virtual services required for the Exchange 2010 protocols/services as well as how you went about and changed the external and internal URLs for each respectively.
    In this part 3, I will show you how to enable SSL offloading so that SSL sessions are terminated on the HLB solution instead of on the Exchange 2010 CAS servers in the CAS array.

    Why enable SSL Offloading?

    There are several benefits of enabling SSL offloading when using a hardware load balancer (HLB). When you enable SSL offloading you terminate the incoming SSL connections on the HLB instead of on the CAS servers. By doing so you move the SSL workload (encryption and decryption tasks) which are CPU intensive from the CAS servers to the HLB device(s). With CAS servers getting more and more responsibility with the introduction of new features such as MailTips, Move Request Service (MRS) and because it now also is the endpoint for MAPI clients, it makes even more sense to let the HLB take care of the SSL workload compared to earlier versions of Exchange Server.
    Another important reason is the fact that you only can take advantage of layer 7 (L7) processing such as cookie-based persistence. If you don’t offload SSL to the HLB solution, you can only use source IP address based persistence, which isn’t ideal. Especially not if you have clients that appear to come from the same IP address.
    Most HLB devices support software SSL. When software SSL is used, the HLB device uses the general processor (CPU) to perform SSL encryption and decryption tasks. Since the general CPU also handles things such as load balancing, health checks and other administrative tasks, if you have thousands of users in your messaging environment, it’s recommended to use a HLB that has a separate CPU with the sole purpose of processing SSL workload.

    Enabling SSL Acceleration on the Hardware Load Balancer

    In this article, I will show you how to configure a Load Master 2000 HA pair from KEMP Technologies for SSL acceleration, but in general the steps should be similar on devices provided by other vendors.
    To enable SSL acceleration for the HTTPS virtual service, that we created earlier on in this article series, log on to the LoadMaster web interface and expand “Virtual Services” followed by clicking “View/Modify Services”. Now find the HTTPS virtual service and click “Modify”.

    Figure 1: Accessing the property page of the HTTPS Virtual Service
    On the property page of the HTTPS virtual service, check “SSL Acceleration

    Figure 2: Enabling SSL Acceleration
    You will now be presented with the dialog box shown in Figure 3.

    Figure 3: Temporary certificate will be used
    When clicking ”OK”, the property page will be extended with additional SSL options.

    Figure 4: Enabling SSL Acceleration extends the property page with new SSL options
    As you noted a self-signed certificate was automatically installed when you enabled SSL acceleration. Since we want to use the 3rd party SAN/UC certificate currently used on the CAS servers in our CAS array, click “Add New”. Then either paste in the entire body of the certificate or point to the cert file by clicking “Browse”.

    Figure 5: Installing the UC/SAN certificate
    Click ”Submit” and ”OK” and the certificate is installed for the HTTPS virtual service.


    Figure 6: UC/SAN certificate installed
    Now make sure that the port for each real server (CAS server) is set to port 80.

    Figure 7: Make sure port 80 is specified as target server port
    We can now see the common name for the cert (mail.exchangelabs.dk) on the virtual service list and we’re done on the HLB side of things. In the next section, we will go over the steps necessary to configure SSL offloading on the CAS servers in our CAS array.

    Figure 8: Certificate properly installed on the HTTPS Virtual Service

    Enabling SSL Offloading for the Exchange 2010 CAS Services

    In this section, I will explain how to configure each service/protocol so that it supports offloading SSL for each service/protocol to a hardware load balancer.

    Configuring Outlook Web App

    To configure SSL offloading for Outlook Web App (OWA), you must perform two steps on each CAS server in CAS array. First, we must add a SSL offload REG_DWORD key. To do so, open the registry editor and navigate down to:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA
    Under this registry key, create a new REG_DWORD key named “SSLOffloaded” and set the value for this key to “1” as shown in Figure 9.

    Figure 9: Creating the SSL Offload key for OWA
    We now need to disable the SSL requirement on the OWA virtual directory. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site, select the “OWA” virtual directory. Under features view, double-click on “SSL Settings”.

    Figure 10: Accessing SSL settings for the OWA virtual directory
    Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

    Figure 11: Disabling SSL requirement for the OWA virtual directory
    Finally, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

    Configuring Exchange Control Panel

    Unlike OWA, configuring SSL offloading for the Exchange Control Panel (ECP) doesn’t require a registry key to be set. Well, to be more specific ECP will use the same registry key as the one we set for OWA.
    So in order to enable SSL offloading for ECP, the only thing we need to do is to disable the SSL requirement on the ECP virtual directory. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site, select the “ecp” virtual directory. Under features view, double-click on “SSL Settings”.

    Figure 12: Accessing SSL settings for the ECP virtual directory
    Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

    Figure 13: Disabling SSL requirement for the ECP virtual directory
    Finally, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

    Configuring Outlook Anywhere

    To enable SSL offloading for Outlook Anywhere only requires one step which, depending on whether Outlook Anywhere already is enabled or not, can be done via the Exchange Management Console (EMC) or the Exchange Management Shell (EMS).
    If you haven’t yet enabled Outlook Anywhere, you can use SSL offloading when running the “Enable Outlook Anywhere” wizard. You can access this wizard by right-clicking on the respective CAS server in EMC and select “Enable Outlook Anywhere” in the context menu.

    Figure 14: Enabling Outlook Anywhere using the EMC
    This brings up the wizard where you enter the external host name to be used and check “Allow secure channel (SSL) offloading”.

    Figure 15: Allowing SSL offloading for Outlook Anywhere
    If you already enabled Outlook Anywhere in your environment, you need to use the Set-OutlookAnywhere cmdlet to enable SSL offloading. If this is the case, open the Exchange Management Shell and type the following command:
    Set-OutlookAnywhere –Identity CAS_server\RPC* -SSLOffloading $true

    Figure 16: Enabling SSL offloading using the EMS
    Running the above command will disable the requirement for SSL for the RPC virtual directory in IIS, which means we don’t need to do so manually like it’s the case with the other services/protocols.

    Configuring Exchange ActiveSync

    Some of you may recall having read on Microsoft TechNet and various other places that SSL offloading isn’t supported by Exchange ActiveSync. This used to be true but is now fully supported (although the Exchange documentation on Microsoft TechNet hasn’t been updated to reflect this yet).
    Bear in mind however that SSL offloading is only supported by Exchange ActiveSync at the Internet ingress point. It’s still not supported in CAS-CAS proxy scenarios between Active Directory sites.
    Configuring Exchange ActiveSync to support SSL offload is extremely simple. We just need to remove the requirement for SSL in IIS. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “Microsoft-Server-ActiveSync” virtual directory. Under features view, double-click on “SSL Settings”.

    Figure 17: Accessing SSL settings for the Microsoft-Server-ActiveSync virtual directory
    Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

    Figure 18: Disabling SSL requirement for the Microsoft-Server-ActiveSync virtual directory
    Finally, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

    Configure Exchange Web Services

    In order to configure Exchange Web services to support SSL offloading, we must perform two modifications. The first one is to remove the SSL requirement for the EWS virtual directory in IIS. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “EWS” virtual directory. Under features view, double-click on “SSL Settings”.

    Figure 19: Accessing SSL settings for the EWS virtual directory
    Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

    Figure 20: Disabling SSL requirement for the EWS virtual directory
    Next step is to make a change to the configuration file (web.config) for the EWS virtual directory. This file can be found under C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews and be modified using a text editor such as Notepad.

    Figure 21: Locating the EWS web config file
    In the web.config file, you should replace all occurrences of “httpsTransport” with “httpTransport” and then save the file.

    Figure 22: Replacing httpsTransport with httpTransport
    Note:
    With Exchange 2010 SP1 you will no longer need to perform the latter change (see KB article 980048 for details).
    Finally, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

    Configuring Autodiscover Service

    In order to configure the Autodiscover service to support SSL offloading, you must perform the same steps as those applied to the Exchange Web service virtual directory.
    So let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “Autodiscover” virtual directory. Under features view, double-click on “SSL Settings”.

    Figure 23: Accessing SSL settings for the Autodiscover virtual directory
    Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

    Figure 24: Disabling SSL requirement for the Autodiscover virtual directory
    Next step is, without surprise, to make a change to the configuration file (web.config) for the Autodiscover service virtual directory. This file can be found under C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover and be modified using a text editor such as Notepad.

    Figure 25: Locating the Autodiscover web config file
    In the web.config file, you should replace all occurrences of “httpsTransport” with “httpTransport” and then save the file.

    Figure 26: Replacing httpsTransport with httpTransport
    Lastly, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

    Validating Access works as expected

    advertisement

    After having offloaded SSL to the HLB, we of course need to validate that access from the miscellaneous Exchange clients/applications works as expected. A good first step is to use the Exchange remote Connectivity Analyzer for this purpose.

    Figure 27: Using the Exchange remote Connectivity Analyzer to test access
    In order to verify you installed the required root and intermediate certs as well as the UC/SAN cert properly, you can use SSL Installation Diagnistics tools such as the one provided by DigiCert.

    Figure 28: Testing the SSL chain using the DigiCert SSL Diagnostics tool
    If you get all green checkmarks using these tools, chances are things are in good shape. But you should of course also test access using the real Exchange clients.
    And with that this multi-part article ends. Yes I also said that when we reached the end of part two, but this time I mean it :)
    If you would like to read the other parts in this article series please go to