Transport Rules

All posts tagged Transport Rules

Transport rules kopieëren

In Exchange 2010 zijn de transport rules flink uitgebreid, aangezien de configuratie van de Hub servers in de AD wordt opgeslagen worden de transport rules hier ook in opgeslagen. Dit heeft als voordeel dat de transport rules gebruikt kunnen worden door de diverse Hub servers in een zelfde Exchange organisatie.

Met een Edge server wordt dit natuurlijk wat lastiger aangezien deze geen lid is van de AD maar gebruik maakt van lokale ADLDS waarmee replicatie niet mogelijk is. Nou is het wanneer je één Edge server hebt nog wel te doen om de transport rules van een Hub opnieuw te configureren op een Edge. Maar stel je voor dat je meerdere Edge servers hebt en je wil dat de configuratie van de transport rules op deze servers identiek is.
In dat geval kun je gebruik gaan maken van de Export-TransportRuleCollection en Import-TransportRuleCollection commando’s. Voor beide commando’s geldt dat deze zowel op een Hub als Edge transport server uitgevoerd kunnen worden.

Met onderstaande commando zorgen we ervoor dat er een export wordt gemaakt van de transport rules in de directory export.

$file = Export-TransportRuleCollection
Set-Content -Path “C:\Export\TransportRules.xml” -Value $file.FileData -Encoding Byte

Vervolgens dient het xml bestand gekopieerd te worden naar de overige Edge servers en dient het import commando gedraaid te worden.

[Byte[]]$Data = Get-Content -Path “C:\Import\TransportRules.xml” -Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data

Dit zorgt ervoor dat de transport rules welke zich in het bestand transportrules.xml bevinden geïmporteerd worden op de server.

Wanneer er nu veel wijzigingen plaatsvinden in de transport rules dan kun je middels een script automatiseren dat de transport rules worden ge-exporteerd en geïmporteerd worden.

Onderstaand een voorbeeld script om transport rules te exporteren. Dit bestaat uit een batch bestand en een Powershell bestand, het batch bestand wordt gebruikt door de scheduled task welke bijvoorbeeld eenmaal per uur een export maakt van de transport rules. Wanneer de opdracht is uitgevoerd wordt een entry gemaakt in het application event log. Een opmerking hierbij is dat ik er vanuit ben gegaan dat de export directory een shared folder is waar de gebruikeraccount die wordt gebruikt om het script uit te voeren rechten op heeft:

exporttransportrules.cmd
PowerShell.exe -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1′; Connect-ExchangeServer -auto; C:\Export\exporttransportrules.ps1″

exporttransportrules.ps1
$file = Export-TransportRuleCollection
Set-Content -Path “C:\Export\TransportRules.xml” -Value $file.FileData -Encoding Byte
$evt=new-object System.Diagnostics.EventLog(“Application”)
$evt.Source=”Export transport rules”
$infoevent=[System.Diagnostics.EventLogEntryType]::Information
$evt.WriteEntry(“Transport rules have been exported”,$infoevent,70)
 

OK nu we het export gedeelte hebben nu het import script:

importtransportrules.cmd
PowerShell.exe -command “. ‘C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1′; Connect-ExchangeServer -auto; C:\Import\importtransportrules.ps1″

importtransportrules.ps1
[Byte[]]$Data = Get-Content -Path “\\sourceserver\export\TransportRules.xml” -Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data
$evt=new-object System.Diagnostics.EventLog(“Application”)
$evt.Source=”Import transport rules”
$infoevent=[System.Diagnostics.EventLogEntryType]::Information
$evt.WriteEntry(“Transport rules have been imported”,$infoevent,70)

Het import script is nagenoeg hetzelfde, alleen export-transportrulecollection is vervangen door import-transportrulecollection en het pad waarvan geïmporteerd moet worden staat verwezen naar de “bron”.

Maar wat gebeurd er nu in een co-existence omgeving wanneer je zowel in Exchange 2007 als in Exchange 2010 transport rules hebt aangemaakt. Zoals eerder beschreven worden transport rules opgeslagen in de Active Directory voor Hub servers, echter voor Exchange 2010 is dit in op een andere plek als in Exchange 2007. Tijdens de installatie van Exchange 2010 worden de transport rules van Exchange 2007 geconverteerd zodat deze gebruikt kunnen worden door Exchange 2010. Wanneer de installatie dus voltooid is hebben zowel de Exchange 2007 als Exchange 2010 servers dezelfde transport rules. Echter na de installatie vindt deze conversie niet meer plaats wat inhoudt is dat wanneer een transport rule in Exchange 2007 gewijzigd wordt deze ook in Exchange 2010 gewijzigd zal moeten worden.
Om alleen de Exchange 2007 transport rules te exporteren op een Exchange 2010 Hub server dient onderstaand commando uitgevoerd te worden:
$ file = Export-TransportRuleCollection -ExportLegacyRules
Set-Content -Path “C:\Export\LegacyRules.xml” -Value $file.FileData -Encoding Byte
 
Mocht je naar aanleiding van bovenstaande meer informatie willen neem dan eens een kijkje op onderstaande sites:

Technet Export-TransportRuleCollection open
Technet Import-TransportRuleCollection open

Berichten naar specifieke domeinen blokkeren

Had je in Exchange 2007 voor sommige dingen echt een Edge server nodig , in Exchange 2010 RC zit het gewoon op de HUB server. Een van deze dingen is mail blokkeren naar specifieke domeinen. In Exchange 2007 kon dit alleen op de Edge server ingesteld worden, in Exchange 2010 RC kan dit nu ook op de HUB server.

Block mail to specific domain

Zoals bovenstaand te zien is kan er bijvoorbeeld geconfigureerd worden dat interne gebruikers niet mogen mailen naar het gmail.com domein. Naast deze optie zijn er vele andere mogelijkheden met transport rules in Exchange 2010 RC bijgekomen. Binnenkort zal ik hier een aparte tutorial over publiceren welke de opties bespreekt en voorbeelden geeft wat je met die opties kunt bereiken.

In de transport rules van Exchange 2007 kun je gebruik maken van regular expressions. Zo kun je bijvoorbeeld bepaalde woorden blokkeren als je dit wil. Wat er echter vaak gebeurd is dat er dan ook woorden worden geblokkeerd die je niet wil tegenhouden. Dit komt omdat dan het woord wat in de filter is gedefinieerd ook voorkomt in het betreffende woord. Om dit te voorkomen kun je gebruik maken van onderstaande parameters:

parameter omschrijving
\S \S kan gebruikt worden om elke enkel karakter te vervangen wat niet een spatie is.
\s \s kan gebruikt worden om een enkele spatie te vervangen.
\D \D kan gebruikt worden om op elk niet numeriek karakter te zoeken.
\d \d kan gebruikt worden om te zoeken op een enkel getal.
\w \w kan gebruikt worden om een reeks karakters te doorzoeken op een enkel Unicode karakter welke in de categorie letter of cijfer voorkomt.
| Het pijp ( | ) karakter kan gebruikt worden om een OR functie te maken.
* De wildcard ( * ) karakter matched nul of meer exemplaren van het vorige karakter.
( ) Door karakters tussen () te plaatsen worden ze gegroepeerd hiermee is het mogelijk om bijvoorbeeld te zoeken op een string waar de letters yz in voorkomen door de volgende expression te gebruiken(yz)*.
\\ De 2 backslashes kunnen gebruikt worden om een bepaald karakter te negeren, bijvoorbeeld \\d om een string te zoeken welke \d bevat.
^ Door het ^ karakter te gebruiken wordt aangegeven waarmee de karakter reeks moet beginnen.
$ Het $ karakter kan gebruikt worden om een karakter reeks te zoeken welke eindigt met een bepaalde reeks karakters

Zoals je ziet zijn er vele mogelijkheden die je toe kunt passen. En af en toe zal het dus best puzzelen zijn hoe je een goede filter kunt bouwen.

Meer info kun je vinden in onderstaand Technet artikel

Regular Expressions in Transport Rules

Blokkeer backscatter mails met Exchange 2007

Zo het is alweer een tijdje geleden dat ik een tutorial heb gepubliceerd. Dit keer gaat de tutorial over het blokkeren van backscatter mails. Deze tutorial legt stap voor stap uit hoe je ze kunt voorkomen m.b.v. Transport rules.  We doen dit met 2 regels, de eerste regel voegt aan elk uitgaand mailtje een extra tag toe in de header. En de tweede regel controleert elke mail op de tag indien dit mailtje een NDR is.

open

Backscatters het komt steeds meer voor NDR’s die worden afgeleverd bij bedrijven waarbij na onderzoek de hele mail niet is verstuurd. Er zijn een aantal mogelijkheden om dit te voorkomen waaronder SPF records.

Toch ben ik zelf eens gaan kijken of er geen andere mogelijkheden zijn om deze vervelende mails te voorkomen. Uiteindelijk kwam ik op de Transport Rules van Exchange 2007 uit.

In deze tutorial leg ik uit hoe je dit precies kunt configureren en dus van de backscatters af kunt komen.

Als eerst maken we een transport rule aan die een tag toevoegt aan de header van de e-mail. Hiermee kunnen we namelijk later herkennen of de mail wel is verstuurd door onze server.

Dit kunnen we doen door in de EMC via de Organizational Configuration naar de Hub Transport server te gaan en vervolgens op de tab Transport Rules te klikken.

Vervolgens selecteren we in het rechter menu dat we een nieuwe Transport Rule aan willen maken

In dit geval geven we deze de naam Add tag to header maar dit kan natuurlijk ook een andere naam zijn als je wil. Wanneer je de naam hebt ingevuld druk je op next

Op de volgende pagina stellen we in op welke mails we deze transport rule willen toepassen

Hier stellen we in dat we deze regel willen toepassen op elke mail die via de Hub Transport server naar buiten wordt verstuurd. Wanneer dit is gebeurd drukken we op next

We gaan nu de actie instellen die we willen uitvoeren. Zoals al eerder gemeld willen we iets aan de header van de mail toevoegen. We selecteren daarom ook de optie set header with value. De regel zal nu in het onderste gedeelte van het scherm te zien zijn. Het enige wat we nog op moeten geven is de waarden die toegevoegd moeten worden

Eerst stellen we de tag zelf in

We geven de tag de naam anti-spf dit is een naam die je zelf kunt verzinnen, onthoud deze wel goed want deze hebben we later nog nodig. Vervolgens stellen we de waarde in die we aan de tag willen geven. Dit kun je het beste een random waarde laten zijn om het moeilijker te maken dat deze gekraakt wordt. Het is echter een statische waarde dus het is niet geheel onmogelijk dat dit gebeurd.

Wanneer de beide waarden hebben ingesteld drukken we op next

We krijgen nu nog een kort overzicht te zien en drukken weer op next waarna de regel wordt aangemaakt. Wanneer de regel succesvol is aangemaakt zul je onderstaande scherm te zien krijgen

Elke mail die nu naar buiten verstuurd zal worden zal nu in de header een tag hebben anti-spf: 7uTreth2

De volgende stap is het aanmaken van de Transport Rule die de NDR mail controleerd op deze tag.

We selecteren daarom in het rechter menu de optie om een nieuwe Transport Rule aan te maken

We geven deze wederom een logische naam, in dit geval NDR Check, en klikken op next

De volgende stap is het instellen van de voorwaarden waaraan de mail moet voldoen voordat deze Transport Rule wordt toegepast. In dit geval controleren we:

  • of de mail gericht is aan mensen intern (sent to users inside your organization)
  • of het onderwerp de tekst Returned mail bevat specifieke woorden (Subject field contains specific words)

Vergeet niet wanneer je de waarde Returned mail handmatig in te vullen wanneer je de optie Subject field contains hebt geselecteerd.

De volgende stap is het instellen van de actie die uitgevoerd moet worden

In dit geval stellen we in dat

  • er een entry in het event log wordt weggeschreven met de waarde NDR Check
  • het betreffende mailtje niet wordt afgeleverd

Mocht je alleen de drop the message actie voldoende vinden dan kun je uiteraard ook beslissen om alleen deze te selecteren. Wanneer je tevreden bent over de instellingen druk je op next

De laatste stap is het instellen van de exceptions, zouden we dit niet doen dan zouden alle mailtjes die gericht zijn aan een interne gebruiker met het onderwerp Returned mail gedropt worden. Dit willen we echter niet, we willen namelijk dat geldige NDR’s wel afgeleverd worden.

Door de body van de mail te controleren op de waarde anti-spf: 7uTreth2 kunnen we voorkomen dat legitieme NDR’s worden geblokkeerd.

Wanneer dit is ingesteld druk je weer op next en vervolgens wordt de regel aangemaakt. Indien de regel succesvol is aangemaakt zul je onderstaand scherm te zien krijgen

Ik geef toe het is even werk maar het bespaart je mogelijk wel een hoop telefoontjes van ongeruste gebruikers.

In Exchange 2003 konden we met delivery rectrictions voorkomen dat mail naar een bepaald domein kon worden verzonden. In Exchange 2007 kun je dit regelen met transport rules deze kun je op de Hub Transport server aanmaken. Wanneer de wizard is opgestart en je de naam hebt gedefinieerd kom je hij het scherm om de conditions in te stellen, deze stellen we als volgt in:

  • from users inside the organization
  • when a message header contains specific words, hier stellen we in dat we willen controleren op de parameter to met de waarde blockeddomain.com

Vervolgens stellen we de action in, we kunnen bijvoorbeeld instellen dat de afzender een bericht terugkrijgt waarin te lezen is dat deze niet mag verzenden naar dit domain vanwege security instellingen

  • send bounce message to sender with enhanced status code

De laatste stap is eventueel exceptions instellen, dit kan bijvoorbeeld gebruikt worden als je een bepaald e-mail adres in een domain wat je blokkeert wel wil toestaan.

Een nieuwe feature in Exchange 2007 is message classification hiermee kan men een bepaalde classificatie geven aan een mail en bijvoorbeeld een transport rule aan koppelen.

De functionaliteit kan alleen gebruikt worden in combinatie met Outlook 2007 clients en Outlook Web Access. Standaard bevat Exchange 2007 5 message classifications:

  • A/C Privileged
  • Attachment Removed
  • Company Confidential
  • Company Internal
  • Partner Mail

De huidige message classifications kun je achterhalen door het volgende commando uit te voeren in Powershell:

get-messageclassifications

Dit geeft onderstaand resultaat:

Het is ook mogelijk om zelf nieuwe message classifications aan te maken dit kan met het commando new-messageclassification met daarbij de nodige parameters.

new-messageclassification -name Marketing  -DisplayName “Marketing Confidential” -SenderDescription “This classification must be used by the marketing department”

In bovenstaand voorbeeld wordt een nieuwe message classification aangemaakt met de naam Marketing. Vervolgens stellen we de naam die in de client wordt weergeven met de parameter displayname in, als Marketing Confidential als laatste parameter gebruiker we senderdescription om de tekst in te stellen die in de client wordt weergeven wanneer deze is geselecteerd.

Deze classificatie zal echter gebruikt worden voor alle talen inclusief Nederlands. Natuurlijk zou je de senderdescription in het Nederlands op kunnen geven, maar het is ook mogelijk meerdere talen te hangen waarbij de client zelf kan kijken of de taal beschikbaar is en zo ja dan zal deze automatisch gekozen worden.

new-messageclassification -Identity Marketing -Locale nl-NL -DisplayName “Marketing NL” -SenderDescription “Deze classificatie mag alleen gebruikt worden door de marketing afdeling”

Met bovenstaande parameter maken we een Nederlandse message classification aan voor de eerder aangemaakte message classification Marketing. Dat deze alleen voor Nederlands is geven we aan met de parameter -Locale gevolgd door de taal. Met de parameter identity selecteren we de Marketing message classification. De overige parameters displayname en senderdescription hebben dezelfde functie als bij het aanmaken van een nieuwe message classification.

Standaard kunnen alle gebruikers gebruik maken van de classificatie. Dit kan echter beperkt worden:

get-messageclassification Marketing -IncludeLocales |Remove-AdPermission -User AU -AccessRights GenericRead -InheritanceType None

Met bovenstaande opdracht zorgen we ervoor dat de rechten die de authenticated users hebben op de Marketing message classification verwijderd worden.

get-messageclassification Marketing  -IncludeLocales | Add-AdPermission -User “domainname\Marketing” -AccessRights GenericRead -InheritanceType None

Vervolgens zorgen we met bovenstaande opdracht ervoor dat gebruikers die lid zijn van de groep Marketing lees rechten krijgen op de message classification.

Er zitten echter wat haken en ogen aan de rechten, zo zal het in OWA goed werken maar zal het in Outlook 2007 niet geheel mogelijk zijn de gebruiker geen gebruik te laten maken van de message classification. Een gebruiker met Outlook 2007 kan namelijk de Classifications.xml aanpasssen waardoor het nog steeds mogelijk is gebruik te maken van de message classification.

Maar goed, het is in ieder geval een manier om het zo moeilijk mogelijk te maken voor de gebruiker om de message classification te gebruiken.

In het voorgaande stuk hebben we het al gehad over message classifcation en Outlook 2007. In OWA hoef je niks te configureren om het te gebruiken, bij Outlook 2007 echter wel.

Het configureren van Outlook 2007 bestaat uit 2 stappen:

  • aanmaken registry keys
  • aanmaken classifications.xml

Voordat men gebruik kan maken van het classifications.xml bestand dient met eerst de onderstaande registersleutels aan te maken:

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Policy]

“AdminClassificactionPath”=”c:\\Program Files\\Office\\Classifications.xml”

“EnableClassifications”=dword:00000001

“TrustClassifications”=dword:00000001

Alle parameters spreken voor zich, behalve de laatste. De parameter TrustClassifications dient alleen de waarde 00000001 te hebben als de gebruiker op een Exchange 2007 is geplaatst.

De laatste stap is het aanmaken van het bestand classifications.xml. Dit laatste dient uitgevoerd te worden op de Exchange 2007 server. Microsoft heeft hiervoor al een standaard script in de scripts directory van Exchange 2007 geplaatst genaamd Export-OutlookClassification.ps1

./Export-OutlookClassifications.ps1 > c:\export\classifications.xml

Zorg er wel voor dat de map waar je naar exporteerd bestaat anders krijg je een foutmelding. Bovenstaand commando zal alle message classifications exporten naar een xml bestand.

Het is echter ook mogelijk om bijvoorbeeld alleen de Nederlandse taal te exporteren:

./Export-OutlookClassifications.ps1 -Locale “nl” >Classifications.xml

Zoals je ziet wordt nu nl gebruikt i.p.v. nl-NL beide zijn eigenlijk hetzelfde, voor een volledig overzicht zie de deze pagina.

Message classifications kunnen ook gebruikt worden in transport rules. Zo kun je controleren of een bericht gemarkeerd is met een bepaalde message classification  om vervolgens te voorkomen dat de betreffende e-mail naar buiten wordt verzonden.

Naast deze mogelijkheid kan een transport rule ook aan de hand van de voorwaarden waaraan de mail voldoet een classificatie aan de mail toekennen.

Een nieuwe feature in Exchange 2007 zijn Transport rules deze kun je op twee manieren aanmaken, via de Exchange Management Console of via de Exchange Management Shell.

De transport rules worden aangemaakt op de Hub transport server. De transport rules worden als volgt uitgevoerd:

Wanneer je de Exchange Management Shell gebruikt om een rule aan te maken zul je de betreffende stappen ook tegenkomen.

Naast de parameters kan een prioriteit aan elke Transport Rule gegeven worden. De prioriteit loopt vanaf 0, deze rule heeft ook de hoogste prioriteit. Wanneer een bericht aan diverse rules voldoet worden alle rules toegepast op het betreffende bericht, er wordt dan wel rekening gehouden met de prioriteiten die aan de rules zijn toegewezen. Heb je eenmaal een rule aangemaakt dan kun je deze gemakkelijk aanpassen.

Als eerst gaan we de Transport Rule aanmaken via de Exchange Management Console. Start hiervoor de Exchange Management Console op, vervolgens klik je op Organizational Configuration, Hub Transport en kiezen de tab Transport Rules

Nu klikken we ergens in het witte gedeelte van het scherm en kiezen we voor New Transport Rule, dit kan ook via de Hub Transport taken aan de rechterkant van het scherm. Je krijgt dan het volgende scherm te zien

Eigenlijk spreken alle velden voor zich, Name is de naam die je aan de Transport Rule wil geven, Description kun je gebruiken om een korte omschrijving te geven van de rule. Het vinkje Enable Rule staat standaard aan, indien je een rule niet direct wil gebruiken dien je dit dus uit te zetten, klik vervolgens op next

Als eerst stellen we de Conditions in, dit zijn de eigenschappen waaraan een mailtje moet voldoen. Dit kan bijvoorbeeld zijn: mail naar alle externe gebruikers

De volgende stap is de Rules instellen die worden toegepast op de mail. In dit geval willen we tekst toevoegen aan het mail met de disclaimer tekst.

Zoals te zien is in de flowchart kunnen er ook nog Exceptions ingesteld worden. In het geval van de disclaimer is dit niet van toepassing dus klikken we op next

Voordat de Transport Rule wordt aangemaakt krijg je eerst nog een overzicht met welke parameters de rule wordt aangemaakt. Klik op New om de regel aan te maken.

Als je bovenstaand scherm te zien krijgt is de regel succesvol aangemaakt en wordt deze toegepast op alle mails naar externe gebruikers.

Nu we een Transport Rule hebben aangemaakt via de Exchange Management Console is het tijd om er één aan te maken via Powershell.

We gaan een rule aanmaken die mails blokkeert met het woord Finance in het onderwerp of in de body van de e-mail behalve wanneer deze afkomstig is van gebruiker Klaas Vaak.

Normaliter kun je direct de parameters in het Powershell commando opgeven, met een Transport Rule gaat dit anders. Eerst stellen we de waarden voor de conditions, rules en exceptions in en gebruiken deze vervolgens in het Powershell commando.

Onderstaand het script wat de regel aanmaakt:

$Condition = Get-TransportRulePredicate SubjectOrBodyContains

$Condition.Words = @(“Finance”)

$Exception = Get-TransportRulePredicate From

$Exception.Addresses = @((Get-Mailbox “Klaas.Vaak”))

$Action = Get-TransportRuleAction RejectMessage

$Action.RejectReason = “E-mail messages sent from departments except the Finance department are prohibited.”

New-TransportRule -name “Block e-mail messages with the word Finance” -Condition @($Condition) -Exception @($Exception) -Action @($Action)

Eigenlijk is het net als de wizard in logische stappen te verdelen.

Met $Condition geven we aan dat we een conditie in gaan stellen waaraan de mail moet voldoen. Dit kun je doen met het commando Get-TransportRulePredicate gevolgd door een parameter, in dit geval SubjectOrBodyContains.

Vervolgens stellen we een waarde in voor de conditie, dit gebeurd met $Condition.Words. Hiermee geven we aan dat er gezocht moet worden naar het woord wat opgegeven is achter het = teken.

De volgende stap is de exception opgeven, dit kan door de parameter $Exception en $Exception.Addresses op te geven. Hiermee stellen we met het commando Get-TransportRulePredicate From moeten gaan zoeken in het from veld naar de waarde die is ingesteld bij $Exception.Addresses.

De laatste parameter die opgegeven moet worden is de actie die uitgevoerd moet worden indien een mail aan de voorwaarden voldoet. Dit gebeurd met de parameters $Action en $Action.RejectReason, in dit geval wordt een bericht teruggestuurd naar de afzender met daarin de tekst E-mail messages sent from departments except the Finance department are prohibited.

Nu we alle parameters hebben gedefineerd kunnen we de regel dan ook echt aan gaan maken, dit gebeurd met het commando New-TransportRule. Dit heeft als extra parameter name meegekregen waarmee we de naam van de regel definieren. Indien we niet willen dat een regel direct actief is dienen we de parameter Enabled $false op te geven. De nieuwe rule zal de laagste prioriteit worden gegeven, dit kun je aanpassen door de parameter Priority mee te geven met daarbij uiteraard een getal vanaf 0.

Ik heb zelf het script even opgeslagen als een Powershell-script zodat ik met 1 druk op de knop het script uitvoer, onderstaande is het resultaat:

Onderstaand nog wat handige pagina’s op Technet welke alle parameters bespreken die mogelijk zijn bij de commando’s.

New-TransportRule open

Get-TransportRulePredicate open