Search

 
Archive
Links
Categories
Admin Login
Sign In

 

 

 

 

Monday, March 22, 2010

There are times when you need to allow applications to relay through your Exchange 2007 or 2010 Server.  These steps give two options for allowing this.

Allow all computers which successfully authenticate to relay, regardless of the list above

Like its predecessor, Exchange 2007 is configured to accept and relay email from hosts that authenticate by default. Both the "Default" and "Client" receive connectors are configured this way out of the box. Authenticating is the simplest method to submit messages, and preferred in many cases.

The Permissions Group that allows authenticated users to submit and relay is the "ExchangeUsers" group. The permissions that are granted with this permissions group are:

NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Submit}
NT AUTHORITY\Authenticated Users {ms-Exch-Accept-Headers-Routing}
NT AUTHORITY\Authenticated Users {ms-Exch-Bypass-Anti-Spam}
NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Accept-Any-Recipient}

The specific ACL that controls relay is the ms-Exch-SMTP-Accept-Any-Recipient.

Only the list below (specify IP address)

This option is for those who cannot authenticate with Exchange. The most common example of this is an application server that needs to be able to relay messages through Exchange.

First, start with a new custom receive connector. You can think of receive connectors as protocol listeners. The closest equivalent to Exchange 2003 is an SMTP Virtual Server. You must create a new one because you will want to scope the remote IP Address(es) that you will allow.

The next screen you must pay particular attention to is the "Remote Network settings". This is where you will specify the IP ranges of servers that will be allowed to submit mail. You definitely want to restrict this range down as much as you can. In this case, I want my two web servers, 192.168.2.55 & 192.168.2.56 to be allowed to relay.

The next step is to create the connector, and open the properties. Now you have two options, which I will present. The first option will probably be the most common.

Option 1: Make your new scoped connector an Externally Secured connector

This option is the most common option, and preferred in most situations where the application that is submitting will be submitting email to your internal users as well as relaying to the outside world.

Before you can perform this step, it is required that you enable the Exchange Servers permission group. Once in the properties, go to the Permissions Groups tab and select Exchange servers.

Next, continue to the authentication mechanisms page and add the "Externally secured" mechanism. What this means is that you have complete trust that the previously designated IP addresses will be trusted by your organization.

Caveat: If you do not perform these two steps in order, the GUI blocks you from continuing.

Do not use this setting lightly. You will be granting several rights including the ability to send on behalf of users in your organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default "Externally Secured" permissions are as follows:

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

Basically you are telling Exchange to ignore internal security checks because you trust these servers. The nice thing about this option is that it is simple and grants the common rights that most people probably want.

Option 2: Grant the relay permission to Anonymous on your new scoped connector

This option grants the minimum amount of required privileges to the submitting application.

Taking the new scoped connector that you created, you have another option. You can simply grant the ms-Exch-SMTP-Accept-Any-Recipient permission to the anonymous account. Do this by first adding the Anonymous Permissions Group to the connector.

This grants the most common permissions to the anonymous account, but it does not grant the relay permission. This step must be done through the Exchange shell:

Get-ReceiveConnector "CRM Application" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

In addition to being more difficult to complete, this step does not allow the anonymous account to bypass anti-spam, or ResolveP2.

Although it is completely different from the Exchange 2003 way of doing things, hopefully you find the new SMTP permissions model to be sensible.

Source: http://msexchangeteam.com/archive/2006/12/28/432013.aspx

Applies to: Exchange 2007, Exchange 2010, Exchange Server 2007, Exchange Server 2010, Backup Exec, Symantec Backup Exec, Symantec Backup Exec 12.5

Monday, March 22, 2010 11:03:40 PM (Central Standard Time, UTC-06:00) | Comments [0] | Exchange 2007 | Exchange 2010 | Symantec Backup Exec#
Monday, February 22, 2010

I had an issue with a Small Business Server SBS 2003 to SBS 2008 migration where once everything was up and running, I had problems with Outlook 2007 Clients giving certificate errors.  Also, OWA Outlook Web Access would redirect to http://sites/owa.  The problem was the internal and external URL settings on the various transports in Exchange 2007.  This powershell script helped to fix the problem.  Note, some errors occurred for me but I was able to just step through the code and issue the commands to the Exchange Shell manually to get the job finished.  The main problem was the AutoDiscover Internal URI - once that was fixed the rest fell into place.

 

# Script to allow you to set all virtual directories to a common name like mail.company.com

Start-Transcript

# Variables

[string]$UMExtend = "/UnifiedMessaging/Service.asmx"
[string]$OABExtend = "/OAB"
[string]$SCPExtend = "/Autodiscover/Autodiscover.xml"
[string]$EWSExtend = "/EWS/Exchange.asmx"
[string]$ConfirmPrompt = "Set this Value? (Y/N)"
[string]$NoChangeForeground = "white"
[string]$NoChangeBackground = "red"

Write-host "This will allow you to set the virtual directories associated with Autodiscover provided services to the name you provide."
Write-host ""
[string]$base = Read-host "Base name of virtual directory (e.g. mail.company.com)"
write-host ""
# =======================================================
# Validate if a third party trusted certificate is being used
# because BITS won't use untrusted certificates
[string]$set = Read-host "Is the certificate being used an internally generated certificate? (Y/N)"
Write-host ""

if ($set -eq "Y")    {
    [string]$OABprefix = "http://"
}    else    {
    [string]$OABprefix = "https://"
}

# =======================================================
# Build the Autodiscover URL and set the SCP Value

Write-host "Setting Autodiscover Service Connection Point" -foregroundcolor Yellow
write-host ""

$SCPURL = "https://" + $base + $SCPExtend

[array]$SCPCurrent = Get-ClientAccessServer

Foreach ($value in $SCPCurrent) {
    Write-host "Looking at Server: " $value.name
    Write-host "Current SCP value: " $value.AutoDiscoverServiceInternalUri.absoluteuri
    Write-host "New SCP Value:     " $SCPURL
    [string]$set = Read-host $ConfirmPrompt
    write-host ""
    
    if ($set -eq "Y")    {
         Set-ClientAccessServer -id $value.identity -AutoDiscoverServiceInternalUri $SCPURL
    }    else {
        write-host "Autodiscover Service Connection Point internal value NOT changed" -foregroundcolor $NoChangeForeground -backgroundcolor $NoChangeBackground
    }
}

# =======================================================
# Build the EWS URL and set the internal Value

Write-host "Setting Exchange Web Services Virtual Directories" -foregroundcolor Yellow
write-host ""

$EWSURL = "https://" + $base + $EWSExtend

[array]$EWSCurrent = Get-WebServicesVirtualDirectory

Foreach ($value in $EWSCurrent) {
    Write-host "Looking at Server: " $value.server
    Write-host "Current Internal Value: " $value.internalURL
    Write-host "New Internal Value:     " $EWSUrl
    [string]$set = Read-host $ConfirmPrompt
    write-host ""

    if ($set -eq "Y")    {
        Set-WebServicesVirtualDirectory -id $value.identity -InternalURL $EWSURL
     } else {
        write-host "Exchange Web Services Virtual Directory internal value NOT changed" -foregroundcolor $NoChangeForeground -backgroundcolor $NoChangeBackground
     }

    Write-host "Looking at Server: " $value.server
    Write-host "Current External Value: " $value.externalURL
    Write-host "New External Value:     " $EWSUrl
    [string]$set = Read-host $ConfirmPrompt
    write-host ""

    if ($set -eq "Y")    {
        Set-WebServicesVirtualDirectory -id $value.identity -ExternalURL $EWSURL
    } else {
        write-host "Exchange Web Services Virtual Directory external value NOT changed" -foregroundcolor $NoChangeForeground -backgroundcolor $NoChangeBackground
    }
}

# ======================================================
# Build the OAB URL and set the internal Value

Write-host "Setting OAB Virtual Directories" -foregroundcolor Yellow
write-host ""

$OABURL = $OABprefix + $base + $OABExtend

[array]$OABCurrent = Get-OABVirtualDirectory

Foreach ($value in $OABcurrent) {
    Write-host "Looking at Server: " $value.server
    Write-host "Current Internal Value: " $value.internalURL
    Write-host "New Internal Value:     " $OABUrl
    [string]$set = Read-host $ConfirmPrompt
    write-host ""

    if ($set -eq "Y")    {
        Set-OABVirtualDirectory -id $value.identity -InternalURL $OABURL
    } else {
        write-host "OAB Virtual Directory internal value NOT changed" -foregroundcolor $NoChangeForeground -backgroundcolor $NoChangeBackground
    }

    Write-host "Looking at Server: " $value.server
    Write-host "Current External Value: " $value.externalURL
    Write-host "New External Value:     " $OABUrl
    [string]$set = Read-host $ConfirmPrompt
    write-host ""

    if ($set -eq "Y") {
        Set-OABVirtualDirectory -id $value.identity -ExternalURL $OABURL
    } else {
        write-host "OAB Virtual Directory external value NOT changed" -foregroundcolor $NoChangeForeground -backgroundcolor $NoChangeBackground
    }
}

# =======================================================
# Build the UM URL and set the internal Value

Write-host "Setting UM Virtual Directories" -foregroundcolor Yellow
write-host ""

$UMURL = "https://" + $base + $UMExtend

[array]$UMCurrent = Get-UMVirtualDirectory

foreach ($value in $UMCurrent) {
    Write-host "Looking at Server: " $value.server
    Write-host "Current Internal Value: " $value.internalURL
    Write-host "New Internal Value:     " $UMUrl
    [string]$set = Read-host $ConfirmPrompt
    write-host ""

    if ($set -eq "Y") {
        Set-UMVirtualDirectory -id $value.identity -InternalURL $UMURL
    } else {
        write-host "UM Virtual Directory internal value NOT changed" -foregroundcolor $NoChangeForeground -backgroundcolor $NoChangeBackground
    }

    Write-host "Looking at Server: " $value.server
    Write-host "Current External Value: " $value.externalURL
    Write-host "New External Value:     " $UMUrl
    [string]$set = Read-host $ConfirmPrompt
    write-host ""

    if ($set -eq "Y") {
        Set-UMVirtualDirectory -id $value.identity -ExternalURL $UMURL
    } else {
        write-host "UM Virtual Directory external value NOT changed" -foregroundcolor $NoChangeForeground -backgroundcolor $NoChangeBackground
    }
}
Stop-Transcript

 

(http://www.exchangeninjas.com/set-allvdirs)

Monday, February 22, 2010 12:50:27 PM (Central Standard Time, UTC-06:00) | Comments [0] | Exchange 2007 | SBS 2008#
Friday, February 12, 2010

As you probably knew, or do now since you are searching for this information, Exchange 2007 requires a UCC Multi-Domain SSL Certificate to properly function.  Here are some tips for setting it up.

-Pick your favorite vendor to purchase the UCC SSL from and make the purchase

-Generate the request from the Exchange 2007 Server.  To do this, open the Management Shell and issue the New-ExchangeCertificate command.  A great tool is provided here: https://www.digicert.com/easy-csr/exchange2007.htm.  You can use this tool to generate the request and it will save the information to a file in the path you can specify or leave default

   For Example:  Lets say we have an Exchange 2007 Server whos Internet Address is mail.rockabilly.com and its local domain address is exch07.rockabilly.local.  I would also include remote.rockabilly.com, rockaserver.rockabilly.local, autodiscover.rockabilly.com, autodiscover.rockabilly.local in the list of requested names.  Feeding this into the tool yields the following request:  "New-ExchangeCertificate -GenerateRequest -Path c:\mail_rockabilly_com.csr -KeySize 2048 -SubjectName "c=US, s=Utah, l=YourTown, o=RockABillyDoodles, ou=IT, cn=mail.rockabilly.com" -DomainName remote.rockabilly.com, pcrserver.rockabilly.local, autodiscover.rockabilly.com, autodiscover.rockabilly.local -PrivateKeyExportable $True"  Copy and paste this request into your Exchange Server Management Shell and it will spit out the request to c:\mail_rockabilly_com.csr.  Open this in Notepad and copy and paste the request into the request fields at the site where you purchased the SSL cert. 

-Once the request is received by the registering entity, an email will be generated to approve this request.  The email will go to the contacts on the WHOIS record for the domain.  Ensure you have access to those email accounts so you can approve the request.

-Once the request is approved and you are able to download the certificate, the next step is to install it into the Exchange 2007 server.

Friday, February 12, 2010 4:13:21 PM (Central Standard Time, UTC-06:00) | Comments [0] | Exchange 2007 | Exchange 2010#
Thursday, June 18, 2009
To enable protocol logging on Receive Connectors, use the following command:

Set-ReceiveConnector "Connector Name" -ProtocolLoggingLevel verbose

In case you're wondering if there are any choices for the logging level - there aren't. It's either verbose or none.

To enable protocol logging from the Exchange console, go to Server Configuration | Hub Transport | select the Hub Transport server you want to configure | select the Receive Connector -> properties | General tab | change Protcol logging level to Verbose, as shown in the screenshot below.

Screenshot: Enabling SMTP protocol logging on a Receive Connector in Exchange 2007
Figure 1: Enabling SMTP logging on a Receive Connector

Unlike Exchange Server 2003/2000, you have to enable logging separately for Send Connectors (equivalent of SMTP Connectors), using the following command:

Set-SendConnector "Send Connector Name" -ProtocolLoggingLevel verbose

To do this using the Exchange console, go to Organization Configuration | Hub Transport | Send Connectors tab | select the Send Connector -> properties | General tab | change Protocol logging level to verbose.

Besides the visible Receive and Send connectors, an invisible Send Connector lurks under the hood - used to transport messages within the organization, between Hub Transport servers, Edge Transport servers, and Exchange Server 2003/2000 servers. It's the Intra-Organization Send Connector. You won't see it in the console, or in the shell if you use the get-SendConnector command. To configure protocol logging for this Intra-Organization Send Connector:

Set-TransportServer "TRANSPORT SERVER NAME" -IntraOrgConnectorProtocolLoggingLevel verbose


Where do protocol logs reside?
- Unlike Exchange Server 2003/2000, which maintain separate protocol logs for each instance of a SMTP Virtual Server, all Receive Connectors share "SmtpReceive" logs. Similarly, Send Connectors share "SmtpSend" logs.
- Receive Connector logs are located in
\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive
- Send Connector logs are located in
\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpSend

How do you change the path of SMTP logs?


To change the path of SmtpReceive logs:

Set-TransportServer "TRANSPORT SERVER NAME" -ReceiveProtocolLogPath "C:\New SmtpReceive Log File Directory"

To change the path of SmtpSend logs:

Set-TransportServer "TRANSPORT SERVER NAME" -SendProtocolLogPath "C:\New SmtpSend Log File Directory"

If you do decide to change the path, ensure the new directories/folders exist with appropriate permissions, as outlined in "How to Configure Protocol Logging" in the product documentation. In addition to the above, you can also control the maximum log file size, the maximum directory size, and the maximum age of log files. This ensures you don't have to worry about purging the logs manually over time, or scheduling a script to do this periodically.

SMTP logs are an important troubleshooting tool - enabling SMTP logging after the fact isn't any help when troubleshooting SMTP mail flow.

Thursday, June 18, 2009 12:45:20 PM (Central Standard Time, UTC-06:00) | Comments [1] | Exchange 2007 | KnowledgeBaseArticles#
Here are some great notes on setting the content filter parameters in Exchange 2007:

Open the Exchange Management Shell:

# To check the Content Filter configuration, type in:

Get-ContentFilterConfig

# To set the Bypassed Senders (example):

Set-ContentFilterConfig -BypassedSenders donotspamme@calazan.com, jdoe@abc.com

# To set the Bypassed Sender Domains (example):

Set-ContentFilterConfig -BypassedSenderDomains calazan.com, *.xyz.com

Important Note: BypassedSenders and BypassedSenderDomains are multivalued properties. When you use the Set-ContentFilterConfig cmdlet, it will overwrite the values of those properties. If you just need to add more senders or domains, please follow the example below.

# To add Bypassed Senders:

$x = Get-ContentFilterConfig

$x.BypassedSenders += “jsmith@google.com”, “bhope@yahoo.com”

# To remove Bypassed Senders (can only be done one at a time):

$x = Get-ContentFilterConfig

$x.BypassedSenders -= “jsmith@google.com”

# To empty the list:

Set-ContentFilterConfig -BypassedSenders $null


Thursday, June 18, 2009 12:43:13 PM (Central Standard Time, UTC-06:00) | Comments [2] | KnowledgeBaseArticles | Exchange 2007#