Search results for 'app:weblogs' matching tags 'troubleshooting', 'tip', and 'Microsoft Exchange 2007'

Improvements to the Exchange Remote Connectivity Analyzer

Anonymous — Tue, 03 Jul 2012 05:00:00 GMT

The Exchange Remote Connectivity Analyzer (ExRCA) has to be one of the best troubleshooting tools that the Exchange product team has ever produced. It's a one-stop shop that allows you to test remote connectivity to an Exchange organization using Autodiscover, ActiveSync, Outlook Anywhere, Web Services, or inbound/outbound SMTP from a Microsoft hosted cloud application on the Internet. It works with both on-prem and Office 365 Exchange organizations.

Shawn McGrath is the developer in charge of ExRCA development and previewed recent improvements to us at the MVP Summit in February 2012. I'm pleased to say that ExRCA version 1.4 has now been released! The biggest changes are around the CAPTCHA experience, which I've been a vocal about for the past year. Constructive Feedback = Good. J

Here’s a list of the changes in this release:

We are using a new CAPTCHA service provided by an internal team.
The challenge is NOT case sensitive, so it doesn't matter if you type upper or lower case letters. We also note this on the web page.
The CAPTCHA challenges will not include hard to distinguish letters/numbers. For example 2 and Z or O and 0.
If you get the challenge wrong, the password entries will not be removed.
Once you enter a correct response to the challenge, you will be verified for a set amount of time (~30 minutes). This means you will not see additional CAPTCHA challenges until the timeout period expires.
The inbound SMTP test now inserts the IP address of the user performing the test into the test email message. The IP is also inserted into an SMTP Header (X-Originating-IP).
Fixed an issue in the Sender-ID test where certain DNS responses while evaluating the "exists" mechanism were incorrectly being treated as a TempError
The outbound SMTP Sender-ID tests now conform to the RFC specified limit of ten DNS-based mechanisms that can be used during the evaluation of the SPF record.
Fixed an issue where host names with all numbers in the top-level domain were not considered valid input
Fixed user interface issues that can cause the "helper bubble" to stick around when navigating in the wizard
Added a note to the EWS service account access test indicating that the mailbox must be empty
Changed the Windows Mobile Certificate test to warn instead of fail when certificates aren't trusted by Windows Mobile since many other devices also use ActiveSync and may trust the certificate
Changed the Outlook Anywhere mutual authentication test to report a warning instead of an error when the mutual authentication (msstd: string) only matches a Subject Alternative Name on the certificate. Windows Vista SP1 and later can handle this configuration.
The Outlook Anywhere Proxy Ping and HTTP Authentication Method Tests now use the full query string; this is necessary to support certain UAG configurations.
Added additional error mappings for known issues

Shawn also created this fun video to demonstrate the new CAPTCHA experience.

How to fix MSExchangeTransport Event ID 12014 on Edge and Hub Transport servers

Anonymous — Wed, 29 Sep 2010 05:00:00 GMT

By default, Exchange 2007 and 2010 attempt to use Transport Layer Security (TLS) for all SMTP traffic. TLS uses a certificate on the receiving server to encrypt SMTP traffic between SMTP servers, similar to the way a certificate on the CAS server is used to secure OWA traffic. If TLS cannot be negotiated, SMTP will usually fallback to non-encrypted SMTP.

In order for a server to send SMTP email via TLS:

The receiving server must have an Exchange certificate in the computer's local Personal store.
The SMTP service must be assigned to use this certificate.
The FQDN used in the Receive Connector must match either the Common Name or one of the Subject Alternative Names (if they exist) on the SMTP certificate.

If any one of these requirements is not met, you will see the following error in the application log of the Edge Transport server:

Log Name:      Application
Source:        MSExchangeTransport
Date:          9/28/2010 9:35:58 AM
Event ID:      12014
Task Category: TransportService
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      mailgate
Description:
Microsoft Exchange could not find a certificate that contains the domain name mail1.expta.com in the personal store on the local computer. Therefore, it is unable to support the STARTTLS SMTP verb for the connector Default internal receive connector MAILGATE with a FQDN parameter of mail.expta.com. If the connector's FQDN is not specified, the computer's FQDN is used. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for that FQDN. If this certificate exists, run Enable-ExchangeCertificate -Services SMTP to make sure that the Microsoft Exchange Transport service has access to the certificate key.

When you see this error on Edge Transport servers you have to examine the error description to determine where the mismatch occurs. In the example above, the connector in error is the "Default internal receive connector MAILGATE", which is the receive connector that exists on the Edge server itself. If the connector in error is on the "EdgeSync - Inbound to domain" connector, the mismatch is on the Hub Transport server's receive connector.

You can fix this by reconfiguring the offending connector to use the Common Name or Subject Alternative Name used on the Exchange certificate. You can find this value by viewing the certificate from the Certificates MMC, as shown below:

To reconfigure the Edge Server's Receive Connector:

On the Edge server, open the Exchange Management Console.
Navigate to Microsoft Exchange > EdgeTransport.
Click the Receive Connectors tab to view the existing connectors.
Double-click the Default internal receive connector SERVER connector to view its properties.
In the Specify the FQDN this connector will provide in response to HELO or EHLO field, enter the certificate's Common Name (for example, ex1.expta.com) as shown below, and click OK.

To reconfigure the Hub Transport's Receive Connector:

On the CAS, open the Exchange Management Console.
Navigate to Microsoft Exchange > Microsoft Exchange On-Premises > Organization Configuration > Hub Transport.
Click the Send Connectors tab to view the existing Send Connectors.
Double-click the EdgeSync - Inbound to domain connector to view its properties.
In the Specify the FQDN this connector will provide in response to HELO or EHLO field enter the certificate's Common Name (for example, ex1.expta.com) as shown above, and click OK.

Fix for OWA always uses Light Mode for some users

Anonymous — Tue, 17 Aug 2010 05:00:00 GMT

This article explains the difference between OWA Light Mode and Premium Mode and why some users may only see the Light Mode client, even though they haven't selected it at logon.

Exchange 2007 Outlook Web Access and Exchange 2010 Outlook Web App offer two different modes for viewing OWA - Premium Mode, with all the bells and whistles that Internet Explorer can muster, and Light Mode, which provides fewer features and is sometimes faster. You would usually use the Light client if you are on a slow connection or using a computer with unusually strict browser security settings.

If you are using a browser other than Internet Explorer 6 or later for OWA 2007, you can only use the Light client. OWA 2010 supports the full Outlook Web App experience (aka Premium Mode) on Internet Explorer 7 and some other browsers on Windows, Mac, and Linux computers. To check out all the supported browsers and operating systems for OWA 2010, click here.

Here's a comparison between the Outlook Web Access 2007 Light and Premium clients:

And here's a comparison between the Outlook Web App 2010 Light and Premiun clients:

Normally, users will default to use the Premium Mode client if they are using IE6 or better for OWA 2007 or IE7 or better for OWA 2010. However, you may hear complaints from some users that they always get the Light Mode client, regardless of whether they selected to use it or not when they logged in. This happens if the user selected to use "the blind and low vision experience" when logging into OWA for the first time.

To disable this mode and allow IE to use the Premium Mode, have the user login to OWA and open Options in the upper right corner. Then select Accessibility and clear the checkbox for Use the blind and low vision experience, as shown below.

Now have the user sign out of OWA and sign back in. They should be using OWA Premium Mode, providing they are using a supported browser.

Exchange Setup Repeatedly Says 'A Restart from a Previous Installation is Pending'

Anonymous — Tue, 29 Jun 2010 05:00:00 GMT

You may find when installing Exchange 2007 or Exchange 2010 that the server repeatedly reports:

A restart from a previous installation is pending. Please restart the system and rerun setup.

Exchange Setup reads the following registry key to determine whether a system restart is required after installation or removal of a software update such as a security update, critical update, or hotfix.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile

Exchange Setup also checks the following registry key to determine whether a previous software update installation was not completed and the system must be restarted to finish the installation.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

If setup still complains that a restart is needed after you've performed a restart, do the following:

Open RegEdit.
Set the HKLM\SOFTWARE\Microsoft\Updates\UpdateExeVolatile key value to 0 or delete it.
Delete the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations key.
Rerun Setup.

The New Exchange 2007 SP3 Password Reset Tool

Anonymous — Mon, 28 Jun 2010 05:00:00 GMT

Exchange Server 2007 Service Pack 3 includes a handy new web page that allows users to change their password before logging into Outlook Web Access (OWA).

Previously, new users who are required to change their password at next logon or users whose password has expired cannot log on to OWA. They will get the less than helpful error from the OWA, "The user name or password that you entered is not valid. Try entering it again", as shown below:

In order to logon to OWA, the user must logon to the network, enter their old password and the new password. Obviously, this causes problems for remote users whose password has expired or for new users who must change their password before logging in for the first time.

Exchange 2007 SP3 introduces a new SSL web page for these users that allows the user to change their password outside of OWA. The page tells the user, "Your password has expired and you must change it prior to signing in to Microsoft Outlook Web Access."

Once the user changes their password, the page redirects the user back to OWA.

This new functionality is not enabled by default, since some organizations do not allow password changes from outside the internal network. To enable it:

Logon to the CAS with administrator rights
Run Regedit and navigate to HLKM\SYSTEM\CurrentControlSet\services\MSExchange OWA
Create a new DWORD (32-bit) Value called ChangeExpiredPasswordEnabled
Assign the ChangeExpiredPasswordEnabled value: 1
Restart IIS using IISRESET /NOFORCE from the command line

Surprisingly, this functionality does not exist in Exchange Server 2010 (or the SP1 beta). I hope Microsoft decides to implement this when Exchange 2010 SP1 is finally released. It's a pretty handy feature!

How to Use Telnet to Send SMTP Email to Exchange 2007 and 2010

Anonymous — Mon, 29 Mar 2010 05:00:00 GMT

Unlike previous versions of Exchange, Exchange Server 2007 and Exchange 2010 use strict RFC compliance to send and receive SMTP email. This can cause some unexpected behavior if a server or application the sends email to Exchange does not comply with RFC 2822.

Many email administrators know how to use the Telnet client to send SMTP email. In this article I’ll show you how to send RFC compliant email using Telnet. Doing so also allows you to also add X-Headers to your email, which I’ll explain later.

First, you need to have access to the Telnet client. This is already installed as part of the operating system on all Windows platforms prior to Windows Vista or Windows 2008.

To install the Telnet Client for Windows Vista and Windows 7:

Open Control Panel > Programs and Features
Select Turn Windows features on or off
In the list that appears, check the box beside Telnet Client
Click OK

For Windows Server 2008 and Windows Server 2008 R2:

Open Server Manager and select Features
Click Add Features
Check Telnet Client, click Next and Install

You may also want to try PuTTY. PuTTY is a free Telnet/SSH client that has extended features, such as logging and appearance personalization. More importantly, PuTTY allows you to use the backspace key to correct typing mistakes – something the Telnet client won’t do.

So, on with the demo. Let’s start first with an example of the way most people use Telnet to send email. Use your Telnet client to connect to the SMTP server on port 25 and issue the following commands. I’ve color coded what I type in blue and what the server returns in maroon.

telnet exchange.domain.com 25
220 exchange.domain.com Microsoft ESMTP MAIL Service ready at Sun, 28 Mar 2010 08:49:36 -0700
helo domain.com
250 VLHC.scif.com Hello [10.1.117.29]
mail from:user1@domain.com
250 2.1.0 Sender OK
rcpt to:user2@domain.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
Subject:Test email using Telnet
This is a test.
.
250 2.6.0 <9c642f92-e0e3-4b9e-b3d3-21054eed3247@exchange.domain.com> Queued mail for delivery
quit
221 2.0.0 Service closing transmission channel
Connection to host lost.

Assuming that the recipient email address is valid and the configuration on the Exchange server allows the email to be relayed, this results in an email being sent to user2@domain.com. However, you will notice a few peculiar things about the email that was received.

First, the To: field in the email is blank. If you look at the SMTP headers, you will see that the
To: header shows “Undisclosed recipients:;”, as shown below.

The second issue with the email is that the body of the message is blank. It should show “This is a test.”

Here’s how to send that same email using RFC 2822 compliance to have it displayed correctly in Outlook. Use your Telnet client to connect to the SMTP server on port 25 and issue the following commands. This time I've used the color green to indicate the changes.

telnet exchange.domain.com 25
220 exchange.domain.com Microsoft ESMTP MAIL Service ready at Sun, 28 Mar 2010 08:52:17 -0700
helo domain.com
250 VLHC.scif.com Hello [10.1.117.29]
mail from:user1@domain.com
250 2.1.0 Sender OK
rcpt to:user2@domain.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with <CRLF>.<CRLF>
to:user2@domain.com
Subject:Test email #2 using Telnet
<---This is a CRLF
This is a test.
.
250 2.6.0 <10c637ec-f8fb-4753-85c4-76d5c4f76108@exchange.domain.com> Queued mail for delivery
quit
221 2.0.0 Service closing transmission channel
Connection to host lost.

This results in an email where the To: field is displayed correctly in both the SMTP headers and the email itself, and the body of the message is displayed, as shown below.

The difference between the two emails are the “to:user2@domain.com” immediately after the “data” command and before the “Subject:…” command. There must also be a blank line after the
Subject and before the body of message is entered.

Technically, the to: line can be entered as either to:user2@domain.com or to:John Smith <user2@domain.com>. Outlook will attempt to auto-resolve the To: line to the display name stored in Active Directory and will overwrite the display name entered. Keep in mind that the
To: command does not have to match the address used in the RCPT command. If the address entered cannot be resolved, Outlook will display the display name listed on the To: line, or just the email address if none was entered.

If you want to add a custom X-Header, you add it anytime after the DATA command and before the Subject:... command. For example:

data
354 Start mail input; end with <CRLF>.<CRLF>to:user2@domain.comX-My-Test-Header:My Data
Subject:Test email with custom X-Header

This results in the X-My-Test-Header: My Data being added to the SMTP header, as shown below:

X-Headers are often used to add metadata to an email message. Antivirus and anti-spam solutions usually add some form of X-Header to emails to show what type of processing has occurred and possibly what score has been applied to the message.

You can use the X-Headers to create Hub Transport rules that act upon messages in a particular way.

You can also use this method to test that the X-Headers are promoted properly in Exchange. You can read more about named property promotion here.

Fixing Leading and Trailing Whitespace in Exchange Objects

Anonymous — Thu, 25 Mar 2010 05:00:00 GMT

You must remove all the leading and trailing spaces from Exchange 2000/2003 user names, group names, and Public Folder names prior to migrating them to Exchange 2007 or Exchange 2010. Previous versions of Exchange and Outlook would let you create these objects, usually by accident. Exchange 2007 and Exchange 2010 have strict conformance rules that will not allow this, so you'll have to fix it before the objects are migrated.

For example, you may use the Exchange AddReplicaToPFRecursive.ps1 script to add your Exchange 2007 or 2010 servers as replicas to your Public Folders. If the Public Folder contains leading or trailing whitespace you will receive an error in the Exchange Management Shell (EMS):

Set-PublicFolder : The Name property contains leading or trailing whitespace, which must be removed.
At C:\Program Files\Microsoft\Exchange Server\Scripts\AddReplicaToPFRecursive.ps1:147 char:24
+ $_ | Set-PublicFolder <<<< -server $_.OriginatingServer;
WARNING: Object \Information Technology\Website Resources\Software Development has been corrupted and it is in an inconsistent state. The following validation errors have occurred:
WARNING: The Name property contains leading or trailing whitespace, which must be removed.

Use the following PowerShell one-liners to trim the leading and trailing whitespace from Exchange objects in AD:

USER OBJECTS

Single User Object:
Get-Mailbox -Identity USER | Foreach { Set-Mailbox -Identity $_.Identity -DisplayName $_.DisplayName.Trim() }

All User Objects:
Get-Mailbox | Foreach { Set-Mailbox -Identity $_.Identity -DisplayName $_.DisplayName.Trim() }

PUBLIC FOLDERS

Single Public Folder:
Get-PublicFolder -Identity "\Test\SubPath\PublicFolderName" | Set-PublicFolder -Identity $_.Identity -Name $_.Name.Trim()

All Public Folders:
Get-PublicFolder -Identity "\" -Recurse -ResultSize Unlimited | Foreach { Set-PublicFolder -Identity $_.Identity -Name $_.Name.Trim() }

DISTRIBUTION GROUPS

Single Distribution Group:
Get-DistributionGroup -Identity GroupName | Set-DistributionGroup -Identity $_.Identity -DisplayName $_.DisplayName.Trim()

All Distribution Groups:
Get-DistributionGroup | Foreach { Set-DistributionGroup -Identity $_.Identity -DisplayName $_.DisplayName.Trim() }

Note: These commands all give a warning if the object is not changed, which you can safely ignore:

WARNING: The command completed successfully but no settings of '\xxxxx\xxxxxx\xxxxx\IT Department Calendar' have been modified.

Another configuration that can cause errors is when a Public Folder alias contains spaces. Use the following one-liners to remove spaces from Public Folder aliases:

Remove Spaces From a Single Public Folder Alias:
Get-PublicFolder -Identity "\Test\SubPath\PublicFolderName" | Get-MailPublicFolder |
Where {$_.Alias -like "* *"} | ForEach-Object { Set-MailPublicFolder $_.identity -Alias:($_.Alias -Replace " ","") }

Remove Spaces From All Public Folder Aliases:
Get-PublicFolder -Identity "\" -Recurse -ResultSize Unlimited | Get-MailPublicFolder |
Where {$_.Alias -like "* *"} | ForEach-Object { Set-MailPublicFolder $_.identity -Alias:($_.Alias -Replace " ","") }

These PowerShell one-liners demonstrate how easily some tasks can be performed. This might take days to do using the GUI with thousands of objects.