E-maili aadresside eemaldamine Exchange serveris

Meiliaadresside lisamine on tavaliselt lihtne. Kui seda on vaja paljudele, siis muudame meiliaadreside poliitikat; kui seda on vaja üksikutele, siis lihtsalt lisame.

Eemaldamisega on lugu natuke keerulisem.  Kõigepealt tuleb üles leida adressaadid, kellel on sobiv aadress.  Üldiselt sobib selleks käsk Get-Recipient, aga teeme seda lihtsuse huvides ainult postkastidega:

$EmailFilter = "*@minu.ee"
$kastid = Get-Mailbox -ResultSize Unlimited |
  Where-Object EmailAddresses –Like $emailFilter

Kui adressaadid leitud, siis tuleb üles leida ka konkreetne eemaldamist vajav aadress.  Seda peamiselt seetõttu, et olemasolevate aadresside loendist ei saa eemaldada aadressi mustri järgi, vaid tuleb esitada täisaadress:

$kastid | Foreach-Object {
  foreach ($address in $_.emailaddresses) {
    if ($address -like $EmailFilter) {
      New-Object PSObject -Property @{Name=$_.name; Alias=$_.alias ; SmtpAddress=$address}
    }
  }
}

Tulemuseks kuvatakse hetkel meile kõik leitud meiliaadressid koos postkasti nimega, mille küljes see aadress on.  Nii et nüüd jääb üle asendada kuvamine kustutamisega.  Siin saab ära kasutada Exchange serveri üldist lähenemist: kui atribuudil võib olla mitu väärtust, siis saame olemasolevate väärtuste hulgas teha muutusi (lisada, eemaldada, asendada)

      Set-Mailbox -Identity $_.id -EmailAddresses @{remove=$address}

Ülaltoodud näide töötab Exchange 2010..2016 peal.  Exchange 2007-l ei olnud veel seda mainitud üldist lähenemist loodud, seega peab seal tegema natuke teistmoodi:

      $NewAddresses = $_.emailaddresses - $address
      Set-Mailbox -Identity $_.id -EmailAddresses $NewAddresses

Kui nüüd peaks vajadus tekkima eemaldada aadresse gruppide, kontaktide või muude adressaatide küljest, siis tuleb lihtsalt asendada adressaatide leidmise ja muutmise käsud.  Muu loogika peaks samaks jääma.

Powershell ja käsurea argumendid

Aeg-ajalt on vaja mõnele PowerShelli käsule või skriptile kombineerida käsurea argumentide komplekt.  Võtame näiteks käsu Send-MailMessage:

#requires –Version 2.0
Send-MailMessage -To "meelis@koolitus.ee" -Subject "Powershell saadab meili" -Priority Low –DeliveryNotificationOption Never

Käsurida on küllalt pikk ja siia peaks teatud tingimustel lisama veel hulga argumente.  Seda on lihtne teha luues muutuja, mille sisuks saab käsurea argumentide komplekt.  Näiteks:

#requires –Version 2.0

$mailFrom = "keegi@mees.ee"
$mailSettings = @{
    Subject = "Tähtis teade";
    From = $mailFrom;
    SmtpServer = "mail.mees.ee";
    Encoding = [System.Text.Encoding]::UTF8;
    To = "teine@mees.ee";
    UseSSL = $false
}

Send-MailMessage @mailSettings

Nii on juba mõnevõrra parem.  Käsk ise on lühem ja loetavam ning lisaks saab boonusena käsurea argumentide komplekti käigult muuta (või uusi argumente lisada):

$mailBody = "This is e-mail sent by Powershell"
$mailSettings.To = $userMail
$mailSettings.Add("Body",$mailBody)
if ((get-date).year -eq 2012) {
    $mailSettings.Add("DeliveryNotificationOption", [System.Net.Mail.DeliveryNotificationOptions]::OnSuccess)
}

Send-MailMessage @mailSettings

Nii saab näiteks kogu meilisaatmise panna tsüklisse, mille tulemusel tekib järjekordne masspostituse mootor. Järgneva näite jaoks eeldame, et meil on failis mailusers.csv inimesed, kellele tahame meili saata, nii et iga inimese kohta on olemas tema nimi (veerg Name) ja e-maili aadress (veerg Mail):

$users = import-csv .\mailusers.csv
foreach ($user in $users) {
    $mailSettings.Body = ("Kallis {0}, `n Meil on Sulle superpakkumine" –f $user.Name)
    $mailSettings.To = $user.Mail
    Send-MailMessage @mailSettings
}

Positiivne on see, et sama meetodit saab kasutada kõigi Powershelli käskude ja isekirjutatud skriptide korral:

function minu ($a, $b) {
  $a
  $b
}

$argList = @{
  a = "üks";
  b = 2
}

minu @argList

Õnnetuseks ei saa sama meetodit kasutada muude programmide väljakutsumise juures.  Seal aitab välja vana hea Start-Process:

#requires –Version 2.0
$argList = "www.ee", "-n 3"
$argList += "-l 100"
Start-Process "ping" -ArgumentList $argList -Wait

Exchange ja Mac meiliklient

Probleem, mis on tõenäoliselt teada kõikidele Mac’i kasutajatele, kelle postkast on Exchange 2010 serveris ja kes püüavad saata kirju piisavalt suurte manustega (~10 MB või suuremad).  Isegi nii tuntud, et levivad legendid selle kohta, et antud koosluse puhul ei saagi nii suuri manuseid saata.

Probleem ise avaldub selliselt, et kui Mac-i meilikliendist püüda saata meili, mille maht (koos manustega) ületab 10 MB, siis kirja serverisse postitamise asemel saab meiliklient veateate.  Probleem esineb nende meiliklientidega, mis suhtlevad Exchange serveriga üle EWS (Exchange Web Services) teenuse. Tegelikult peaks sama probleem esinema ka telefonidel ja muudel sarnastel seadmetel.

Lahendus on tegelikult väga lihtne ja töötab enam-vähem sarnaselt Exchange 2013/2010 peal.

Exchange Serveris kus töötab CAS roll, on EWS-i kaustas (2010 jaoks vaikimisi c:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews) fail WEB.CONFIG .  Selles tuleb teha mõned muudatused:

  1. leida üles element
    <requestLimits maxAllowedContentLength="13600000" />
    

    ja muuta number nii suureks, kui on maksimaalne lubatud kirja suurus.  Ülaltoodud number on baitides ning vaikeväärtus on ~10 MB

  2. leida üles element
    <binding name="EWSHttpsBinding">
        <httpsTransport maxReceivedMessageSize="13600000" …>
    

    ning muuta ka siin number piisavalt suureks.  Ka see number on baitides ning vaikimisi väärtus on ~10 MB.  Võimalik, et seda numbrit polegi vaja muuta.  Exchange 2013 puhul võib seda atribuuti esineda mitu korda.

  3. Exchange 2010 puhul leia üles element
    <httpRuntime maxRequestLength="2097151" />
    

    ning veenduda, et ülaltoodud number on piisavalt suur.  See number on kilobaitides (KB).

Sama liigutus tuleb teha kõikides CAS rolli serverites.

Täpsemalt saab lugeda Microsofti veebist.

Exchange 2007 puhul on asi keerulisem. Nimelt töötab Exchange 2007 ka Windows Server 2003 peal ja seal on IIS-i häälestus osaliselt metabaasis. Seetõttu pole kahte esimest parameetrit failis WEB.CONFIG . Loodetavasti leian ma mingi aja jooksul üles, et kus ja mis nimega need IIS6-s on …

Exchange Server ja e-mail Address Policy

E-mail Address Policy on väga pikka aega olnud viis, kuidas adressaatidele (sealhulgas postkastid) automaatselt e-maili aadresse genereerida.  Ning Exchange Server 2007 tõi siia ühe olulise muudatuse.  Nimelt on alates Exchange 2007-st muutunud poliitika rakendamise loogika.  Enam ei rakendata seda taustal ja mõne aja pärast, vaid muudatused toimuvad kohe.

Kuid tuleb välja, et päris nii see ka ei ole.  Exchange dokumentatsioon väidab, et poliitika rakendatakse kahel juhul:

Esimese juhuga on asi lihtne.  Poliitika rakendub siis, kui seda rakendatakse.  Teise juhuga on asi keerulisem.  Poliitika rakendub kohe, kui adressaati muudetakse Exchange haldusvahenditega.  Ent kui tegemist on kasutajakonto või grupiga, mida sageli muudetakse hoopis Active Directory (AD) haldusvahenditega.  Ja sellisel juhul aadressipoliitika ei rakendu.

Toome lihtsa näite:  ettevõttel on kasutajad/postkastid mitmes linnas laiali ning e-maili aadressid kajastavad linna, kus kasutaja paikneb.  Kui nüüd kasutaja kolib ühest linnast teise, siis aadressi muutumiseks tuleb muuta kasutaja objekti AD-s.  Ja kui seda tehakse näiteks Active Directory Users and Computers konsooliga, siis e-maili aadressid ei muutu.  Kui sama muudatus teha Exchange Management Console’i kaudu, siis muudetakse ära ka e-maili aadress.  Ja seda ka sel juhul, kui Exchange haldusvahendiga muudeti mõnd muud atribuuti, kui seda mis aadressi muudatuse tingib.  Kõik sama kehtib ka skriptitavate liideste kohta.

Ülaltoodud jutus on üks erand.  Nimelt on võimalik luua aadressipoliitika, mis kontrollib kasutaja atribuuti Description.  Nimetatud atribuuti ei suuda Exchange käsk Get-User kuvada ning käsk Set-User muuta.  Sellest tulenevalt ei rakenda selle atribuudi muutmine ka automaatselt e-maili aadressipoliitikat.  Mis veel halvem, ka muude atribuutide muutmine (Set-User abil) ei käivita aadresspoliitika rakendamist.  Ainuke viis selliseid aadressipoliitikaid rakendada on Update-EmailAddressPolicy.

Sama probleem on tegelikult ka Exchange aadressiraamatutega.  Nende puhul tuleb lihtsalt kasutada teist käsku (Update-AddressList).

Ülaltoodud jutust tasub teha järgmised järeldused:

  1. Adressaatide atribuute tuleb reeglina muuta kasutades Exchange haldusvahendeid;
  2. Kui on võimalik situatsioon, et muudatusi sooritatakse muude vahenditega, siis tasuks ajastatud toimingutesse lisada üks skript, mis iga aadresspoliitika (või aadressraamatu) peal käivitaks käsu Update-EmailAddressPolicy (või Update-AddressList);
  3. Aadressipoliitikas tasub vältida atribuudi Description kasutamist.

Eemaldatud funktsionaalsuse lehel on sellest õnneks isegi juttu, et Recipient Update Service on pärast Exchange 2003 eemaldatud ning nimetatud funktsionaalsuse täielikus jätkamiseks on vaja kasutada ajastatud toimingute abi.  Kahjuks aga ei mainita, et mis tingimustel ajastatud toiminguid vaja on.

Siia jutu sisse poetatud lingid viitavad Exchange 2013 dokumentatsioonile, ent sealtsamast saab kiiresti kätte ka Exchange 2010 dokumentatsiooni. Ja kui 2010 lingid on juba käes, siis saab neid ise muuta nii, et nad näitaksid Exchange 2007 dokumentatsioonile (vihje: v=exch.80).

Exchange 2010 ja signatuurid

Olen pikka aega tegelenud e-maili süsteemidega nng seoses sellega kokku puutunud ka soovidega panna automaatselt kirjadele külge ühiselt kujundatud signatuur.  Seda kõike on lihtne teha e-maili klientprogrammis, ent klientprogrammi on vaja häälestada ning seda tuleb teha igas arvutis, kus e-maile kirjutatakse.  Seetõttu tekib automaatselt tahtmine, et miks ei võiks signatuure kirjadele lisada hoopis server.

Exchange 2003 ajal (ja varem) tuli selleks kasutada kolmanda partei tooteid, Exchange ise ei pakkunud mingeid võimalusi.  Exchange 2007 oli juba palju parem.  Transport reeglitega oli võimalik muuhulgas lisada tingimustele vastavaltele kirjadele automaatselt kirja algusesse või lõppu fikseeritud teksti.  Tekst võib olla HTML ja seega ilusti kujundatud, ent piiranguks jääb siiski see, et kõik ühe reegliga lisatud tekstid on ühesugused.

Exchange 2010 on lisanud sellele funktsionaalsusele võimaluse oma lisatavas tekstis kasutada Active Directory-st kasutajakonto väljade väärtusi.  Selle tulemuseks on võimalus luua personaliseeritud signatuure.  Ehk siis signatuur võib sisaldada inimese nime, kontaktandmeid ja muud iga inimese puhul varieeruvat infot.  Näiteks järgmine HTML kood kasutab seda ära:

<div style="font-size:9pt;font-family:Calibri,sans-serif;">
  %%DisplayName%%<br />
  %%Title%%<br />
  &nbsp;<br />
  Tel: %%Phone%%<br /></div>
&nbsp;<br />

<div style="background-color:#D5EAFF;border:1px dotted #003333;padding:.8em;">
  <img align="left" hspace="3" alt="Eneta" src="http://www.eneta.ee/SiteCollectionImages/promo/eneta_blog_175x75_02.gif"/>
  <p style="font-size:8pt;line-height:10pt;font-family:Cambria,'times roman',serif;">Mine loe Eneta portaalist uudiseid</p>
  <span style="padding-top:10px;font-weight:bold;color:#CC0000;font-size:10pt;font-family:Calibri,Arial,sans-serif;">
    <a href="mailto:%%email%%">%%email%%</a>
   </span><br /><br /><br />
</div>

Tulemuseks on järgnev signatuur:

Meelis Nigols 
mõttejagaja 
 
Tel: 1234567
Eneta

Mine loe Eneta portaalist uudiseid

meelis@kuskil.ee