Exchange, Active Directory, Windows server... és ami még belefér
Megérkezett az utolsó cumulative update az Exchange 2019-hez, a CU 15: Download Cumulative Update 15 Exchange Server 2019 (KB5042461) from Official Microsoft Download Center
Innentől (illetve a CU14-től) csinálhatunk in-place upgrade-et az Exchange Server SE RTM-re vagy side-by-side is telepithetjük.
Exchange 2016 demotálás a feladat, rutinmunka.
Jön a lépés, az adatbázis eltávolítás. Tegye fel a kezét, aki még nem futott bele ebbe a képernyőbe (a valaha volt legidegesítőbb hibaüzenet díj esélyese…)
azaz: “This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, public folder mailboxes, arbitration mailboxes, or audit mailboxes. To get a list of all mailboxes in this database, run the command Get-Mailbox -Database <database ID>… To disable a non-arbitration mailbox so that you can delete the mailbox database, run the command Disable-Mailbox <mailbox ID>… Audit mailboxes should be moved to another server; to do this, run the command New-MoveRequest <parameters>. If this is the last server in the organization, run the command Get-Mailbox -AuditLog | Disable-Mailbox…”
Ok, jöhetnek az ellenőrző parancsok:
Set-ADServerSettings -ViewEntireForest $true
Get-Mailbox -Database MDB-01
üres az output
Get-Mailbox -Archive -Database MDB-01
üres az output
Get-Mailbox -PublicFolder -Database MDB-01
üres az output…
Get-Mailbox -Arbitration -Database MDB-01
ez is üres…
Get-Mailbox -AuditLog -Database MDB-01
itt sincs semmi…
Pingvinezés, asztalharapdálás.
Próbáljuk meg más kapcsolóval:
Get-Mailbox -AuditLog -Database MDB-01 | where {$_.IsMailboxEnabled}
Hoppáka! Te sötétben bújkáló…
Nézzük meg a további parancsokat, amiket visszaellenőrzés céljából futtattam. Az “IsMailBoxEnabled” nélkül bizony az orrunkál fogva vezet, hogy nincs ott semmi.
Tanulság: érdemes minden Get-Mailbox… parancsot a fenti kapcsolóval futtatni, hamarabb célhoz érünk…
Egyik kedves ügyfélnél erősen proxyzott környezet van. A SCCM-nek engedélyezték az auth nélküli proxy-t, meghatározott URL listával.
A feladat az SCCM co-management beállitása volt. Pár kattintás, Azure bejelentkezés, semmi extra. Aham…
Jól rákészültünk a proxybeállitásokra:
Ezek után az SCCM konzol a csatlakozáskor úgy befagyott mint a szög. Pár percig nézegette a köldökét, a proxy szerver felé semmilyen forgalom nem ment, aztán feldobta a microsoft loginablakot, végigment a név/jelszó/mfa, majd nem történt semmi.
“Mindig a hálózat a hibás. Mindig.” ezt régi kollégától hallottam, szeretjük is mindenre ráhúzni, de mivel forgalom nem ment a proxy felé, nehéz volt rásütni. De négy helyen is definiálva van a proxy, miért nem talál oda?
Végül process monitorral vizsgálva előbújt, hogy a Microsoft Configuration Management.exe küzd kihivásokkal. Szerencsére neki is lehet proxyt beállitani (az ötödiket!), mégpedig a C:\Program Files (x86)\Microsoft Endpoint Manager\AdminConsole\bin folderben a Microsoft.ConfigurationManagement.exe.config fileba kell definiálni:
<system.net>
<defaultProxy useDefaultCredentials=”true” />
</system.net>
Ezek után már gond nélkül kitalált a proxyn keresztül és sikerült a co-management beállitás…
Megjelent az idei első Cumultative Update az Exchange Server 2019-hez: Download Cumulative Update 14 for Exchange Server 2019 (KB5035606) from Official Microsoft Download Center
A CU alapból bekapcsolja majd az Extended Protection feature-t (Windows Extended Protection <extendedProtection> | Microsoft Learn), aki ezt nem szeretné, az telepítse powershellből a CU-t a /DoNotEnableEP vagy /DoNotEnableEPFEEWS kapcsolóval.
A TLS 1.3 támogatás Windows 2022 Serveren csúszik, a CU15-be fogják (remélhetőleg) implementálni.
Kb. 2009 óta foglalkozom az SCCM-mel, persze az utóbbi években egyre kevesebbszer, de azért előkerül. Ez az a termék, ami mindig lenyűgöz, hogy úgy érzem, értek már hozzá, aztán arculcsap a valóság…sokszor prózai okokból.
Ügyfélnél telepitettem SCCM-et, szépen működgetett, majd csendben lejárt a trial időszak (ritkán nyomogattam a konzolt). Sebaj, termékkulcs megad, konzol feléled, menjünk karácsonyozni.
Most újra elővettem a konzolt, szép zöld minden (system status, component status), de valahogy mégsem csinál semmit….a logokban nincs error, csupán azt tűnt fel, hogy kb az összes logfile egyszerre megállt december 15. 13:45-kor.
Benéztem a szervizek közé, de felesleges, mert fut minden…és hoppá!..az össze főbb service stopped állapotban van, Manual start opcióval.
Gyorsan visszaállitottam Automaticra őket és a service-ek elinditása után feléledt a SCCM is (a screenshot felúton készült) Hogy ezek mitől mentek manualba, tippem sincs…
Újabb lecke, hogy sosincs unásig tudott dolog, meglepi mindig érhet…
Elgondolkodtató…
…in late November there were 30,635 machines on the public web with an unsupported version of Microsoft Exchange:
Múltkor utaltam az Exchange vizsgára (Volt vizsga, nem lesz vizsga – E-mail és a detektívek (emaildetektiv.hu) ma nekiláttam.
Sikerült megugrani 800 ponttal, de elég érdekesre rakták össze. A kérdésekről nem beszélek, sokáig úgysem aktuálisak, de tartsuk az NDA-t.
Szóval, csomó powershelles kérdés volt, még a Case Study-kban is. Ezen picit húzom a számat, nem feltétlenül ez a jó tudásmérő, hogy kétsoros ps-eket kell összeraknod. A sima kérdések közül sok olyan volt, ami a való életben felmerült, bár vagy 10 kérdés a journalinggal foglalkozott, talán ez sem olyan releváns.
És nem lehet MS-vizsga félreérthetőség nélkül. Van egy device-od, ami mailt küld az EXO-n keresztül. Melyik a jó válasz, felveszed az ip-t az spf rekordba vagy veszel neki O365 licenszet és azon keresztül állitod be. Tipikusan az attól függ kérdés, de ilyen kevés infóval csak találgathatsz, mire gondolt az MS.
Jó vizsga volt összeségében, sajnálom hogy megszűntetik, mert aktuális a tudásanyaga, de igy alakult. Aki kedvet kapott hozzá (:D) július 31-ig levizsgázhat.
Hát, elég visszás….
Jelen pillanatban egy Exchange-minősítés érhető el:
Microsoft 365 Certified: Exchange Online Support Engineer Specialty, amihez egy darab vizsga elég: Exam MS-220: Troubleshooting Microsoft Exchange Online
Exam MS-220: Troubleshooting Microsoft Exchange Online – Certifications | Microsoft Learn
És ennek is vége nemsokára:
Egy korszaknak vége.
Nincs új a nap alatt; ebben a hónapban is kapnak Security Update-et az Exchange Serverek
Exchange 2016 CU 23: Download Security Update For Exchange Server 2016 CU23 SU8 (KB5025903) from Official Microsoft Download Center
Exchange 2019 CU 13: Download Security Update For Exchange Server 2019 CU13 SU1 (KB5026261) from Official Microsoft Download Center
Exchange 2019 CU 12: Download Security Update For Exchange Server 2019 CU12 SU8 (KB5026261) from Official Microsoft Download Center
Grafikus segédlet:
Nem vadonatúj az infó, de nem árt észben tartani: az EXO blokkolni fogja a sebezhető Exchange szerverektől érkező leveleket.
Sebezhető=nem támogatott verzió/nem megfelelő patch verzió
Kétkörös lesz a bekeményítés:
Nézzük a timeline-t, hogyan történik majd:
Stage 1: ez a report-only mode, az adminnak 30 napja van hogy rendbeszedje az Exchange kiszolgálót.
Stage 2-4: elkezdődik a throttling és minden 10 napban növekszik.
Stage 5-7: beindul a throttlink ÉS blocking, a blokkolás is 10 naponta növekszik.
Stage 8: az EXO nem fogad el leveleket az Exchange szervertől.
Az első áldozata a fenti szigorításnak az Exchange 2007 lesz, abban az esetben ha van outbound connectora az EXO-ba. Bízzunk benne hogy nincs sok ilyen, de soha ne mondd hogy biztos.
A következő körökben a Microsoft bővíti majd a blokkolandó termékek körét, függetlenül attól, hogy EXO konnektoron vagy sima SMTP-n csatlakozna be. Ezekről a Message Centerben lehet majd tájékozódni.
A múltkori cikkben megnéztük, milyen támogatott on-prem verziók maradtak, most járjuk körbe, hogy maradjunk-e a földön vagy költöztessük a felhőbe az egész levelezés miskulanciát.
Tegyük fel hogy szerencsés helyzetben vagyunk, nem vonatkozik ránk az 50-es törvény, egyéb szabályozások, szabadon mehetünk a felhőbe, ha szeretnénk. Ott állunk tehát a döntés küszöbén:
A döntéshez segitséget adhat a Microsoft Shared Responsibility modeljének áttanulmányozása (Shared responsibility in the cloud – Microsoft Azure | Microsoft Learn) . Egy ábrát emelnék ki, elég beszédes:
Ahogy látjuk, ha on-premise maradunk, akkor bizony minden felelősség a miénk, mindent nekünk kell megoldani; a fizikai szervereinket, storage-okat, hálózatot stb. Ok, eddig is ezt tettük, de manapság ez komoly nyűg is lehet.
Félmegoldásnak felmerülhetne, hogy akkor legyen IaaS, hiszen akkor a Microsoft megoldja helyettünk a datacenter-szerverek üzemeltetésének problémáját. Ez nagyon rossz ötlet, amellett hogy drága lenne, nem is olyan a performancia, mint pl. az Exchange Online esetén. Egyszóval ne futtassunk felhőben Exchange Servert.
A harmadik út a SaaS, azaz az Exchange Online. Ahogy a fenti képen látjuk, ez tűnik a legkényelmesebbnek, a gyártó szinte minden feladatot levesz rólunk. Technikailag is nehéz érvelni ellene (ok, a felhő is leállhat néha, illetve ha féltjük az adatainkat, hybrid esetén vissza is migrálhatjuk a postafiókokat a földi környezetbe).
Mivel gyakorlatilag minden szervezet használ már O365 vagy M365 licenszeket (főleg a Teams miatt), amikben benne van Exchange Online licensz is (sőt, hybrid esetén a Microsoft ad ingyen Exchange 2019 licenszet is, csak migrálj), adja magát a verdikt: költöztessük fel a felhőbe a levelezést.
Hozzáteszem, hogy ez egy általános megközelítés; minden cégnek a saját szempontjai alapján kell mérlegelni, egyedi igényeket és külső szabályozásokat figyelembe venni.
Kis áttekintés 2023 júniusában, hogy milyen on-prem Exchange rendszerekkel dolgozhatunk.
Bár gondolnánk, hogy egy levelező szerveren nem kell annyit frissítgetni, a gyártója másképp látja. Nézzük meg az ismert verziókat, hogy állunk most.
Aki tehát a földön szeretne (vagy kötelező neki) maradni, az üzenet világos: migrálj minél hamarabb Exchange 2019-re (hunyorítsunk együtt, hogy elvileg 128 GB RAM a beugró…) és húzd ki 2025-ig, amíg megjelenik a “v.Next”. Aki pedig már 2019-et használ, szorgalmasan frissítse a CU/SU-kat hónapról-hónapra.
Üdvözlet az Exchange-szcéna megmaradt tagjainak.
Aki követi kicsit a termék életútját, láthatja, hogy az Exchange halott. A Microsoft gőzerővel tol mindenkit a felhő felé, egyre inkább az a mantra, hogy ne üzemeltesd már, hanem migrálj az EXO-ba és megoldódnak gondjaid.
Borús is lehetne a hangulatunk, de inkább nézzük meg, mit lehet manapság kihozni az Exchange-ből és hogyan lehet összeilleszteni a felhős testvérével. Ezekről szeretnék a jövőben írni, még ha nem is csak szívásokat megörökíteni, de hátha hasznos lesz.
Nemsokára folytatjuk…
Gondolom, mindenki észrevette, hogy az utóbbi időben a blog bejegyzései megritkultak. Na jó, megszűntek. Tulajdonképpen csak azért nem zártam még be, mert jó volt tesztelgetni rajta azokat a dizájn megoldásokat, melyeket később be szerettem volna vezetni a mivanvelem blogon.
Hogy miért szűnt meg?
Erről nem akarok litániákat írni, a legfontosabb ok, hogy már nem volt mit megírnunk. Gömöri Zoli (SUF) teljesen eltávolodott az Exchange-től, a munka melletti hobbijáról meg külön blogokban irkál. (Magyar nyelvű, angol nyelvű.)
Én ugyan az Exchange/M365 közelében maradtam, de már sok éve nem végzek operatív munkát. Innentől szívjanak a fiatalok. Ha nagyon elakadnak, akkor még megpróbálom irányba állítani őket, de ezek már az ő történeteik.
Ebbe az egyre jobban kiszáradó pocsolyába dobott bele egy követ Istvánffy Zoli. Nemrég megkeresett, hogy ő is szokott szívni és ezeket szívesen publikálná a blogon. Természetesen elutasítottam. Viszont felajánlottam neki, hogy ha van hozzá kedve, akkor vigye tovább az oldalt. Volt.
Nekem ez az utolsó írásom ezen a blogon, egyfajta búcsú, Gömöri Zoli pedig itt integet mellettem.
Az átadás-átvétel folyamata elindult. Istvánffy Zoli gondolom majd megírja, mik a tervei a bloggal. Az eddigi szakmai jelenléte alapján úgy gondolom, nem lesz gond a folytatással.
Annyi év, annyi cucli után nem igaz, hogy még mindig ilyesmiket csinálok. SCCM-et telepítettem és az istennek sem akart összejönni az SQL kapcsolat. Pedig lassan már a reménytelen dolgokat is kipróbáltam. Végül a Wireshark egyik csomagjának elemzése során vettem észre, hogy elgépeltem egy betűt az instance megadásakor. (Sccm vs scmm.) Mondhatni klasszikus.
Most azt kellene írnom, hogy amint javítottam a nevet, egyből hasított… de nem. Jó vicc, akkor nem töltötte volna ki a telepítés a délutánomat. Szexuált működni. Igaz, ekkor már tényleg a belső tűzfal volt a saras, amint kikapcsoltam, ment minden. Csak hát… ez nem annyira korrekt. Viszont nem tudtam mást csinálni: az SCCM folyamatosan lehetetlen RPC portokra kapcsolódott az SQL-en, olyanokra, melyeket komoly rendszerszolgáltatások használtak. Hiába korlátoztam én le az SQL-t statikus portokra, ha ennek a szerencsétlennek annyi más is kellett. Végül hagytam a francba, a két szerver között engedélyeztem az any-any kapcsolatot, így van is tűzfal, meg a kommunikáció is megy.
Majdnem azzal fejeztem be, hogy hurrá, tkp mindenki örül, de jobban belegondolva, ez inkább az a szituáció, amikor mindenki szomorú egy kicsit.
Ezt az írást érdemes alaposan átolvasni – és végiggondolni. Az internet alapműködését feszegeti a téma.
A lépések számottevő problémát jelentenek, a Symantec-csoporthoz tartozó CA-k (a Symantec, VeriSign, az Equifax, a GeoTrust, a Thawte, RapidSSL és más kisebb márkák) által kibocsátott tanúsítványok ugyanis széles körben elfogadottnak számítanak.
– link –
Azaz a Google, konkrétabban a Chrome felül fogja bírálni a fenti CA-k által kiadott tanúsítványokat, sőt, az is benne van a pakliban, hogy nem fogja elfogadni ezeket. Ugye te is észrevetted a VeriSign nevét a felsorolásban? Az sem érdektelen, hogy a Symantec válaszként beszüntette az RA programot, azaz innentől a fenti CA-k mellett nem működhetnek külsős RA szolgáltatók.
Már eddig is csak úgy fityegett. Adott valamennyi pluszt, de cserébe pénzt kért és komplikációkat okozott.
Most jött a bejelentés, hogy az MS támogatási elveiben változás történt.
Mit tehetsz? Használd a Microsoft online megoldását, az Exchange Online Protection-t, vagy használj külső gyártótól származó offline megoldást.
Ennyi. A magam részéről annyira nem bánom. Az Edge jelentősége már régóta periférikus volt, az antispam ügynököket lehetett ugyan használni egy utolsó utáni védelmi vonalként, de a menedzselésük tragikus volt, hasonlóan a hatásfokuk is. Vegyük le a kalapunkat és egy perces néma csönd.
Mindenkinek, aki böngészőből próbálja tesztelni a belső autodiscover.xml elérhetőségét, ajánlom figyelmébe a Dirty Motherfucker blog erre vonatkozó bejegyzését. Én sem mondhattam volna szebben.
Recent Comments