One of the things that I get a lot of questions about when I start leading people down the CLI path is whether or not the Exchange Management Shell is just PowerShell with a fancier icon. We frequently open the EMS in order to perform certain managerial tasks in Exchange, and we hear more and more coming out of Redmond regarding PowerShell. So let’s discuss it.

As it turns out, the Exchange Management Shell is PowerShell (big surprise there) but it’s a more specialized environment than you get when simply running PowerShell.exe, with a lot of specific settings to make it talk to Exchange. In this post, we’ll go over the differences, and when you want to use one or the other.

The Exchange Management Shell (EMS) uses PowerShell as its base, but it expands upon PowerShell in a number of ways. Many of these you could do yourself, either manually by entering specific commands, or by automating those tasks in your profile. When you launch the EMS, you connect to a remote session on an Exchange server using Windows Remote Management 2.0 (WinRM). Even if you are running the EMS on the only Exchange server in your environment, you connect to that WRM. The only exception to this is the Edge Transport server. Because it is a standalone role, when you launch the Exchange Management Shell, you connect to the local server only, much like you did in Exchange 2007.

When you connect, authentication checks create a session for you with access to the cmdlets and parameters you have permission to run based on your assigned management roles. The cmdlets are contained within three snap-ins:

1. Microsoft.Exchange.Management.PowerShell.E2010
2. Microsoft.Exchange.Management.PowerShell.Setup
3. Microsoft.Exchange.Management.Powershell.Support

You could load those into a PowerShell session using the Add-PsSnapin command but there are still differences between the two environments. Launching PowerShell and adding the snapins would give you access to the cmdlets, but first, you would still need to connect your session to the WinRM instance running on the Exchange server. You would also be running all of the available commands as cmdlets. When you launch the EMS, you run these as functions.

When it comes to writing scripts, the good news is that because EMS is built on top of PowerShell, there’s no real difference when it comes to scripting and using the EMS. Some of the system variables do not work fully in the EMS though, so if you are going to write a script that uses a system variable, you are better off adding the snap-ins to PowerShell.

While most Exchange admins tend to use the remote desktop client to connect to an Exchange Server, when they want to run EMS commands that is not necessary. If you are running a 64 bit desktop, you can install the Exchange Management Tools on your workstation from the Exchange installer. Users with the –RemotePowerShellEnabled attribute set to true, and assigned to at least one Exchange management role, will be able to run the EMS on their workstation and manage Exchange.

In future posts, we’ll start to dig deeper into the EMS and explore just how powerful and useful this administrative interface is.

Exchange Management Shell vs PowerShell

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue.

While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 4 of this series, we’re going to look at the humble physical layer (DoD, not OSI) and discuss troubleshooting NICs.

NICs

We’re now down where the rubber meets the road, that is, where the packets meet the wire. Your Network Interface Cards can be the most important part of the entire network connectivity between client process and server process, and are also the most commonly overlooked aspect of the entire communications channel. I’ve seen many a case where Exchange network performance issues came down to problems with the NIC, but days had gone by troubleshooting the problem, or weeks just accepting the poor performance, before anyone thought to look at the NICs. If the NICs aren’t happy, ain’t nobody happy so let’s make sure those NICs smile.

The differences between the various physical connections are beyond the scope of this article, but the recommendations and troubleshooting suggestions in this article should apply equally to all types of NIC, whether copper or fibre based, and whether physical or virtual. Let’s start with some best practices for connecting up all your servers and clients:

Use quality NICs

There are times to save money, and there are times to spend the extra for the best, and as far as Exchange servers are concerned, you cannot go wrong spending a little extra on the higher quality NICs. Single port or multi-port, specific name brand not as important, but don’t buy the cheap one off NICs or limit yourself to what is built-in to your server.

Use good cables

I take pride in my ability to “roll my own” cables (Ethernet, not fibre-optic) and I also know that name-brand cables can cost a fortune, but here again is where you don’t want to take any chances. All of your drop cables should be commercially made, but at the same time, don’t assume that because they are, they are faultless. Make it a habit to test all cables early in the troubleshooting process if not at time of install.

Use quality, managed switches

Inexpensive unmanaged switches are good for home use, or to provide last minute patches in a meeting room without wireless, but have no place in a datacenter. Make sure all your servers directly connect to managed switches that can provide you details and statistics about the physical connection.

With that out of the way, now we’ll move on to some more best practices that should also be the second steps you take on the server when troubleshooting connectivity issues, right after reseating all the cables.

Hardware Drivers

Make absolutely certain you are running the latest hardware drivers. Check the vendor site, and read the documentation for any known issues that might correlate to your problem, but unless there is something contraindicated in that documentation, make sure you have the latest supported drivers. If you do though, consider downgrading one rev just in case you have encountered a new bug.

Firmware

Don’t just stop at the software drivers for your NICs, make sure you have the latest firmware installed as well.

TCPIP.SYS

Check the Microsoft operating system drivers for your specific platform, and if you are not running the latest TCPIP driver, upgrade immediately. I have personally seen dozens of problems magically disappear just by catching up on patches. Of course, I do recommend staying current on all patches, but this is one that should have no exceptions.

Teaming

More connectivity problems have been “solved” by “breaking the team” than any other single fix in history. If you have having network connectivity problems and are using network teaming, break the team and see if the problem goes away. Do this early on, as it is a quick thing to check, and to put back if that is not the problem. Odds are that it is, and in that case, you need to troubleshoot network teaming, not Exchange networking. The solution will usually be with updating drivers, fixing a problem with your configuration, or something on the switch.

Receive Side Scaling and ToE

If your multi-processor Exchange server is slamming one CPU(or core) and the rest are sitting idle, it’s a good bet you don’t have RSS enabled. RSS lets your server balance NIC interrupts across all the CPUs, which leads to better overall performance. It’s on by default in 2008 and 2008R2, but might have been turned off by another admin. If you see high CPU on only one processor, check with this command.

netsh interface tcp show global

If Receive-side Scalaing state shows as disabled, you’ve found the culprit.

That same command will also show you the status of TCP Chimney Offload, or ToE. With compatible NICs, ToE can provide much better throughput on large file transfers (like database replication for DAGs, mailbox moves, etc.) and reduced CPU utilization. With it off, those operations will take much longer, have lower throughput, and cause higher CPU utilization. 2008 disables ToE by default, while 2008 R2 uses an automatic setting. If your NICs support ToE, make sure you are using it by enabling it (if necessary) in the O/S, and then setting the advanced properties of the NIC to use it.

Using Hardware Load Balancers

The biggest challenge to troubleshooting load balanced servers is that the problem usually will manifest itself as intermittent, or isolated to a single client or subnet. If load balancers are in the mix, test from your machine, but test against the VIP and against each physical server one by one. If you cannot reproduce the problem, try the same process from the client. This may be one time where you have to use a HOSTS file to trick the client into connecting to each server one by one. If you don’t have admin access to the hardware load balancer, get on with that admin to do your tests so they can view realtime logs to see if anything stands out.

The Microsoft Network Load Balancing Service

If you are trying to load balance Exchange servers and are running into problems using software load balancing, my money is on the problem being in your switch configuration, and not with the MS NLB service. The easy test is to move the VIP to one of the servers, validate that everything works, and then move the VIP to the other and validate again. If it works without NLB in the mix, then it is not Exchange you should be looking at. MS NLB works great, though it is limited to IP based affinity and not port based, but there are so many ways the switch and/or router that your server connects to can screw up NLB, I’ll frequently recommend against using it unless I can directly manage the switches myself, or I know the person who does and that he or she understands their side of making NLB work.

See  http://technet.microsoft.com/en-us/library/ff625247.aspx for some more tips on MS NBL, and if you are using VMware to virtualize your servers, see this article for specific settings in VMware. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007371

Coming up next

In Part 5, we will look at the issues that can cause Exchange problems when making RPC calls, and how to troubleshoot those problems. Here’s a rundown of the six parts in this series. We’ll update with live links as each part is published over the next several weeks.

1. Introduction and DNS
2. Active Directory
3. Firewalls
4. NICs (this post)
5. RPCs
6. Client side issues

Troubleshooting Exchange Networking: NICs (Part 4)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Back in early December, I wrote an article called A Deeper Look into Exchange 2010 SP2 where I discussed some of the new changes being added to Exchange and to the Active Directory schema. If you didn’t read that article, click the link above, and then come back here. It’s okay, I’ll wait. Back and ready to go? Good. In that article I indicated that the new extension attributes could be available for customers who want to store additional information in Active Directory but don’t have suitable attributes already in place, and don’t want to roll their own schema extensions.

In a new post over at the Exchange Team Blog, You Had Me at EHLO, Nino Bilic wrote an article a couple of weeks ago that has prompted me to update you about this, and to revise what I said, in his post on Custom (aka. Extension) attributes in Exchange 2010 SP2 and their use, Bilic talks in detail on the two additions to the object class ms-Exch-Custom-Attributes.

Here’s where clarifications are necessary, and where I had the wrong idea about all those new extension attributes. Microsoft considers ms-Exch-Extension-Attribute1 through 15 to be “all yours”. As Bilic stated it, “you are free to use them as you used them before”. If you ever read the TechNet article Understanding Custom Attributes, then you probably are already using those first 15 attributes for anything and everything you might want to store in Active Directory. The Exchange Management Shell even makes it trivially easy to set/edit/remove values from those attributes, shorthanding them to “CustomAttribute#” and allowing you to write to them using the Set-Mailbox command. Logic suggests that by creating CustomAttribute16 through 45, Microsoft was just being generous and giving you more fields to play with. Not so much.

According to Bilic, CustomAttribute16 through 45 are for “future use” and should be considered reserved. What they are being used for remains to be seen, and there are no hints in the article or elsewhere, but CustomAttribute16 through 45 cannot be modified using the Set-Mailbox –CustomAttributeX command the way 1 through 15 can be, nor are they exposed in the UI, and Bilic went on to say “we cannot recommend that you use non-Exchange tools to edit their values because we might use those attributes in the future for various Exchange features.” Can you update those values with ADSI Edit or some third party tool? Probably. Should you? Not a chance.

The bottom line is to keep your hands off of CustomAttributes 15 through 45, but to also keep your fingers crossed that some new functionality will be forthcoming. If the 15 attributes we’ve had all this time are not enough, keep in mind that SP2 did add ms-exch-extension-custom-attribute1 to 5, which are multi-value attributes that can store tons more information about an object. They have been shorthanded to ExtensionCustomAttribute1 to 5, and can be accessed using the Set-Mailbox command. Hopefully that will be enough to fit any needs you have in the foreseeable future.

30 New Custom Attributes? Not So Fast

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Often, Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets (slow being at best a relative term and never specific enough about what precisely is considered to be slow) can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue. While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 3 of this series, we’re going to discuss the connectivity you need to permit through firewalls for Exchange to function properly on the network.

Firewalls

There are at least three places where a firewall can cause problems for Exchange. The most common is at your Internet border, when you are trying to support a protocol and the firewall is not permitting the necessary traffic. The second is between your DMZ and the internal network, which can cause issues for both Edge Transport servers and Client Access Servers, depending upon whether you pass traffic into them directly (which is not recommended) or you publish the CAS services using TMG or some other reverse web proxy. The third, which is both the least common and the most problematic, is when there are firewalls between different internal Exchange servers, or between Exchange servers and Active Directory.

Clients on the Internet must connect to the CAS servers for the various protocols they will use. Other Internet mail servers must connect to the Edge Transport server to exchange SMTP messages, and all Exchange server roles except the Edge Transport Server must query AD directly for configuration information, and to perform LDAP lookups for servers in different sites. They will also need to communicate with Active Directory to authenticate users. Edge Transport servers have to communicate with Hub Transport servers both to update their configuration, and to pass SMTP traffic in to the internal network. Any time a firewall is between two Exchange servers, or between an internal Exchange server and either Active Directory or any other part of the Exchange environment, you must ensure that all required traffic is permitted to pass through the firewall. Firewalls frequently translate IP addresses, called NAT. NAT is okay for some protocols; for others not so much. Windows 2008 and 2008 R2 servers will source all ephemeral connections from ports between 49152 and 65535. If you have any Exchange servers running 2003 or 2003 R2, you will need to expand that range to 1025-65535. The same can be said for clients. Windows Vista and 7 will source their connections from ports between 49152 and 65535. XP clients will source from 1025 to 65535.

Let’s look at each of the roles to see more about the required connectivity.

Edge Transport Server Role

Of course, your firewall needs to permit inbound TCP 25 from the Internet (ip any) to enable other Internet mail servers to send it email, and source ports can be anything from 1025 on up. You should also permit TCP port 587, which is commonly used by clients sending TCP over TLS connections. Older firewalls sometimes attempt to perform a rudimentary form of Intrusion Protection (fixup, inspect, etc.) which can often cause more problems than it solves, so consider carefully whether to enable that or not.

The Edge Transport server doesn’t access Active Directory directly, it stores it configuration in an instance of Active Directory Lightweight Directory Services. It uses an Edge Subscription to subscribe to a Hub Transport server in an Active Directory site, which will use the Microsoft Exchange EdgeSync service to synchronize Active Directory data to AD LDS. The Edge Transport server must be able to communicate to each and every Hub Transport server within the site it is subscribed to over TCP port 50636. That’s every Hub Transport server in the site, not just one or two, and it will source its queries from an ephemeral port between 49152 and 65535. If you add a Hub Transport server to the site, you must update your firewall rules to include the new server and update your Edge subscription.

You can use NAT for both Internet traffic in to the Edge Transport server, and from the Edge Transport server into the Hub Transport servers in the subscribed site.

Hub Transport Server Role

The Hub Transport server must contact Active Directory to perform message categorization, necessary for recipient lookup and routing resolution. This will include the location of the recipient’s mailbox and any restrictions or permissions that may apply. It will also use LDAP queries to expand the membership of distribution lists to determine membership of a dynamic distribution list.

It’s best if there is no firewall between a Hub Transport server and the Domain Controllers in the same site, but if you must place a firewall between them, ensure that the Exchange server can reach all Domain Controllers in the site over all the following ports and protocols.Collapse this tableExpand this table

Collapse this tableExpand this table

NAT is no good here; it can break RPC DCOM traffic which is used for some Active Directory functions.

Client Access Server Role

The Client Access server role services clients connecting from the Internet who want to use Outlook Web App, POP3, IMAP4, or ActiveSync. When a connection is received, the Client Access server authenticates the user against AD and then queries to determine the appropriate mailbox server. If the user’s mailbox is in the same site, the user is connected directly to their mailbox. If in a different site, the connection is redirected to a Client Access server in the remote site.

If you are going to provide client connections directly to the CAS server, you must permit the following for the relevant client protocols.Collapse this tableExpand this table

Unified Messaging Server Role

The Unified Messaging server will need essentially the same connectivity as the Hub Transport server role, plus whatever required ports are necessary for your particular VoIP gateway. Consult your vendor’s documentation for those specifics.

Mailbox Server Role

The Mailbox server will also need the same connectivity as detailed for the Hub Transport server role.

Limiting RPC ports

Firewall admins don’t like to carve large holes in their walls, and will often request that you limit the port ranges used by RPC connections. This is supported, and well documented, but be warned. It is very common to limit RPC connections to too narrow a range of ports. This will manifest as random failures particularly at peak load times, with tons of 1722 errors. If you must restrict RPC ports, I suggest you start with a range of at least 1000 ports, and carefully monitor clients and servers to ensure that this is enough to support all connections during peak times.

Troubleshooting Exchange firewall issues

Knowing the ports Exchange uses will help you troubleshoot issues. If you suspect Exchange is having a problem caused by a firewall, it’s best if you can work directly with the firewall administrator, who can monitor the source and/or destination IP addresses to see if rules are blocking. If that is not possible, you can test connectivity between Exchange and Active Directory or other Exchange servers by using the PortQueryUI tool. You can also use PING, the TCPING tool, or even the Windows Telnet client to see whether you can connect to the port or not.

PortQueryUI can provide specific success or failures, but you can use PING to make sure you can reach the destination server, and then TCPING or Telnet to confirm whether or not you can make a connection on the specific ports required. If you get timeouts or refusals, and you have confirmed the destination server is up and running, then you are probably dealing with a firewall issue. There’s no real workaround here; the firewall admin must permit the required traffic for all services.

Coming up next

In Part 4, we will look at the issues that can cause Exchange problems when NICs are involved, and how to troubleshoot those problems. Here’s a rundown of the six parts in this series. We’ll update with live links as each part is published over the next several weeks:

1. Introduction and DNS
2. Active Directory
3. Firewalls (this post)
4. NICs
5. RPCs
6. Client side issues

Troubleshooting Exchange Networking: Firewalls (Part 3)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

If you are still on an Exchange 2003 or 2007 platform and are starting to plan your upgrade to Exchange 2010 (or your to the cloud), you are probably looking at your public folders and thinking to yourself: “oh gods no please don’t make me go through them! I promise I will be good from now on and eat my vegetables and clean my room please oh please oh please don’t make me deal with the public folders and please don’t send me to the cornfield!”. Okay, you might not have quite that, emotional reaction, but if you aren’t dreading the task, you haven’t started to think about it yet.

1. Eventually, they won’t be supported anymore.

2. Anybody remember where we stored that customer list?

3. Collaboration? Not so much.

4. Backups? We don’t need no stinking backups!

5. Public Folder management tools, what Public Folder management tools?

6. Wow! I remember that. Gosh, I haven’t seen that in years!

7. When I grow up, I want to be SharePoint.

7 Reasons Public Folders Need to Go Away

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Customize the Exchange Management Shell as an Exchange administrator, it’s only a matter of time before you embrace the dark side and come to know the true power of shell. The Exchange Management Shell is the direct interface between you and the underlying PowerShell cmdlets that are used to query, configure, and manage Exchange. Getting comfortable with a command line interface after years of GUI work is a big shift for many admins, but if you start out slow, and work your way through things step by step, you’ll soon find that you are a PowerShell Jedi. Making something your own is the first step towards getting comfortable with it, so in this post, we’ll see how to customize the Exchange Management Shell to make it your own.

Again, the Exchange Management Shell (EMS) is simply Exchange’s pathway into PowerShell. If you look at the properties of the EMS shortcut, you will see that it does three things:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1′; Connect-ExchangeServer -auto;”

1. It launches PowerShell,
2. It runs a PowerShell script called RemoteExchange.ps1, and finally
3. Automatically connects to the localhost Exchange server.

PowerShell uses profiles to control how it looks and feels. You can also use profiles to configure PowerShell with your own aliases, functions, etc. If you examine the RemoteExchange.ps1 script referenced in the path above, you will find that it configures the size of the EMS window, provides the tips you see at launch, and defines some functions specific to Exchange.

To tailor the appearance of your EMS, you can create/edit your PowerShell profile. You won’t always have a profile to start with. When you open the EMS, type this command:

Test-Path $profile

If you have a profile the result will show True. If you don’t, it will show… care to guess? That’s right, False. To start working with your profile, enter this command:

notepad $profile

If you didn’t have a profile, you will be prompted to create one. Now that you have a profile, what can you do? I like to have the EMS automatically open in the scratch directory I tend to save working scripts, output files, etc., in and change up the colors a little bit. Here’s an example profile file:

$Shell = $Host.UI.RawUI
$Shell.WindowTitle="A little knowledge is a dangerous thing"
$Shell.BackgroundColor="Black"
$Shell.ForegroundColor="Green"
Set-Location C:\\scratch

Let’s see what we’re doing here. First, we create a variable called $Shell, and populate it with the properties of the $Host.UI.RawUI, which stores all the attributes of the UI. Then, we set the value of the WindowTitle attribute (quote enclosed), set the foreground and background color, and then essentially we CD into our c:\scratch directory. Here’s a list of the colors you can use:

• Black
• Blue
• Cyan
• DarkBlue
• DarkCyan
• DarkGray
• DarkGreen
• DarkMagenta
• DarkRed
• DarkYellow
• Gray
• Green
• Magenta
• Red
• White
• Yellow

Save the file, and then launch the EMS. You should see your EMS with the foreground and background colors that you chose, and that your current directory is c:\scratch (or whatever you chose). Notice what you don’t see? Your Window title should display “Machine:FQDN” of your Exchange server. When you use the Connect-Exchange server command, it updates the window title to reflect the server. However, when you launch the regular PowerShell (instead of the EMS) you will see your catch window title at the top.

We’ll look more into PowerShell and the power of the EMS in upcoming posts. If you have a particular customization you like to use, please feel free to share it in a comment below.

Customize the Exchange Management Shell

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets (slow being at best a relative term, and never specific enough about what precisely is considered to be slow) can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue. While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six-part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 2 of this series, we’re going to discuss how Exchange is dependent upon and interacts with Active Directory on the network.

Active Directory

There’s a ton of network interactions between Exchange servers and Active Directory, which is why you are required to have a Global Catalog server in every site in which you have an Exchange server. An Active Directory site is usually defined as a collection of subnets with sufficient bandwidth to support replication, and that can lead to sites spanning WAN links. While the WAN may have sufficient bandwidth and low enough latency to support Active Directory replication and authentication traffic, any AD client that is in a site may connect to, and query, and Domain Controller within that site. When the target of queries is across the WAN, the total latency of the WAN link can add up to noticeable delays. Understanding just how much goes on between your Exchange server and your Global Catalog server may be enough to make you change the word “site” to “subnet.” Exchange servers will bind to a randomly selected domain controller and global catalog server in the same site, to minimize WAN traffic. Ensure that there are redundant servers will keep WAN traffic to a minimum, and optimize Exchange performance.

Note: Read-Only domain controllers are not usable by Exchange. Exchange must access writable domain controllers.

Configuration information

The configuration partition in Active Directory contains critical data about the forest-wide configuration. Exchange configuration information can be found in a subfolder of the Services container in the Configuration partition. This includes:

1. Address lists
2. Address and display templates
3. Administrative groups
4. Client access settings
5. Connections
6. Messaging records management, mobile, and UM mailbox policies
7. Global settings
8. E-mail address policies
9. System policies
10. Transport settings

All Exchange server roles, except the Edge Transport Server, will query AD directly for this information. Here’s more specific information on how each role depends upon AD. You can also read more about that here http://technet.microsoft.com/en-us/library/aa998561.aspx.

Hub Transport Server Role

The Hub Transport server must contact Active Directory to perform message categorization, necessary for recipient lookup and routing resolution. This will include the location of the recipient’s mailbox and any restrictions or permissions that may apply. It will also use LDAP queries to expand the membership of distribution lists to determine membership of a dynamic distribution list.

The Hub Transport Server will use cached information regarding the AD site topology to determine routing for message delivery between sites. If the Hub Transport server determines that a mailbox is in the same site, it will deliver the message directly to the Mailbox server, otherwise it will route the message to a Hub Transport server in the destination site.

The Hub Transport server uses the application partition of Active Directory to store and access configuration information, including transport rules, journal rules, and connectors.

Client Access Server Role

The Client Access server role services clients connecting from the Internet who want to use Outlook Web App, POP3, IMAP4, or ActiveSync. When a connection is received, the Client Access server authenticates the user against AD and then queries to determine the appropriate mailbox server. If the user’s mailbox is in the same site, the user is connected directly to their mailbox. If in a different site, the connection is redirected to a Client Access server in the remote site.

Unified Messaging Server Role

The Unified Messaging server queries Active Directory to retrieve global configuration information, such as dial plans, IP gateways, and hunt groups. When a message is received by the Unified Messaging server, it matches the telephone number to a recipient address, then the location of the user’s mailbox. It can then route the voicemail message to a Hub Transport server for delivery to the mailbox.

Mailbox Server Role

The Mailbox server also stores configuration information Active Directory, including agent configuration, address lists, and policies. The Mailbox server will use this to enforce mailbox policies and global settings.

Edge Transport Server Role

The Edge Transport server doesn’t access Active Directory. It stores it configuration in an instance of Active Directory Lightweight Directory Services. It uses an Edge Subscription to subscribe to a Hub Transport server in an Active Directory site, which will use the Microsoft Exchange EdgeSync service to synchronize Active Directory data to AD LDS.

Site definitions

There are two rules of thumb for Active Directory site design and how it impacts Exchange:

1. Make sure every single subnet that hosts an Exchange server belongs to a site
2. Don’t let any of those sites span the WAN, no matter how much bandwidth you have available.

If an Exchange server cannot determine its AD site because the subnet does not belong to a site, the MSExchangeDSA will fail with a 2114 and MSExchangeSA will fail with a 1005. In both cases it is because Exchange could not determine the AD site based on the subnet. Even the fastest WAN links have higher latency than the slowest LAN links, and that latency will have a cumulative and negative impact on Exchange performance as the server is waiting on responses from domain controllers if the DC is on the far side of the WAN from the Exchange server.

Troubleshooting Exchange interaction with Active Directory

Knowing how Exchange depends upon Active Directory will help you troubleshoot issues. The four main categories of problem are:

1. Network latency between the Exchange server and GC/DC
2. Firewall rules blocking connection attempts
3. Incorrect site configuration
4. Replication problems within AD

If you suspect Exchange is having a problem accessing Active Directory, first ensure that Exchange can communicate with a domain controller for each domain in the forest that has users with mailboxes, and that there is at least one domain controllers in the same site that is a global catalog server. Look for errors including 2114, 1005, and 1722.

Test connectivity between Exchange and Active Directory by using the PortQueryUI tool, and the response times to LDAP queries using LDP.EXE and a protocol analyzer. And of course, ensure that you have no replication problems with your Active Directory. A domain controller that stops replicating because of DNS islanding or other connectivity issues with the rest of the forest will directly impact AD. Changes in AD (like name, group membership, SMTP proxy addresses, etc.) must replicate to all domain controllers that Exchange relies upon before you can be sure that Exchange will pick up on/display the differences.

Performance will be enhanced by redundancy. When possible, ensure that there are multiple global catalog servers in the same site as every Exchange server, and that every domain in the forest with Exchange users is represented.

Performance of Exchange will also improve directly with the capabilities of those domain controllers. When the DC is able to cache the entire Active Directory in memory, response to queries from Exchange will be much faster. Look at implementing 64bit DCs with enough RAM to cache the entire database.

On a domain controller a quick way to check for replication problems is to run this command in an administrative command prompt

Repadmin /replsummary [enter]

Check for fails, servers that are down or unreachable, and larger times since the last replication event.

Coming up next

In Part 3, we will look at the connectivity requirements for Exchange as they relate to firewalls, and how to troubleshoot those problems. Here’s a rundown of the six parts in this series. We’ll update with live links as each part is published over the next several weeks:

1. Introduction and DNS
2. Active Directory
3. Firewalls
4. NICs
5. RPCs
6. Client side issues

Troubleshooting Exchange Networking: Active Directory (Part 2)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Whether you are troubleshooting an Exchange server performance issue, trying to see how well you sized your servers, or just want a better idea of what your users are doing, the Exchange Server User Monitor from Microsoft (or ExMon as it is known to its friends) is a great, free tool you can use to gather all sorts of information about your Exchange environment. The Exchange Server User Monitor has been around for years, and this latest version, 14.2.247.5, was released in December of 2011.

You can download ExMon from this link and use to evaluate a server, or an individual user’s interactions with that server. As with many tools from Microsoft, this has been around for years, but gets an update and a facelift every so often. With ExMon, you can view the following information:

• IP addresses used by clients
• Microsoft Office Outlook® versions and mode, such as Cached Exchange Mode and classic online mode
• Outlook client-side monitoring data
• Resource use, such as:
  • CPU usage
  • Server-side processor latency
  • Total latency for network and processing with Outlook 2003 and later versions of MAPI
  • Network bytes
  • And more.

The download is a simple MSI file that weighs in under 2MB in size, and the install is of the next agree next enter variety. You don’t need to run this tool on your Exchange server; It can run just fine on another server or on your workstation when you want to use it to view trace files gathered by the tool running on an actual Exchange server. Just launch it from the command line passing the ETL filename in the command, like exmon.exe c:\temp\exch01.etl [enter]. Note, if you are going to run the tool on your workstation, you can find it at C:\Program Files (x86)\Exchange User Monitor. There’s a reg file in that directory that you should import into your registry so the tool can work properly.

You can collect data for use with ExMon in one of three ways:

• Collecting data directly with ExMon
• Collecting data by using System Monitor (Windows 2000 Server and Windows Server 2003 only)
• Collecting data by using command-line tools.

Using ExMon directly to collect data is best done when you are looking to “spot check” a server and plan to gather data for only short intervals. ExMon trace files can become very large, especially when the monitor interval is long, and parsing these files can be both CPU and RAM intensive.

For trending data, it’s best to use System Monitor, and schedule it with a reasonable sampling frequency. It’s best to start out small, monitor the size of the files generated, and adjust your sampling interval and the duration of your monitoring as you see fit.

While the documentation has not been updated yet for this version, you can read more about how to use ExMon at the TechNet site: http://technet.microsoft.com/en-us/library/bb508855(EXCHG.65).aspx.

Cool Tools: Microsoft Exchange Server User Monitor

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Often Exchange administrators will receive escalated help desk tickets from users complaining that Exchange is “slow” and demanding resolution. These sorts of tickets (slow being at best a relative term, and never specific enough about what precisely is considered to be slow) can be extremely challenging to work, since the subjective nature of slowness is often combined with an inability to replicate the problem, or the problem is intermittent. The Exchange admin can take a look at the server(s) for high CPU utilization, low memory conditions, disk and network queue lengths exceeding the norm, and finding nothing, shrug it back off to the desktop support team as a client issue. While it is often a client issue, there are several places between Outlook and a user’s mailbox that can cause intermittent slowness, and are fair to call networking bottlenecks. In a six part series of articles, we’ll look at how Exchange interacts on the network with various other services to help you identify network issues, and troubleshoot them when they occur.

In many cases, troubleshooting Exchange network bottlenecks will require a network trace, and may also require performance monitor counters. This series of articles will talk about both of those in general terms; how to use NetMon or Wireshark, and PerfMon are out of scope. In Part 1 of this series, we’re going to discuss how Exchange is dependent upon and interacts with DNS on the network.

DNS

DNS is one of the most important, and fundamental services on any TCP/IP network and the critical role it plays in all aspects of Exchange cannot be understated. Every single interaction between servers depends on being able to resolve a name to an IP address, and being able to quickly (and correctly) perform name resolution can set the tone for the entire transaction.

Most of you will be using AD integrated DNS, so your DNS servers will be domain controllers. Keep in mind that the default TTL for AD integrated zones is 3600, so your Exchange servers will cache responses for an hour before trying to resolve the same name again. Using AD integrated zones also means that changes to DNS records must replicate to all domain controllers, and then the TTL must expire before you can assume that a client or Exchange server is resolving the right IP address to name.

To ensure that the right IP address is being provided in response to a query, open an administrative command prompt on the Exchange server you are troubleshooting, and use the NSLOOKUP command to query the primary DNS server, and the secondary. Confirm that both provide the same result and that it is correct, and then ping the destination server by name. Compare the IP address in the PING command to what NSLOOKUP returned to be sure that your Exchange server is trying to reach the right address. If it is not, issue the ipconfig /flushdns command to clear the local cache, and try again.

>nslookup exch2.example.com
Server:  dc1.example.com
Address:  192.168.0.2
Name:    exch2.example.com
Address:  192.168.0.6
>ping exch2.example.com
Pinging exch2.example.com [192.168.0.9] with 32 bytes of data:
Reply from 192.168.0.104: Destination host unreachable.
Ping statistics for 192.168.0.9:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

>ping exch2.example.com
Pinging exch2.example.com [192.168.0.6] with 32 bytes of data:
Reply from 192.168.0.6: bytes=32 time=4ms TTL=128
Ping statistics for 192.168.0.6:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

You want to place DNS servers as “close” to your Exchange servers as possible, configure your Exchange servers to use the closest DNS servers they can, and to keep the application response time (ART) for DNS queries as low as possible. If it takes more than 50 milliseconds to resolve a DNS performance will suffer. You can use a protocol analyzer like Microsoft’s NetMon or Wireshark to analyze that, or you can just use the dig command. A Windows port can be downloaded from here. The dig command can tell you how long it takes to resolve a name.

>dig @192.168.0.2 -t a exch2.example.com
; <<>> DiG 9.3.2 <<>> @192.168.0.2 -t a exch2.example.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 104
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;exch2.example.com.             IN      A

;; ANSWER SECTION:
exch2.example.com.      3600    IN      A       192.168.0.6
;; Query time: 8 msec
;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Fri Dec 30 15:29:26 2011
;; MSG SIZE  rcvd: 51

Eight milliseconds is not bad at all.

Your internal Exchange servers (CAS, HUB, UC, and Mailbox) should be configured to use local servers for both their primary and secondary DNS. In sites where there is only DNS server, you really ought to add another, but if you cannot, configure the secondary to be the one with the least latency. That won’t always be the one on the other side of the connection with the greatest bandwidth; test.

Your Edge Transport servers should be configured to resolve DNS queries to servers as close to the Internet edge as possible, and these should be able to go straight to root rather than forwarding to your ISP. That way, every MX lookup, SPF lookup, DKIM lookup, and PTR lookup that the Edge must perform when sending or receiving a message can complete as quickly as possible. Configuring the Exchange server to query an internal DNS server, which then must forward to your ISP, which then may forward to another, adds lots of latency to every DNS lookup. Sure, the operating system will cache those lookups, but caches expire and you are exchanging email with hundreds or thousands of domains each day. Keep in mind that changes beyond your control will be made as other admins move their services to different servers, networks, etc. Changes to DNS records take time to replicate; if you are troubleshooting a connectivity failure to a remote system, don’t forget that they may be in the middle of a change and DNS records are simply stale. Time will sort that out for you.

Considering that DNS queries must be resolved in order for an Exchange server to connect to the Global Catalog server, which it must do for authentication, to expand distribution lists, to look up topology information, and to do practically anything else, and you will understand that you don’t want to waste time just trying to resolve a name to an IP address.

Coming up next

In Part 2, we will look at how Exchange interacts with Active Directory at the network level, where bottlenecks can occur, and how to troubleshoot those problems. Here’s a rundown of the six parts in this series. We’ll update with live links as each part is published over the next several weeks.

1. Introduction and DNS
2. Active Directory
3. Firewalls
4. NICs
5. RPCs
6. Client side issues

Troubleshooting Exchange Networking: DNS (Part 1)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

If you’ve been working with Exchange for several years, you might remember a little thing from Exchange 2003 called Outlook Mobile Access. This HTML only version of browser-based access to your Exchange mailbox was developed at a time when smart phones were mostly a dream, but web browser capable phones, Palm Pilots, and Windows CE devices ruled the portable space. In a world where bell bottoms are once again popular, it should come as little surprise that OMA is back, this time courtesy of Service Pack 2 for Exchange 2010.

The Exchange Team at Microsoft decided to bring back the mini version of Outlook Web Access because apparently there is still a large demand for mobile access to Exchange email in parts of the world where web capable, but not fully “smart” phones, are still in use. These devices have less horsepower, fewer features, and only a basic HTML web browser, but cost less and require less bandwidth as well, making them perfect for area with less infrastructure, and very popular amongst prepaid plan customers.

What is OMA?

Outlook Mobile Access (OMA), or more accurately in Exchange 2010 Outlook Web Access Mini (OWA Mini), is built on a series of forms and requires only HTML and cookie support in the mobile browser. To provide maximum compatibility, it is based on HTML 2.0.

What do you get in OWA Mini?

OWA Mini includes the following features:

• Mailbox access, including all subfolders
• Calendar access
• Contact list access
• Task list access
• GAL access
• Meeting request processing
• Timezone
• OOF

How do users access it?

There is no client detection for OWA Mini. In fact, it is just a vdir called \OMA under the \OWA virtual directory. Unless you provide users a better way to get there, they will have to enter the full URL https://mail.example.com/owa/oma, which is pretty lame, so do your users a favour and create a mobile friendly URL that will redirect them to the OWA Mini path. Try http://m.example.com and have that do a 301 or use a refresh tag to direct mobile users to the full HTTPS path.

Other things to know

OWA Mini uses basic authentication only, so you must support that in your IIS instance. If you are publishing OWA Mini through TMG, you won’t be able to use FBA. There is no authentication cookie or Javascript involved, so there is no logoff button in OWA Mini. It does use the “Public” timeout for sessions, so yes, users can go right back into their mailbox after closing their browser without authenticating again if they are quick enough. You can also enable or disable OWA Mini using the Exchange Management Shell. Use the Set-OWAVirtualDirectory cmdlet with the –OWAMiniEnabled Boolean parameter to turn it completely on or off, or use the Set-OWAMailboxPolicy cmdlet with the –OWAMiniEnabled Boolean to turn it on or off on a per user/group basis with policies.

OWA Mini may have limited use for a company that has Windows Mobile, Droids, Blackberries, and iPhones, but if your users are global, or just prefer less expensive web phones, OWA Mini is a great way to provide them access to their email while on the go.

No smartphone, no problem. Meet SP2’s OMA.

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Users of practically every supported version of Windows, whether desktop or server, 32 bit or 64 bit, and even the low attack surface Windows Server Core should immediately review Microsoft Security Bulletin MS11-100 and begin testing and deployment of this patch as soon as possible. The patch, covered in KB2638420 addresses four vulnerabilities in the Microsoft .NET Framework, including 1.1 SP1, 2.0 SP2, 3.5 SP1, 3.5.1, and 4. Three of the four were privately reported, while the last one has been publicly disclosed.

In a worst case scenario, an unauthenticated attacker could send a specially crafted request to an unpatched server, and gain elevated privileges which could then execute remote code on the impacted server. Exploiting this vulnerability requires that the attacker be able to register an account on an ASP.NET site, and know an existing username. Of course, when so few follow recommended practices and rename the Administrator account, or use common accounts like Admin, Guest, etc., this doesn’t present too high a bar for any site that allows user registrations.

In all, four separate CVEs are addressed by this update, including:

1. Collisions in HashTable May Cause DoS Vulnerability – CVE-2011-3414
2. Insecure Redirect in .NET Form Authentication Vulnerability – CVE-2011-3415
3. ASP.Net Forms Authentication Bypass Vulnerability – CVE-2011-3416
4. ASP.NET Forms Authentication Ticket Caching Vulnerability – CVE-2011-3417

KB2638420 replaces several earlier patches that were released to address some of these vulnerabilities. The first, involving collisions in HashTable, can lead to a denial of service, which can be just as significant an impact to users as any other kind of attack. Exchange admins running Edge Transport Servers and/or Client  Access Servers exposed to the Internet should be aware of this and deploy this security patch as soon as possible. All Exchange server roles require the .NET Framework 3.5 SP1 and are therefore vulnerable, so all Hub Transport, Unified Messaging, and Mailbox servers should also be patched.

As with all patches, you should test this in your lab environment before deploying to production, and follow your appropriate change control processes, but that does not mean you should wait until after the New Year to start evaluating this patch. Microsoft released it out of band (instead of waiting for the normal patch Tuesday in January) because this does address a publicly disclosed vulnerability, and the combined impact should a server be successfully exploited is so critical. When patching Exchange, apply this patch to your server roles in the following order:

1. Edge Transport
2. Client Access
3. Hub Transport
4. Mailbox
5. Unified Messaging.

Microsoft Releases Critical, Out Of Band Update

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Users interested in deploying a hybrid configuration have been looking forward to Exchange 2010 SP2 for months so they could take advantage of the new hybrid configuration wizard included with SP2. That wizard takes dozens of manual steps and automates them in a simple to follow wizard, which we discussed in this article a few weeks ago.

While the hybrid configuration wizard is a great improvement in setting up an Exchange system with some mailboxes on premise, and others with a cloud service provider, it seems a small glitch made it through to the release of SP2. It seems that many customers are running into issues using PKI certificates that were previously issued and which worked without a problem in Exchange 2010 RTM and/or SP1.

There is a TechNet article called Understanding Certificate Requirements for Hybrid Deployments that details what you should do when creating a certificate for hybrid deployments. The article (as of the date this post was written) only indicates SP1, but includes the steps I followed when creating a certificate for hybrid configuration. The article discusses the use of a SAN certificate, but does not discuss using a wildcard certificate, and here’s why this is a good thing. When you run the wizard to set up hybrid configuration, the wizard parses the CN of your certificate and attempts to set up a Send Connector for the SMTP encryption between your on-premise and your remote Exchange infrastructure. If it encounters a value like *.example.com in the CN, the wizard will error out because that is an invalid name for a Send Connector. Here’s what the error looks like:

Update-HybridConfiguration

Failed

Error:

Updating hybrid configuration failed with error
'Subtask Configure execution failed: Configure Mail Flow
Execution of the New-SendConnector cmdlet had thrown an exception.
This may indicate invalid parameters in your Hybrid Configuration settings.
Cannot process argument transformation on parameter 'Fqdn'.
Cannot convert value "*.example.com" to type "Microsoft.Exchange.Data.Fqdn".
Error: ""*.example.com" isn't a valid SMTP domain."
at System.Management.Automation.PowerShell.CoreInvoke[TOutput]
(IEnumerable input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.Invoke(IEnumerable input,
PSInvocationSettings settings) at System.Management.Automation.PowerShell.Invoke()
at Microsoft.Exchange.Management.Hybrid.RemotePowershellSession.RunCommand
(String cmdlet, Dictionary`2 parameters, Boolean ignoreNotFoundErrors)'.
Additional troubleshooting information is available in the Update-HybridConfiguration
log file located at C:\Program Files\Microsoft\Exchange
Server\V14\Logging\Update-HybridConfiguration\HybridConfiguration_12_16_2011_5_58_59_634596119396658235.log.
Exchange Management Shell command attempted:
Update-HybridConfiguration -OnPremisesCredentials
'System.Management.Automation.PSCredential' -TenantCredentials 'System.Management.Automation.PSCredential'

So, what can you do to move past this? Two choices are available. The first is to not use a wildcard certificate. I know, I know, wildcard certs are awesome, solve a ton of other headaches, and security concerns notwithstanding, are a dream come true. However, since the * in the wildcard cert is what causes the wizard to hurl, stick with a SAN certificate if you need a cert that can validate more than one name. The second is to get the fix from Microsoft. If you already have a wildcard certificate, this is the more economical way to go. You can wait for RU1 that is due to release in January 2012, or you can contact Microsoft for a hotfix.

Even with this little “issue” SP2 is a great improvement over SP1, and if you are planning a hybrid deployment, it is still the way to go. A regular, SAN, or UC certificate is far less expensive than a wildcard, so this may not be an issue for you anyway, but if you already have a wildcard cert, your fix is a free phone call away.

Certificate Problems with Hybrid Configuration in SP2

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Exchange 2010 SP2 provides many updates and fixes to Exchange 2010, but only a limited set of new features. One of these, Cross-Site Silent Redirection, may go unnoticed by smaller organizations, but should be a huge improvement in the end user experience for larger, multi-site companies that use OWA. Cross-Site Silent Redirection is the name given to the new SP2 feature that enables CAS servers to redirect clients to a more optimally located server offering OWA services.

Prior to Cross-Site Silent Redirection, when a user tries to access the general OWA URL, but their mailbox is hosted in another location, the experience goes something like this:

1. User enters the OWA URL in their browser.
2. User is prompted for and enters their credentials.
3. CAS server performs service discovery, determines that it must redirect user to a different site.
4. CAS server provides page to user with link to proper OWA URL.
5. User clicks link.
6. User is prompted for and enters their credentials, again.

Not exactly the best user experience, is it? Recognizing this, the Exchange team added Cross-Site Silent Redirection with SP2. A new parameter enables the CAS server to silently redirect the client’s browser to the correct CAS server URL using a 302, which causes the browser to go to the correct CAS server URL without the user having to authenticate twice, or click on another link in a webpage.

Configure your OWA using the Set-OWAVirtualDirectory command with the new –CrossSiteRedirect switch, like this.

Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

Cross-site silent redirection can leverage FBA with your TMG. If both listeners are set up for FBA and SSO. Internally, you can also get this as long as the OWA virtual directories are set up to use integrated authentication, and the URLs are in the Local Intranet zone.

There are some circumstances where silent redirection won’t work; these include:

1. You use Basic Authentication on the OWA virtual directories.
2. You have different authentication settings on the original and targeted OWA virtual directories.
3. You are using two factor authentication (2FA).
4. You are publishing the CAS servers through TMG and use a different listener for each.

With silent-redirection, your users can leverage a single URL for OWA, and be redirected to the best CAS server without any additional effort on their part. This greatly enhances the user experience and is a great add for large organizations with OWA in multiple sites. Once you have SP2 deployed, plan on testing and deploying this feature in your environment.

Exchange 2010 SP2 offers Cross-Site Silent Redirection

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Now that Exchange 2010 SP2 is available for download, I’m sure many of you (like me) have already downloaded the binary and are testing it in the lab. Of course, the reason we test is because we want to ensure that we don’t create problems in production which is prudent and a best practice for administration. SP2 is a great service pack, and in a vanilla Exchange 2010 organization I seriously doubt you will encounter a single issue with this service pack, but how many of us are running a vanilla org, freshly installed from scratch? For the majority of us who aren’t, here are some pointers about SP2 that should prove useful.

Network timeouts and long installation times

The Exchange 2010 SP2 binary is a slipstreamed copy of Exchange 2010 with SP2. You can use it to patch an existing server, or to install a new server from scratch, so keep it handy, but also keep in mind it isn’t exactly small. The download is 535 MB, but when you run it, it will expand to 1.38 GB. Make sure you have room for that wherever you decide to expand it, and consider whether to place it on a network share where all your Exchange servers can access it, or if you should copy the downloaded EXE to Exchange servers in remote offices before you expand it.

Schema extension errors

Yes, you must extend the schema for SP2. That means you need Schema Admin rights, or to have your AD administrator extend the schema before you can apply SP2 to any server. If you are not also the AD admin, engage that person now.

CAS Server update fails

SP2 requires some additional components for CAS servers that SP1 and RTM did not. Make sure that your CAS server has the following IIS role services installed before applying SP2, or it will fail. If you are running Windows 2008 SP2 use Server Manager to install:

• IIS 6 WMI Compatibility
• ASP.NET
• ISAPI Filters
• Client Certificate Mapping Authentication
• Directory Browsing
• HTTP Errors
• HTTP Logging
• HTTP Redirection
• Tracing
• Request Monitor
• Static Content

If you are running Windows 2008 R2 you can use PowerShell to install the required modules by running:

Import-Module ServerManager [enter]

Add-WindowsFeature Web-WMI,Web-Asp-Net,Web-ISAPI-Filter,Web-Client-Auth,Web-Dir-Browsing,
Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-Request-Monitor,
Web-Static-Content [enter]

If that’t too much effort, you can install SP2 in unattended mode like this in a normal administrative command prompt.

Setup /Mode:Upgrade /InstallWindowsComponents [enter]

Errors managing RBAC

SP2 changes some of the Role Based Access Control definitions in Active Directory. If you try to manage any RBAC roles from a server that has not yet been updated, you will encounter errors in both the Exchange Management Shell, and the Exchange Control Panel.

In the shell you will see:
WARNING: The object MyMailboxDelegation has been corrupted, and it’s in an inconsistent state. The following validation errors happened:
WARNING: The property value you specified, “15″, isn’t defined in the Enum type “ScopeType”.

In the control panel you will see:
There are multiple warnings. Click here to see more
The object MyMailboxDelegation has been corrupted, and it’s in an inconsistent state. The following validation errors happened:
The property value you specified, “15″, isn’t defined in the Enum type “ScopeType”.

Upgrade all Exchange servers to SP2, or use a server that has already been upgraded to manage RBAC until you can finish patching the other servers.

Redirs for OWA fail

If you are using a simple URL and not requiring HTTPS (like http://mail.example.com) to redirect your users to their OWA, this will fail after updating to SP2. To avoid this, as soon as SP2 has been applied to the CAS server, modify your web.config file using the steps found in http://technet.microsoft.com/en-us/library/aa998359.aspx.

Cross-forest mailbox moves fail

If you have a multi-forest Exchange org, or are migrating to Office 365, this is a big one. The way MRSProxy works has changed with SP2, so the service is disabled by SP2 and settings in the EWS\web.config file are no longer used. Use the EMS command to reenable the MRSProxy.

Set-WebServicesVirtualDirectory -Identity "EWS (Default Web Site)" -MRSProxyEnabled $true [enter]

Hybrid Configuration Wizard fails

There’s a known issue setting up hybrid configuration using the wizard if the FQDN of your Hub Transport server starts with a number. You can either use a different HT server, rename your HT server, or use the EMS Update-HybridConfiguration cmdlet to set up hybrid coexistence instead of using the wizard.

Knowing these ahead of time can help to ensure your testing, and production deployment, of SP2 goes off without a hitch. Good hunting!

Troubleshooting Exchange 2010 SP2 Installation

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

You might have heard by now that Exchange 2010 SP2 has been released, and if you are looking to migrate some or all of your on-premise email to hosted email from Microsoft’s Office 365, two of the best things about SP2 are the New Hybrid Configuration Wizard and the Manage Hybrid Configuration Wizard.

The New Hybrid Configuration Wizard is designed to make establishing a hybrid coexistence relationship between your on premise Exchange organization and another Exchange organization as easy as possible. Scenarios where you would need to establish a hybrid deployment can include Office 365 or another cloud provider, where you will have some mailboxes on premise and others in the cloud either in the short term during migrations, or permanently when you want to keep some mailboxes on premise and move others to the cloud. Hybrid deployments let you:

• Share an SMTP namespace
• Share a unified GAL
• Share free/busy
• Centralize mailflow
• Use a single OWA URL
• Securely route mail between on premise and cloud mailboxes
• Move mailboxes between on premise and cloud with automatic Outlook configuration,
• and more.

Whether you want to move all of your email services to the cloud, or just a subset, one thing you should understand up front is that this will not be a point and click operation. Email is complicated, and email coexistence can be even more so, but SP2’s new Hybrid Configuration Wizard takes the approximately 50 manual steps required to set up hybrid configuration, and boils them down to a simple and wizard driven process.

The Hybrid Configuration Wizard has three main pieces:

1. A new wizard in the Exchange Management Console that provides step by step guidance through the entire hybrid deployment process.
2. New Exchange Management Shell cmdlets which are executed in the background by the wizard, but also available to you for administration and scripting.
3. Better and simplified management of many of the hybrid features.

When you run the wizard to establish a hybrid configuration, the wizard will handle many of the testing and verification steps that used to be manual processes, including:

1. Verified all prerequisites for hybrid deployment.
2. Creates the federation trust between your on premise environment and Office 365.
3. Creates the mutual organization relationships between your on premise Exchange and Office 365.
4. Makes the necessary email address policy modifications needed for moving mailboxes from an on premise server to Office 365.
5. Takes care of both mailtips and free/busy calendar sharing, as well as message tracking for easy interaction between on premise and cloud users.
6. Sets up the secure mail flow (TLS) between your on premise and Office 365, and configures mail routing to meet your requirements in case you have on premise DLP or other services.
7. Enables online archiving for on premise mailboxes if you have subscribed to that feature.

The Exchange 2010 SP2 Manage Hybrid Configuration Wizard enables you to manage this hybrid deployment easily, making your Exchange organization seem like a single management entity, even though some of your mailboxes are in the on premise infrastructure, and others are in the cloud at Office 365 datacenters. With a hybrid deployment, users won’t notice (or care) whether another user within the company has their mailbox on premise or in the cloud; they all look like they are a part of a unified Exchange organization. Mailbox moves between on premise and cloud are easy and can be done with minimum interruption to the user. If they are using Outlook 2010, they can even stay connected to their mailbox until the last few moments of a move, and will only need to close and restart Outlook to connect to their mailbox; no client reconfiguration, no download of a new OST.

If you are considering Office 365 as a part of your email service offering, be sure to look at the benefits of the SP2 Hybrid wizards. Managing email won’t become an end user task, but these wizards will sure make our lives easier!

First Look At The SP2 Hybrid Configuration Wizards

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

With 26 days left in calendar year 2011, the Exchange team at Microsoft stayed true to their word, and have delivered an early Christmas present to email admins all over the world. Exchange 2010 Service Pack 2 has arrived! We’ve covered some of the things you could expect with the latest service pack to Exchange 2010, both here and here, and offered advice on getting ready for testing the service pack in your environment, and extending the schema as required for this service pack.

Service Pack 2 includes all the update from the release of Exchange 2010 RTM through Rollup 6, so some of you may be asking yourselves if you really need to rush right out and apply SP2. As with any patch or update, testing is required, so a measured and careful pacing is far better than a rush, but there’s a lot of great stuff inside SP2 that should appeal to you. Here’s the list from the TechNet article What’s New in Exchange 2010 SP2.

Hybrid Configuration Wizard

Exchange 2010 SP2 introduces the Hybrid Configuration Wizard which provides you with a streamlined process to configure a hybrid deployment between on-premises and Office 365 Exchange organizations. Hybrid deployments provide the seamless look and feel of a single Exchange organization and offer administrators the ability to extend the feature-rich experience and administrative control of an on-premises organization to the cloud. For more information, see Understanding the Hybrid Configuration Wizard.

Address Book Policies

Exchange 2010 SP2 introduces the address book policy object which can be assigned to a mailbox user. The ABP determines the global address list (GAL), offline address book (OAB), room list, and address lists that are visible to the mailbox user that is assigned the policy. Address book policies provide a simpler mechanism to accomplish GAL separation for the on-premises organization that needs to run disparate GALs. For more information, see Understanding Address Book Policies.

Cross-Site Silent Redirection for Outlook Web App

With Exchange 2010 SP2, you can enable a silent redirection when a Client Access server receives a client request that is better serviced by a Client Access server located in another Active Directory site. This silent redirection can also provide a single sign-on experience when forms-based authentication is enabled on each Client Access server. For more information, see Understanding Proxying and Redirection.

Mini Version of Outlook Web App

The mini version of Outlook Web App is a lightweight browser-based client, similar to the Outlook Mobile Access client in Exchange 2003. It’s designed to be used on a mobile operating system. The mini version of Outlook Web App provides users with the following basic functionality:

• Access to e-mail, calendar, contacts, tasks and the global address list.
• Access to e-mail subfolders.
• Compose, reply to, and forward e-mail messages.
• Create and edit calendar, contact, and task items.
• Handle meeting requests.
• Set the time zone and automatic reply messages.

For more information, see Understanding the Mini Version of Outlook Web App.

Mailbox Replication Service

In Exchange 2010 SP1, if you wanted to move mailboxes from on-premises to Outlook.com or to another forest, you had to enable MRSProxy on the remote Client Access server. To do this, you had to manually configure the web.config file on every Client Access server. In Exchange 2010 SP2, two parameters have been added to the New-WebServicesVirtualDirectory and Set-WebServicesVirtualDirectory cmdlets so that you don’t have to perform the manual configuration: MRSProxyEnabled and MaxMRSProxyConnections. For more information, see Start the MRSProxy Service on a Remote Client Access Server.

Mailbox Auto-Mapping

In Exchange 2010 SP1, Office Outlook 2007 and Outlook 2010 clients can automatically map to any mailbox to which a user has Full Access permissions. If a user is granted Full Access permissions to another user’s mailbox or to a shared mailbox, Outlook, through Autodiscover, automatically loads all mailboxes to which the user has full access. However, if the user has full access to a large number of mailboxes, performance issues may occur when starting Outlook. Therefore, in Exchange 2010 SP2, administrators can turn off the auto-mapping feature by setting the value of the new Automapping parameter to false on the Add-MailboxPermission cmdlets. For more information, see Disable Outlook Auto-Mapping with Full Access Mailboxes.

Multi-Valued Custom Attributes

Exchange 2010 SP2 introduces five new multi-value custom attributes that you can use to store additional information for mail recipient objects. The ExtensionCustomAttribute1 to ExtensionCustomAttribute5 parameters can each hold up to 1,300 values. You can specify multiple values as a comma-delimited list. The following cmdlets support these new parameters:

• Set-DistributionGroup
• Set-DynamicDistributionGroup
• Set-Mailbox
• Set-MailContact
• Set-MailPublicFolder
• Set-RemoteMailbox

Litigation Hold

In Exchange 2010 SP2, you can’t disable or remove a mailbox that has been placed on litigation hold. To bypass this restriction, you must either remove litigation hold from the mailbox, or use the new IgnoreLegalHold switch parameter when removing or disabling the mailbox. The IgnoreLegalHold parameter has been added to the following cmdlets:

• Disable-Mailbox
• Remove-Mailbox
• Disable-RemoteMailbox
• Remove-RemoteMailbox
• Disable-MailUser
• Remove-MailUser

You can download SP2 from this link http://www.microsoft.com/download/en/details.aspx?id=28190. At 535 MB, it isn’t the smallest update you have ever had to download. It comes down as an EXE, so saving it to a common location that all of your Exchange servers can access will keep you from having to do multiple downloads. Remember, both during testing, and when it comes time for production deployment, patching should follow this order for servers:

1. Client Access Servers (all servers in a CAS array consecutively)
2. Hub Transport Servers
3. Unified Messaging Servers
4. Mailbox Servers
5. Edge Transport Servers (which can actually be done whenever, but it makes sense to leave them to last just for consistency).

I’m not saying Steve Balmer is a jolly old elf, but Santa’s helpers on the Exchange team worked very hard on SP2, and it’s the best early Christmas present I’ve gotten this year. Now, off to submit that change request!

Christmas Comes Early – Exchange 2010 SP2 is here!

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

With the imminent release of Exchange 2010’s Service Pack 2, I thought it would be nice to share some of the more interesting details that may be in store. I was digging around the Microsoft site looking for some documentation on what changes are actually made to the Active Directory schema when you extend it, as some fellow engineers had (unfounded) concerns about extending the schema. In my quest for documentation, I came across some very interesting documentation made available by Microsoft.

The Exchange Server Active Directory Schema Changes Reference is a Microsoft Word document that defines every change made to the Active Directory schema since Exchange 2003. This one hundred and seventy-one page tome goes into specific detail, and will no doubt prove to be immensely useful to developers and AD archaeologists in the future. The reason I am sharing it with you now is because it details even those changes that SP2 will make to the schema (yes, that’s correct, you will need to extend the schema to apply SP2, as mentioned in this article).

SP2’s schema extensions will modify several of the common classes we’re used to dealing with, including Mail-Recipient and ms-Exch-Mail-Storage, and our favourite ms-Exch-CustomAttributes, but where it gets interesting is in what classes and attributes are being added. A quick scan of these supports some of the new features we know are coming in SP2, including Address Book Policies, but take a look at the full list.

Classes Added By Exchange 2010 SP2

The following classes are added when you install Exchange 2010 SP2:

•             ms-Exch-Address-Book-Mailbox-Policy

•             ms-Exch-Coexistence-Relationship

•             ms-Exch-ActiveSync-Device-Autoblock-Threshold

Attributes Added by Exchange 2010 SP2

The following attributes are added when you install Exchange 2010 SP2:

•             ms-Exch-Content-Byte-Encoder-Type-For-7-Bit-Charsets

•             ms-Exch-Content-Preferred-Internet-Code-Page-For-Shift-Jis

•             ms-Exch-Content-Required-Char-Set-Coverage

•             ms-Exch-Address-Book-Policy-Link

•             ms-Exch-Address-Book-Policy-BL

•             ms-Exch-Address-Lists-Link

•             ms-Exch-Address-Lists-BL

•             ms-Exch-Global-Address-List-Link

•             ms-Exch-Global-Address-List-BL

•             ms-Exch-Offline-Address-Book-Link

•             ms-Exch-Offline-Address-Book-BL

•             ms-Exch-All-Room-List-Link

•             ms-Exch-All-Room-List-BL

•             ms-Exch-Coexistence-Domains

•             ms-Exch-Coexistence-External-IP-Addresses

•             ms-Exch-Coexistence-Feature-Flags

•             ms-Exch-Coexistence-Servers

•             ms-Exch-Extension-Attribute-16

•             ms-Exch-Extension-Attribute-17

•             ms-Exch-Extension-Attribute-18

•             ms-Exch-Extension-Attribute-19

•             ms-Exch-Extension-Attribute-20

•             ms-Exch-Extension-Attribute-21

•             ms-Exch-Extension-Attribute-22

•             ms-Exch-Extension-Attribute-23

•             ms-Exch-Extension-Attribute-24

•             ms-Exch-Extension-Attribute-25

•             ms-Exch-Extension-Attribute-26

•             ms-Exch-Extension-Attribute-27

•             ms-Exch-Extension-Attribute-28

•             ms-Exch-Extension-Attribute-29

•             ms-Exch-Extension-Attribute-30

•             ms-Exch-Extension-Attribute-31

•             ms-Exch-Extension-Attribute-32

•             ms-Exch-Extension-Attribute-33

•             ms-Exch-Extension-Attribute-34

•             ms-Exch-Extension-Attribute-35

•             ms-Exch-Extension-Attribute-36

•             ms-Exch-Extension-Attribute-37

•             ms-Exch-Extension-Attribute-38

•             ms-Exch-Extension-Attribute-39

•             ms-Exch-Extension-Attribute-41

•             ms-Exch-Extension-Attribute-40

•             ms-Exch-Extension-Attribute-42

•             ms-Exch-Extension-Attribute-43

•             ms-Exch-Extension-Attribute-44

•             ms-Exch-Extension-Attribute-45

•             ms-Exch-Coexistence-On-Premises-Smart-Host

•             ms-Exch-Coexistence-Secure-Mail-Certificate-Thumbprint

•             ms-Exch-Coexistence-Transport-Servers

•             ms-Exch-extension-custom-attribute-1

•             ms-Exch-extension-custom-attribute-2

•             ms-Exch-extension-custom-attribute-3

•             ms-Exch-extension-custom-attribute-4

•             ms-Exch-extension-custom-attribute-5

•             ms-Exch-ActiveSync-Device-AutoBlock-Duration

•             ms-Exch-ActiveSync-Device-Autoblock-Threshold-Incidence-Duration

•             ms-Exch-ActiveSync-Device-Autoblock-Threshold-Incidence-Limit

•             ms-Exch-ActiveSync-Device-Autoblock-Threshold-Type

Notice all those new Extension Attributes? If you have ever worked in a company that wanted to store more data in ms-Exch-Extension attributes instead of deploying their own schema extensions, you have probably run into a supply and demand situation where there just weren’t enough attributes to go around. Well SP2 adds another thirty, tripling the available extension attributes. For a couple of my customers, that’s reason enough to extend the schema with a beta of SP2 even if you don’t plan to actually deploy the service pack until next Spring! All of these new extension attributes will be indexed and replicated to the Global Catalog, making searches across AD for whatever you store in those attributes easier to execute across the forest.

Close to thirty MAPI ID’s are also being added, which may hint at new capabilities in store for the next version of Outlook. Time will have to tell on that one, but the note at the end holds a clue.

Only attributes with MAPI IDs can be retrieved directly from Active Directory Domain Services (AD DS) by Microsoft Outlook or other MAPI clients.

You can download the Schema reference from http://www.microsoft.com/download/en/details.aspx?id=5401 but be aware; for reasons that defy all logic, Microsoft chose to make this download an MSI file, that “installs” the documentation to your Program Files directory. Yes, that’s right, what at the end is just simple docx must be installed, invoke ConsentUI, build a directory path in your Program Files directory, and then drop a docx. With so much other documentation available from Microsoft in docx or PDF, this makes no sense, so you might want to just crack the MSI open and extract the docx by hand. It’ll be quicker!

However you choose to get the file, have a look and keep it handy. It’s a good history lesson in the evolution of Exchange, and I’m sure many of you will find a use for all those new extension attributes!

A Deeper Look into Exchange 2010 SP2

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

We’ve spent some time going over the Offline Address Book in Exchange 2010. In our first post on the topic, Inside Exchange -The Offline Address Book, we introduced the OAB and went over creating, storing, distributing, and updating it. Then, in Troubleshooting the Offline Address Book, we looked at how to fix some common issues that come up with the OAB from time to time, including server side issues, client-side issues, and when network problems arise. In this final post on the Offline Address Book, we’re going to go over some best practices for Exchange admins to use with regards to the OAB.

1. Make sure the mailbox server that generates the OAB has sufficient disk space. Temp files can take up a lot of space for a short period of time, and while you can move those to a different volume, starting with enough disk space on C: is critical for any server.
2. Ensure antivirus exceptions are properly configured. Exempt the temp directory, the OAB directory structure, and consider exempting LZX and XML files from real-time scans.
3. Make sure the CAS server’s IIS directories are also exempt. A mailbox server may create the OAB, but it’s the CAS server that distributes it to clients.
4. OAB generation is CPU intensive. By default, it runs on the mailbox server each day at 500 local time. Schedule backups and any other processor intensive activities so they do not overlap OAB generation.
5. Make sure HR and any other groups understand that changes to personal information may take a couple of days to propagate to all users so that you have time for AD replication to complete, and then for the daily OAB updates to run, and finally for users to pull down those updates, otherwise they may expect telephone number changes to happen instantly. Manage users expectations accordingly.
6. Don’t change permissions on the OAB directory structure on the Mailbox server or IIS directories on the CAS server, no matter what security template the infosec team wants you to run. Just don’t do it – the security gains are hypothetical at best; the things those templates can break are very real.
7. Whenever possible, use the latest version of Outlook. Outlook 2010 is much more efficient about downloading the OAB than earlier versions are, and that can make a big difference when you have made a larger volume of changes to the GAL, such as a new SMTP suffix. Outlook 2010 can deal with difference files if no more than 50% of the OAB has changed; earlier versions’ threshold is 12.5%.
8. Keep a close eye on Active Directory replication, and ensure that the Mailbox server that generates the OAB always has a Global Catalog server in the same site as it is. Users can authenticate across site boundaries and probably won’t notice any issue, but OAB generation can grind to a halt.
9. OABs are generated on one mailbox server and replicated to servers throughout your Exchange organization. If your first Mailbox server is not optimally placed in your network, move the OAB generation task to a Mailbox server that is more centrally located.

Follow these nine best practices for the care and feeding of your Offline Address Book and your servers will thank you.

9 Top Practices for Offline Address Books

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Microsoft Exchange 2010 was first introduced two years ago. While adoption was initially slow, despite Microsoft’s aggressive efforts to spur rapid adoption, it seems that companies are finally starting to see the benefits of the software and ready to migrate to it in a big way.

According to a recent independent survey of some 500 IT decision makers, more than three-quarters of them (77 percent) said they expected to migrate to Exchange 2010 or Office 365 in the next two years. If that happens, that means hundreds of thousands of businesses will be embracing the software in the next 24 months.

There are many reasons why the migration to Exchange 2010 has become a stampede. Two of the top rationales are new features (57 percent), which includes better support for mobile devices, and easier administration (50 percent). Also high on the list of migration motivators were security (49 percent), larger mailboxes (49 percent), improved storage options (48 percent), and improved web access (46 percent), the survey said.

Also, to some extent  companies’ enthusiasm to migrate is being fired by a recognition of the increased role email is playing to business success. Not only does Exchange 2010 offer better handling of email while imposing less of a burden on harried IT personnel, but it can do it at a lower cost.

According to a recent report in The Independent, email is far more effective in converting eyeballs into cash than any other web medium. 25 percent of people who open an email in a sales campaign will be converted into a buyer, the publication reported. That’s far and away higher than conversions from clicking on links (10 percent) and website visitations (2 percent).

As important as email is to a successful business, it can be costly to store and archive, which must be done for compliance as well as business reasons. Companies that have clung to older versions of Exchange are finding that the storage options offered by Exchange 2010—most notably the ability to swap out expensive SAN architecture for low cost SATA drives—can save them barrels of money. For instance, storage and archiving costs for an Exchange 2003 deployment can be 40 percent higher compared to what they cost with Exchange 2010.

There are productivity costs associated with older Exchange deployments too, especially because they don’t have the robust support of Exchange 2010 for the web and mobile platforms, the independent reported.

Another factor contributing to the step-up in Exchange 2010 adoption is its unique position as a bridge to the cloud. As the high-tech research firm Gartner has pointed out in the past,

“Exchange 2010 represents both the beginning of the end of the premises-based email era, and the dawn of the cloud-based email era.”

The strategy adopted by Microsoft for Exchange 2010 could pay off big for the company as it faces a growing number of competitors trying to capture a piece of its Exchange business.

“With several low-cost competitors snapping at its heels,” observed one technology commentator, “Microsoft’s hybrid strategy is a win-win one as it allows the company to protect its customer base in the on-premise model—while simultaneously giving customers the choice to migrate to a new cloud-based model.”

Migration to Exchange 2010 Becoming a Stampede

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Update Rollup 6 for Exchange Server 2010 Service Pack 1 was released late last month, and has been around long enough now that it is seriously time for you to plan its deployment into your Exchange infrastructure. With the problems that were encountered with RU4, many admins have been gun-shy and skipped RU5 altogether, but RU6 includes a number of fixes for system crashes and other issues, and with SP2 still lacking a release date, prudent admins should deploy this rollup on their systems.

This rollup includes updates for Exchange server since the release of service pack 1 and includes twenty-eight fixes for issues as diverse as:

• retention policies
• quotas
• ActiveSync
• incompatibility with antivirus programs
• memory issues
• and many more.

As with any update to Exchange, you need to test this thoroughly in your environment, and the deployment is not without its own unique set of challenges, namely with Role Based Access Control and Forefront services.

Before deploying RU6 to your Exchange servers, you will need to tend to Forefront. If Forefront Protection for Exchange is running on your Exchange server when RU6 is deployed, you will probably find that post-install, neither the Information Store nor the Transport service start back up. To avoid this problem, open an elevated command prompt and stop all Forefront services. Once the rollup has deployed and you have verified all the appropriate Exchange services are running, restart Forefront. Assuming you are also tending to operating system patches while you have your maintenance window, you will be rebooting your servers anyway, so double-check when they come back up that all services are running properly.

Yes, that’s right, there are several operating system patches that have been released since RU4 (which is probably the last time you patched your Exchange servers) and some of them include fixes for critical vulnerabilities, so make sure you patch the operating system while you are at it.

The other issue to be aware of has to do with Role Based Access Control and Exchange 2010. If you are not using it, you won’t notice or care, but RU6 does make some changes that will cause what are called “cosmetic” issues with RBAC . These are transient, can safely be ignored, and will resolve themselves once all of the Exchange servers in your organization are running RU6, but between the first and the last, you will encounter errors when using the Exchange Control Panel to manage roles, or when using the Exchange Management Shell and running either the Get-ManagementRole or Get-ManagementRoleAssignment cmdlets.

Don’t worry about your existing RBAC configuration; it will continue to work without issue. But if you need to make any RBAC changes during the deployment of RU6, just make sure you establish your EMS session using a server that has already been updated to RU6. You can do that by running these commands in your PowerShell window, assuming you are already logged on using credentials that have rights to Exchange.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
 http://<FQDN of Exchange 2010 server>/PowerShell/ -Authentication Kerberos

Import-PSSession $Session

Like any other patching for Exchange, remember to apply patches to your server roles as follows:

1. Client Access Servers (all servers in a CAS array consecutively)
2. Hub Transport Servers
3. Unified Messaging Servers
4. Mailbox Servers
5. Edge Transport Servers (which can actually be done whenever, but it makes sense to leave them to last just for consistency.)

With the holiday season and year end approaching, take the time now to update your servers before things get so busy that you either forget, or are rushed to do the job without proper testing, and don’t forget those operating system patches while you are at it!

All about Update Rollup 6 for Exchange Server 2010 Service Pack 1

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators