Exchange 2013 uuenduste paigaldus

Sai hiljuti just läbi tehtud Exchange 2013 serverile uuenduste paigaldus.  Ja pärast seda olen veendunud, et ainuke õige viis Exchangele uuenduste pealepanekuks on olemasoleva serveri kõrvale uue paigaldamine ning rollide ületõstmine.  Sest nii hoiab kõvasti närve ja tõenäoliselt ka aega kokku.  Ning lisaks muudele eelistele saab uuendamist teha rahulikult keset päeva.

Exchange on juba pikka aega olnud selline keskkond, kus parandused lastakse välja ühe komplektina.  Ning Exchange 2013 puhul on seesama komplekt sobiv ka uue serveri paigalduseks.  Aga kui Sa järele proovid, siis tuleb välja, et testitud on ainult tühja masinasse Exchange paigaldust.

Mis siis valesti on?  Paigaldusprotsess on jagatud mitmeks sammuks.  Iga samm paigaldab/uuendab ühe komponendi.  Uuendamise puhul võetakse sammu alguses ports teenuseid (sealhulgas Exchange teenused), pannakse need seisma ja keelatakse nende käivitamine.  Kuskil paigalduse käigus aga läheb neid teenuseid järsku vaja ning teenused käivitatakse uuesti.  Windowsi teenustega on tavaliselt kõik hästi, ent Exchange enda teenuste puhul on paigaldusprotsess unustanud, et teenused keelati ära.  Ja tulemuseks on veateade ning poolik paigaldus.

Mis halvasti, see uuesti.  Aga tulemuseks on sama probleem, kuna paigalduse sammu alguses keelatakse teenused ning töö käigus püütakse neid uuesti käivitada.  Ja seda hoolimata sellest, et antud sammu on juba korduvalt jooksutatud…

See probleem pole Exchange 2013 Cumulative Update 10 juures unikaalne, vaid eksisteerib juba mitu aastat.  Ning kuskilt otsast pole näha, et midagi muutuks.

Kui ülaltoodud jutt pole Sind veel piisavalt ära hirmutanud ja Sa siiski proovid, siis varu kannatust ning ära mine arvutist kaugele, sest paigaldusprotsessi tuleb pidevalt järele aidata.

Enne alustamist tasuks salvestada hetke teenuste häälestus.  Seda saab teha näiteks Powershelliga:

Get-CimInstance -ClassName Win32_Service |
  Select-Object Name, StartMode , State |
  Export-Csv -Path .\teenused.csv -UseCulture -Encoding Default

Kui jooksva sammu progress on jõudnud ~3% peale, siis tuleks (tavalises) Powershellis käivitada järgmised käsud:

Get-Service -Name msexchange*, fsm |
  Set-Service -StartupType Manual

Ja sedasi iga kord, kui paigaldus uue sammu peale läheb.  Seetõttu ei tohigi masinast kaugele minna, sest teenused tuleb uuesti käivituvaks teha, muidu jääb paigaldus pooleli. Ja tuleb jälle kõik sammud läbi käia…

Kui nüüd paigaldus on lõppenud, siis on kogu selle sebimise käigus läinud kaduma teenuste varasem staatus.  Seetõttu tuleb see ise taastada:

$teenused = Import-Csv .\teenused.csv -UseCulture

$teenused | Where-Object StartMode -Like "Auto" |
  ForEach-Object {
    Set-Service -Name $_.name -StartupType $_.StartMode
  }

$teenused | Where-Object State -Like "Running" |
  Start-Service

Tegelikult salvestab Exchange paigaldus samuti teenuste häälestuse.  Ent miskipärast häälestuse taastamisega paigalduse lõpus enam hakkama ei saadud.

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.

Valikud MCSE tiitlites

Kui juba Microsofti sertifitseerimisest rääkima sai hakatud, siis tasub veel ära mainida, et hiljuti tekkis ka uus MCSA taseme tiitel – MCSA: Office 365.  Selle tiitli kättesaamiseks tuleb sooritada kaks eksamit:

Ning kuna vastav tiitel on seotud Office 365 kaudu pakutavate toodetega, siis on järgmistel MCSE taseme tiitlitel võimalik kasutada ülalmainitud MCSA tiitlit MCSA: Windows Server 2012 asemel (ehk siis valikuna):

Jällegi võimalik eksameid kokku hoida, kuna MCSA: Windows Server 2012 sisaldab kolme eksamit, MCSA: Office 365 aga ainult kahte.

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 ja OWA kerge versioon

Lihtsad asjad on ikka need, mis kõige rohkem peavalu valmistavad.  Näiteks kui Sa kasutad Outlook Web Access’i  (2007 või 2010) ning mingist hetkes alates näed ainult kasutajaliidese kerget (piiratud funktsionaalsusega) versiooni, siis tahad Sa tõenäoliselt saada tagasi täisfunktsionaalset liidest.  Ja see ei pruugi õnnestuda, eriti juhul, kui Sa ei tea, kuidas kerge liides peale on tulnud.

Kerget liidest saab sisse lülitada kolme moodi:

  1. sisselogimise vormilt.  Sel juhul töötab kerge liides kuni väljalogimiseni.  Ja järgmisel sisselogimisel saab jälle valida, et kerge liides või täisfunktsionaalsus.
  2. Nägemisprobleemide hõlbustusvahendi sisselülitamisel.  Sel juhul jääb kerge liides aktiveerituks, kuni nägemisprobleemide hõlubustusvahend välja lülitada.
  3. kasutades OWA-d vähem toetatud veelilehitsejaga (Exchange 2007 veelilehitsejate nimekiri, Exchange 2010 veebilehitsejate nimekiri).  Sel juhul on kerge versioon automaatselt sees ning seda ei saa välja lülutada.

Neist teisel juhul (eriti, kui mitte teada selle seotusest kerge liidesega) tekib õigustatud küsimus, et miks kerge liides kogu aeg peal on.  Või et kuidas seda maha saab.  Juhendi sisselülitamiseks Exchange 2010 puhul leiab siit, väljalülitamiseks tuleb mainitud valik lihtsalt tühistada.  Exchange 2007 puhul on suvandite liides natuke teistsuguse väljanägemisega (Sätted | Üldine asemel on kohe Üldsätted), ent eelpool mainitud juhend peaks aitama ka sel puhul.