Exchange Queue & A: Get the Right Message
This month, our regular Exchange Queue & A columnist is joined by a guest contributor to resolve your most vexing Exchange issues.
Henrik Walther
With guest contributor Georg Hinterhofer
Message Tracking
Q. Can you share a hint or two on how you do message tracking? We find the GUI to be of limited use. We’re seeking advice on how to get the required information out of the message-tracking logs.
A: Using Windows PowerShell for message tracking is the preferable approach. It gives you more control over the query parameters and is much faster. A typical one-liner would be:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM"
This would get you all message-tracking records from all transport servers in your environment that have a sending address of test@contoso.com, starting March 18, 2012, at 9 a.m. If you want to export the results to one of your users or customers, pipe the results into the Export-CSVcmdlet:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | Export-CSV –Path c:\temp\messagetracking.csv
Want to dig into the results for troubleshooting? Add the format-listcmdlet to the command:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | fl
For ease of use and to spare a lot of typing, it’s a good idea to write your own small Windows PowerShell function. This allows for quick and effective searching. This example will search logs from all Hub Transport Servers, accept –sender as a parameter and search the last 24 hours worth of data:
functionmt {param ($sender) $SDate = (get-date).adddays(-1) get-transportserver | get-messagetrackinglog -sender $sender -start $SDate }
Feel free to adapt this function to suit your needs. You can also put this piece of code in the $profile .ps1 file so it gets loaded on startup. From then on, you would only need to type:
mt –sender test@contoso.com
Use Updates for Rollups
Q. We’ve heard we can use the Updates folder on the Exchange 2010 installation source media to install rollups during the installation. Is this accurate?
A. Yes, that’s accurate—at least partially. You can use the Updates directory to install a matching rollup during a fresh Exchange 2010 installation, and cut down the required installation time. Just drop the .msp file into the respective directory, as shown in Figure 1.
.jpg "Adding the .msp into the Updates directory lets you install a matching rollup")
Figure 1 Adding the .msp into the Updates directory lets you install a matching rollup.
Do not attempt this for an upgrade installation, such as released to manufacturing to the second service pack, or the first service pack to the second service pack. This won’t work and will fail on installation. Upgrades need to be done sequentially and you can’t combine them in that manner. There’s more information on the TechNet Library page, “Install the Latest Update Rollup for Exchange 2010.”
SP1 or SP2?
Q. We’ve upgraded our Exchange 2010 Edge Servers to the second service pack. The installation completed without an error. However, when looking at the build numbers with Get-ExchangeServer, they still show as 14.1.xx, aka SP1. What went wrong here?
A. This is a little misleading, but actually expected behavior. Once an Edge subscription is in place, Microsoft doesn’t update build numbers as part of the regular EdgeSync process. If you ever need to redo the entire subscription (for example, if your certificate used for EdgeSync expires), you’ll see the build numbers will update as well.
Permissions Delays
Q. When I’m trying to grant full mailbox permissions to a mailbox in Exchange 2010, the list of mailboxes takes a long time to populate (anywhere from several minutes up to hours). Is there anything that can be done about that?
A. This is a common question. The reason for the “Select accounts” window populating so slowly is improper LDAP querying. You’re fetching all mailboxes, and applying the filter afterward. If you were searching for a mailbox named “Fred,” for example, you would first get a list of all security principals. Then you would check afterward to see if one of those is Fred’s. This process is painfully slow, especially in large user-count installations.
Luckily enough, Security Enhancements for Microsoft Exchange, or Exchange(SE), decided to fix this issue in the latest and greatest rollup for Exchange 2010 SP2, namely Rollup 1. The direct link to the fix is here.
Integrated Authentication
Q. We’re trying to enable Windows Integrated Authentication for Exchange Outlook Web App (OWA) to get a decent single sign-on experience for our internal, domain-joined clients. Clients are accessing a Network Load Balanced (NLB) URL called https://mail.contoso.com.
We disabled First Boot Agent and enabled Windows Integrated Authentication on the OWA virtual directories. However, when trying to access https://mail.contoso.com/owa, we’re still getting prompted for credentials. When we access the OWA pages by directly entering a Client Access Service (CAS) URL, such as https://cas1.contoso.com/owa or https://cas2.contoso.com/owa, we’re logged on with no prompts. To make it even weirder, if we type the resolved IP of mail.contoso.com, in our case https://10.1.1.150/owa, we’re also logged on with no authentication. Can you help?
A. After working my way up and down through Netmon and Fiddler traces, I finally noticed a change in authentication methods used (you can see these in Fiddler) when I switched from https://10.1.1.150/owa (working, not prompting) to https://mail.contoso.com/owa (prompting).
It turns out that while accessing the resolved IP, we were using Windows NT LAN Manager to authenticate against OWA. When switching to the NLB Fully Qualified Domain Name, we started to use Kerberos to go against the CAS.
A little more digging and clever use of setspn.exe –l revealed that someone had added a Service Principal Name (SPN) entry called http/mail.contoso.com to a totally unrelated computer account. This in turn made client computers go for a Kerberos ticket (because a corresponding entry was found in Active Directory) and then present the ticket to the CAS box. The CAS box obviously had no idea what to do with a Kerberos ticket issued to some completely different box, so it threw a repeated authentication prompt.
Once the bogus SPN entry was removed, Windows Integrated Authentication started to work instantly against the NLB URL and the authentication prompt was gone.
Disclaimer Discord
Q. We’re trying to create a transport rule to add a disclaimer to all outgoing mail. During testing, we discovered the Transport boxes seem to ignore the rule. It didn’t add the desired disclaimers, even after rebooting all the Hub boxes to make sure they actually loaded the rule. However, the same rule is working like a charm in our test environment. Do you have any ideas?
A. The actual rule to perform this function looks like what is shown in Figure 2.
.jpg "This rule was intended to add a disclaimer at the end of outgoing messages")
Figure 2 This rule was intended to add a disclaimer at the end of outgoing messages.
After checking the usual suspects like replication, transport service not aware of any change and so on, everything looked proper. Then we checked ExTRA tracing to capture an .etl of the rules engine while processing outgoing e-mails.
The .etl revealed that the transport service was fully aware of the new transport rule, but for whatever reason didn’t recognize outgoing mails as “outgoing.” For some reason, they were treated as internal.
Further tracing revealed the rules engine considered the “Default Remote Domain” entry in the remote domains as internal. Therefore, it didn’t apply the disclaimer rule.
While looking into the issue, I noticed it says IsInternal:$true for the Default Remote Domain. This tells Exchange to treat all mail going to an address space of * as internal—and therefore not apply the disclaimer. We changed it back to the default setting of false. Now the disclaimers are successfully applied.
.jpg "Henrik Walther")
.jpg "Georg Hinterhofer")
Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 16 years of experience in the IT business. He works as a Technology Architect for a Microsoft Gold Certified Partner in Denmark, and as a technical writer for Biblioso Corp. (a U.S.-based company that specializes in managed documentation and localization services). He’s also a contracted vendor working on various product teams (including the Exchange and Lync teams) at Microsoft.
Georg Hinterhofer is a Microsoft Certified Master for Exchange 2010. He works as a senior premier field engineer, focusing on solely on Microsoft Exchange. He is based in Austria, near Vienna.