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

The Exchange Team first indicated it was coming back in July 2011. We’ve been anxiously awaiting it ever since, and it has finally arrived. Microsoft’s free PST Capture Tool is available for download now.

This tool is designed to hunt down PSTs on your network and provide administrators with a management console which will enable them to either migrate the content to Exchange 2010 on premise, or to Office 365. It uses a client-server approach, requiring a management console to be installed on a server, and agents to be deployed to all systems which you want to scan for PSTs.

To use the tool you must first install the PST Capture Console onto a workstation or server with Outlook 2010 (64 bit) installed. During the install you specify the service account to use, and the port the service will bind to if you don’t want to use the default 6674. Then you install the PST Capture Agent on each computer that you want to search for PSTs. During the install of the agent you specify the FQDN of the Capture Console, and the port if you changed it from the default.

You’ll also need a service account that has been assigned  permissions based on the import scenario you want to implement.

Running import operations can be bandwidth intensive. The agent will copy the PST files to the server running the management console. Then the management console server will either copy the data to a CAS server which will then copy it to a mailbox server, or if the destination is in Office 365, the management console will copy the data directly to Office 365. If you were keeping count, that means a PST might transit the network anywhere from two to four times, depending upon the source of the PST (local hard drive or network share) and the destination. It’s recommended that the management console server be local to the CAS server as well, and in the case of Office 365 customers, close to the Internet egress point.

With the release of the PST Capture Tool, admins now have a free tool to help finally eradicate PST files. Good hunting!

Rejoice, for the PST Capture Tool Has Been Launched!

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

Email is one of the most important communications tools for businesses. When it stops working, people start to get nervous.

While there are many things that a user can do to mess up their email, many of these problems can be resolved with a restart of the software or the computer.

However when the old standby of restarting doesn’t work, it is time for the email administrator to start looking into the issue a bit more deeply.

Here are some of the more common errors found in Outlook 2007 along with some of the ways you can make things right again:

1. Error message that reads: “Cannot open your default e-mail folders. The information store could not be opened.”

This issue can be fixed by first locating Outlook.exe that can be found here: C:\Program Files\Microsoft Office\Office12.

Next, right click Outlook.exe and then click on Properties.

On the Compatibility tab, clear the check box that reads ‘Run this program in compatibility mode’. Then click Ok and restart Outlook.

2. Error message that reads: “Your Microsoft Exchange Server is unavailable.”

This error is a bit trickier to resolve only because there can be many different causes.

No data connection – test your SMTP connection using telnet. If you are unsure how to do this, Microsoft has provided a guide on their TechNet site that walks you through this process: http://technet.microsoft.com/en-us/library/bb123686.aspx.

Office Outlook files are locked – there are times when .ost and .pst files are accidentally, or purposefully, set to read only. Check the permissions of these two files by navigating to:

C:\Users\<username>\AppData\Local\Microsoft\Outlook\ for .pst files and C:\Program Files\Microsoft Office\Office12\ for .ost files. Make sure that neither is set to read only.

Third party applications are interfering with Outlook – many programs, including anti-malware solutions, can interfere with Outlook connecting to the Exchange Server. To check to see if this is the cause, start Outlook in safe mode.

Outlook files are corrupted – this can happen after an upgrade is applied to Outlook. If any of the .dat files listed below are present they should be deleted or renamed.

• Extend.dat – Located in C:\Documents and Settings\<username>\Local Settings\Application Data\Microsoft\Outlook\
• Frmcache.dat – Located in C:\Documents and Settings\<username>\Application Data\Microsoft\Forms\
• Views.dat – Located in C:\Documents and Settings\<username>\Application Data\Microsoft\Outlook\
• Outcmd.dat – Located in C:\Documents and Settings\<username>\Application Data\Microsoft\Outlook\

All the files, with the exception of Outcmd.dat will be re-created. The Outcmd.dat file saves customized toolbar settings so if it is removed these settings will have to be re-applied.

3. Office Outlook will not open personal folders or personal folders do not show up in Outlook.

Personal folders are often the root of many problems related to Outlook. Microsoft has published the Inbox Repair tool, Scanpst.exe, that can be used to scan .pst and .ost files for errors in the file structure. If this is not intact, it will reset the file structure and rebuild the headers.

This tool will only work on the files that reside on your computer’s hard drive, not the files on the Microsoft Exchange Server.

This will also help to resolve the error message: “Cannot open your default e-mail folder. The file c:\users\owner\documents\software info\outlook.pst is not a personal folders file”.

4. Error messages that read either: “The action cannot be completed. The connection to the Microsoft Exchange Server is unavailable. Your network adapter does not have a default gateway” or “Your Microsoft Exchange Server is unavailable”.

This error occurs when Outlook is unsure of the default gateway address. The former is the error message that shows when the Outlook profile is configured automatically and the latter appears when the profile is manually configured. Both have the same fix.

To repair this you will need to edit the registry so clicking on Start and then Run is necessary. Then, enter regedit in the Open box and click OK.

Next, navigate to the registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC. On the Edit menu, point to New, and then click DWORD Value.  Type DefConnectOpts, and then press ENTER. Now, right-click DefConnectOpts, and then click Modify. In the Value data box, type 0, and then click OK.

5. None of the authentication methods supported by this client are supported by your server.

This happens to people when they use their computer in multiple locations. For example, a laptop is taken home and connected to the home network or perhaps a computer is taken on the road. Basically, it comes from authentication rules for the SMTP server.

When this error occurs go to the Account Settings tab and click on Change then More Settings. Now select the Outgoing Server tab.

The option that reads: “My outgoing server requires authentication” and the one that reads: “Log on to incoming mail server before sending mail” should both be looked at. If there is a check in the option box remove it.

5 Common Outlook Errors and How to Fix Them

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

Google recently hung a ‘going out of business’ sign on its Message Continuity service for users of Microsoft Exchange. Google will continue to provide the service to its users until their contracts run out, but after that, they’re on their own.

Since the service was launched a little over a year ago, “hundreds” of businesses have subscribed to the offering, which uses Google’s cloud to provide email continuity when a Microsoft Exchange environment is interrupted for any reason.

Hundreds of users, though, can’t compete with the “millions” of businesses that have moved their entire email operation to Google Apps, so Searchzilla has decided to scrap its continuity product for Exchange  and concentrate all its resources on its application suite.

Current users of the continuity product were “encouraged to consider using Google Apps as their primary messaging and collaboration platform” in a company blog written by Vice President of Product Management Dave Girouard.

The brusque departure by Google from the Exchange disaster recovery scene contrasts sharply with how it entered it:

“Google Message Continuity advances our commitment to providing rapidly deployed, cost-effective email management solutions for organizations of all sizes,” Enterprise Product Manager Matthew O’Connor wrote when the continuity product was announced.

Looking back on the announcement, it appears that Google’s “commitment” to the Exchange market was as solid as an adolescent’s commitment to the latest fad.

That’s not to say that Google’s intentions in offering an Exchange product weren’t clear from the start for careful readers of the company’s pronouncements. “Additionally, for organizations interested in eventually moving to Google Apps, Google Message Continuity can provide a smooth bridge to the cloud,” O’Connor slyly observed in his blog item.

O’Connor’s colleague, Rajen Sheth, the group product manager for Google Apps had a similar pitch at the time:

“Google Message Continuity can also help organizations transition to Google Apps down the road,” he wrote. “Since Microsoft Exchange and Gmail are always in sync with one another, there’s no need to migrate email data when eventually deploying Google Apps.”

Little did those who signed on for Google’s continuity solution realize when they did so that if they didn’t “transition” to Google Apps fast enough to suit the Ferret King, they’d be left looking for another business interruption solution within a year’s time.

Google has been criticized in the past for its flighty attitude toward product development. Some detractors maintain that Google often enters markets to be disruptive, not competitive. Like a sea gull boss, it will undercut competitors in a market and when things don’t work, abandon that market, leaving customers who had faith in the Google brand to clean up the mess.

That kind of product management may work with consumers, but it leaves something to be desired in the business world. Google’s competitor in the enterprise market, Microsoft, knows that. While the Redmond crew have suffered a few slings and arrows for sticking with products too long, their commitment to legacy products has been an important, if sometimes overlooked, part of their success in the business market.

Google’s forsaking of Message Continuity brings to mind some remarks by Microsoft Senior Director of Online Services Tom Rizzo in his famous “Google Graveyard Spooks Customers” blog written on Halloween last year:

“Google releases experimental products and tracks adoption to determine whether to continue providing them,” he wrote. “Its products are like spaghetti, Google throws them up against the wall to see if they stick.”

“The burials of de-supported products are more examples of what is convenient for Google and not good for business,” he added.

Google deserts Exchange users by killing Message Continuity

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

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

You’ve probably seen this before. A user opens a help desk ticket because every time they try to send an email to someone, it bounces. That someone could be a co-worker using the same email system, or it could be a customer on an external email system – it doesn’t matter. When the user replies to an email sent from the other person, the reply is delivered flawlessly. But when the user tries to create a new email, it bounces.

You try to send an email to the remote person and it is delivered correctly. You use message tracking to try to run down the problem with the email, and you might not even find it (if you are searching on the recipient address that is…which is a hint).  It’s not until you have the users actually showing you what they are doing that you realize they have a bad address in their nickname cache.

The nickname cache, which provides Outlook’s handy auto-completion when you start to type a name or an email address into the TO: or CC: or BCC: boxes in a new email, is used both to perform automatic name checking and to perform auto-completion. It is also lets you start to type “Cas…” into the TO: box and pulls up casper.manes@example.com so you don’t have to type out the complete email address. The problem comes up when a recipient’s address is wrong, or changes, and your client holds old or bad information.

To fix this, you can remove entries one at a time, or you can purge the cache completely. If you have recently changed your internal addressing standard, or migrated to a new system, I tend to just purge the whole thing so folks have to go to the GAL for fresh information. They will rebuild their cache soon enough, but if it is just a one or two addressee issue, removing individual entrees is easy enough.

To remove a single entry:

1. Start typing the email address, until autocomplete provides choices, like shown below.
   
2. Click the X to the right of the name to delete it from the cache.

To completely remove the cache:

1. Click File, Options
2. Select the Mail tab
3. Scroll down to “Send messages” and click the “Empty Auto-Complete List” button.
   

Alternatively, you can launch Outlook from the Run dialog using
Outlook.exe /CleanAutoCompleteCache

Protip: using that cmd line in a login script is a convenient way to clear all users’ caches after a migration.

Removing bad entries will force the user to go to the GAL, or use a personal contact, or just type the email address in longhand, which will update the nickname cache with the proper email address, and that means a problem solved.

Troubleshooting Outlook Auto-complete

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