Saturday, November 14, 2009

Outlook 2007 Best Practices

The Outlook 2007 Best Practices article is intended to provide users of Microsoft Office Outlook 2007 guidance on how to best use the product.

Overview
The purpose of this paper is to provide customers of Microsoft Office Outlook 2007 guidance on how to best use the product. Created by the product team who created Outlook 2007, this guide represents our advice on how to get the most out of Outlook 2007. By no means comprehensive, it covers just a few core scenarios.

Why an Outlook "best practices" document?
We wrote this paper for the best possible reason: Our customers asked. We designed Outlook 2007 to be used by a wide audience with many work needs and styles. Although there's no one "right way," there are a few ways of working in the program that we know to be easier than others. We hope that by being aware of the best practices, you will have the best experience possible using Outlook.

Management Shell Quick Reference for Exchange 2010

A very usefull document for every Exchange Administrator: Exchange Management Shell Quick Reference for Exchange 2010.

Brief Description
This download contains a quick reference sheet that can be used to access frequently used Exchange Management Shell cmdlets and syntax in Microsoft Exchange Server 2010.

Overview
The Exchange Management Shell provides a powerful command-line interface for Microsoft Exchange Server 2010 that enables automation of administrative tasks. This quick reference guide provides a list of frequently used cmdlets, important conventions, and useful tips. The information is presented by feature area, such as recipient, transport, and database administration. This quick reference guide applies to Exchange 2010.

Tuesday, November 10, 2009

Exchange Server 2010 is now available worldwide!

Finally Exchange 2010 is available globally as of today! :)

Check the post on the Exchange Team Blog: http://msexchangeteam.com/archive/2009/11/09/453096.aspx

Thursday, October 22, 2009

Preventing Forwarding NDRs Storms

One recurring problem I have is users setting up forwarding rules to e-mail addresses that don’t exist (why do they never check it?!).
Anyway, when they receive an e-mail, that e-mail gets forwarded automatically to that non-existing address which generates a Non-Delivery Receipt (NDR). When the user receives the NDR, it gets forwarded to the same address, which creates another NDR, and so on, and so on, and so on, going into an infinite loop. This is known as an NDR Storm.


What is an NDR?
An NDR is a message that a mail server sends to notify the sender when a problem occurs with the delivery of the e-mail. For example if the server resources are unavailable, the recipient's mailbox is full (and it doesn’t accepts more e-mails), the recipient is unknown, etc.

In my case, the users always type the recipient's address incorrectly... So, the receiving server sends a message that looks similar to this:

-------------------------------------------
From: mailer-daemon
Sent: Wednesday, October 21, 2009 11:06:38 PM
To: Nuno Mota
Subject: There was an error sending your mail ...
Auto forwarded by a Rule

I'm afraid I had problems forwarding your message. Full details follow:

Subject: 'just testing the forwarding rule'
Date: 'Wed, 21 Oct 2009 23:06:38 +0100 (BST)'

1 error(s):

SMTP Server rejected recipient (Error following RCPT command). It responded as follows: [550 unknown user xxxx.xxxx]

I have also attached the mail's original headers. Sorry it didn't work out.



First, I created a transport rule to BCC every e-mail sent to outside users and that contained the text "FW: There was an error sending your mail", "FW: Mail delivery failed", "FW: failure notice" in the subject to our Quarantine mailbox. This way, every time I got loads of NDRs I just had to go to the user’s mailbox and disable the rule (if that was the case of course).

This was working fine, except for the times this happened during the night. When I got to work, sometimes I had users with 2GB of NDRs in just a few hours...

So, another approach was necessary. That’s when I thought of writing a script to analyze the transport logs every hour (changed it to 15 minutes for now) and, in case an NDR Storm was detected, create a Transport Rule to block those e-mails from going out.

And here is the result:

# Script: PreventNDRsStorm.ps1
# Purpose: Analyze the Transport Logs for possible NDR storms and stop them
# Author: Nuno Mota
# Date: Oct 2009


# Get the date and time for 15 minutes ago. This will be the starting point to search the transport logs

$strDate = Get-Date
$strStartFrom = $strDate - "00:15:00"

# Get all the users who forwarded non-delivered messages to external users in the last 15 minutes. Group them so we can analyze the total number of e-mails sent
$strNDRs = Get-TransportServer Get-MessageTrackingLog -ResultSize Unlimited -Start $strStartFrom -EventId SEND ? {($_.MessageSubject -match "FW: There was an error sending your mail") -or ($_.MessageSubject -match "FW: Mail delivery failed") -or ($_.MessageSubject -match "FW: failure notice")} ¦ Group Sender

# For each sender, check if they sent more than 25 e-mails
ForEach ($strNDR in $strNDRs)
{
# If they sent more than 25 e-mails (in the last 15 minutes) create the transport rule and send an e-mail to the administrator
If (($strNDR.Count -ge 25) -and ($strNDR.Name -match "@letsexchange.com "))
{
# Create the Transport Rule
# For every e-mail sent by that user

$condition1 = Get-TransportRulePredicate From
$condition1.Addresses = @(Get-Mailbox $strNDR.Name)

# only when the e-mail is going Outside the organization
$condition2 = Get-TransportRulePredicate SentToScope
$condition2.Scope = @("NotInOrganization")

# and only when the subject contains any of these phrases
$condition3 = Get-TransportRulePredicate SubjectContains
$condition3.Words = @("FW: There was an error sending your mail", "FW: Mail delivery failed", "FW: failure notice")

# Redirect the FW e-mail to the Quarantine NDRs mailbox
$action = Get-TransportRuleAction RedirectMessage
$action.Addresses = @(Get-Mailbox Quarantine)

# Get the user's alias from the e-mail address to create the transport rule with it
$strName = [regex]::split($strNDR.Name, "@")[0]

# Create the Transport Rule itself
New-TransportRule -Name "Prevent NDRs Storm - $strName" -Comments "Prevent NDRs Storm by blocking specific sender after searching the Transport Logs for more than 25 e-mails forwarded by one single user" -Conditions @($condition1, $condition2, $condition3) -Actions @($action) -Enabled $True -Priority 0


# Send the E-mail to the administrator
$body = ""
$body += "`n**********************************"
$body += "`n* *"
$body += "`n* WARNING: NDR Storm Prevented *"
$body += "`n* *"
$body += "`n**********************************"
$body += "`n`nTransport Rule Created for ", $strNDR.Name
$body += "`n`nFW e-mails: ", $strNDR.Count

$FromAddress = "administrator@arts.ac.uk"
$ToAddress = "nuno.mota@letsexchange.com"
$MessageSubject = "NDRs Storm!"

$SendingServer = "HTCAS2"

$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $ToAddress, $MessageSubject, $body

$SMTPClient = New-Object System.Net.Mail.SMTPClient $SendingServer
$SMTPClient.Send($SMTPMessage)
}
}



(My apologies for the bad layout of the code...)

What it does is analyze the transport logs every 15 minutes and if it finds a user that forwarded 25 or more NDRs, creates a transport just for that user rule and block those e-mails from going out by redirecting them to the Quarantine mailbox.
Then, I receive an e-mail saying a transport rule was created and all I have to do is go to the user’s mailbox, disable the rule and delete the transport rule after a few minutes.


Job done! Any other ideas?

Wednesday, September 30, 2009

Outlook Anywhere Repeatedly Prompting for Credentials

Two days ago it came to my attention that some Outlook Anywhere (OA) users were getting prompted for their credentials constantly. Talked to some of them and said that a workaround was to go to the connection settings and unselect the “Only connect to proxy servers that have this principal name in their certificate” box and restart Outlook:




Another problem was that after a while (no one could tell me exactly how much time that was) that box got selected again and the same problem happened.

After some investigation regarding Outlook Anywhere and the Autodiscover service I found what the problem was.
First, some information:


The Autodiscover Service and Outlook Providers
The Autodiscover service makes it easier to configure Outlook 2007. Earlier versions of Exchange and Outlook required you to configure all user profiles manually to access Exchange. The Autodiscover service uses a user's e-mail address or domain account to automatically configure a user's profile. By using this information the Autodiscover service provides the following information to the client:
· The user’s display name;
· Separate connection settings for internal and external connectivity;
· The location of the user’s Mailbox server;
· The URLs for various Outlook features that govern such functionality as free/busy information, Unified Messaging, and the offline address book;
· Outlook Anywhere server settings.

When a user's Exchange information is changed, Outlook automatically reconfigures the user's profile by using the Autodiscover service. For example, if a user's mailbox is moved or the client is unable to connect to the user's mailbox or to available Exchange features, Outlook will contact the Autodiscover service and automatically update the user's profile to have the information that is required to connect to the mailbox and Exchange features.

To allow Autodiscover to function completely there is an important component in Exchange 2007 named Providers. Providers are components that are specifically related to the type of client that is trying to connect and be configured. When the Client Access Server role is installed, by default three providers are created: EXCH, EXPR and WEB.

When creating or refreshing an Outlook 2007 profile a request is placed to the Autodiscover service; the service determines which provider needs to handle the request. The XML request contains the necessary information for this to happen, such as the SMTP address and which client (MAPI client or Outlook Anywhere) made the request so the Autodiscover service can easily identify the provider the request needs to be forwarded to.



By default three Outlook Providers are used to configure settings individually for Exchange RPC protocol or internal clients (EXCH), Outlook Anywhere (EXPR) and WEB.
- The EXCH setting references the Exchange RPC protocol that is used internally. This setting includes port settings and the internal URLs for the Exchange services that you have enabled.
- The EXPR setting references the Exchange HTTP protocol that is used by Outlook Anywhere. This setting includes the external URLs for the Exchange services that you have enabled, which are used by clients that access Exchange from the Internet.
- The WEB setting contains the best URL for Outlook Web Access for the user to use. This setting is not in use.


Resolution
Without going into much detail on how this works, here’s how this was causing the problems:

When issuing the command Get-OutlookProvider EXPR FL I was getting the following information (just displaying the important parts):

CertPrincipalName:
Server:
TTL: 1



Our ExternalHostname, for Outlook Web Access, is owa.letsexchange.com (fake name of course) but the certificate for that website was issued to letsexchange.com

When the CertPrincipalName parameter for OutlookProvider is not configured, Outlook uses the ExternalHostname parameter for OA to populate the server name listed after “msstd:” in the “Only connect to proxy servers that have this principal name in their certificate” profile setting, so it was as msstd:owa.letsexchange.com, which did not match the “Issued To” Name on the certificate, and users were being prompted for credential repeatedly! When users unselected this box, the principal name on the certificate didn’t get checked so Outlook was working fine. Once this box got ticked, it would fail.

So I had two choices, find away to prevent that box from being ticked or to put the correct information on it. At his time, I realized that OA with Autodiscover wasn’t working externally because of this! Users had to manually configure OA, but once it was working, Outlook would eventually download the configuration for it and mess it up.

So, the option was to make it right. How to do this? Issue the correct certificate or simply change the CertPrincipalName to provide the correct information to Outlook. I opted for the second option by issuing the following command:

Set-OutlookProvider EXPR –CertPrincipalName “msstd:letsexchange.com”

Now, Outlook receives the correct information for OA and OA with the Autodiscover service is working perfectly!

Tuesday, August 18, 2009

Exchange Server 2010 RC available

This morning I received an e-mail from Microsoft saying that "Microsoft Exchange Server 2010 Release Candidate is now available"! :)

Went to the website and couldn't find anything... :-S

Well, will try again later with a little more time.

Friday, June 19, 2009

Exchange 2010: Hub Transport Role Installation Fails

Many people, including me the first time, have been reported that the Hub Transport Role installation fails while starting the MSexchangeTransport service and that the below error is reported in setup window when you try to install Exchange 2010 Beta.

Error
The execution of: “$error.Clear(); if ($RoleStartTransportService) { start-SetupService -ServiceName MSExchangeTransport }”, generated the following error: “Service ‘MSExchangeTransport’ failed to reach status ‘Running’ on this server.”


Aparently, this normally happens when you disable IPv6 in Local Area Connection, which was what I did.


Resolutions
· Enable IPv6 in Local Area Connection.

· To completely disable IPv6 on a Windows Server 2008-based computer, follow these steps and add a registry key:
1. Open Registry Editor
2. Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
3. In the details pane, click New, and then click DWORD (32-bit) Value
4. Type DisabledComponents, and then press ENTER
5. Double-click DisabledComponents, and then type 0xffffffff in Hexadecimal or 4294967295 in Decimal

· Apply the “Microsoft Fix It” available in KB952842 to disable IPv6.


Note: If the setup still fails, remove IPv6 entry from the hosts file available at %systemroot%\system32\drivers\etc