Búcsú az Exchangektől

Vége, befejeztem.

Pénteken lekapcsoltam az utolsó Exchange szerveremet. Azt gondolom ezzel életem egy korszaka lezárult.

Az elmúlt pár évben, elsodródtam az üzemeltetéstől, a Microsoft eszközöktől és az Exchage-től. A napi életem ma Linuxok, CI/CD pipeline-ok, git, Jenkins, Nexus, Sonar, Terraform és főleg Amazon AWS körül zajlik.

Az eMail már nem az egyetlen, valószínüleg. nem a legnépszerűbb írásbeli kommunikációs forma, még céges környezetben sem. Ehhez jön, hogy a cégek nagy része átáll a felhő alapú megoldásokra. Az én Exchange tudásom, legalábbis ami több volt mint egy átlag rendszergazdáé, vagy konzulensé, a transport agent-ek (korábban transport sink-ek) gyártása. Ez az Office 365-nél már teljesen okafogyott, ugyanis ezek telepítését a rendszer már nem engedi. Így már nem érzem, hogy lenne értelme ezzel foglalkoznom.

Gondolkodtam, hogy írjak némi áttekintőt az elmúlt kb. 30 évről, az én a levelezés és az Exchange kapcsolatáról, de sok mindenre nem emlékszem pontosan, a dolog biztosan hiányos, pontatlan lenne, így ez most kimarad.

Tré-Systems

/Örjöngés on
Kedves drága Tré-Systems,
Mondjátok már meg, hogy a teljesen legitim - Microsoft Office 365 által kiállított és egyébként más domain-ben az AWS Route53 által elfogadott - DKIM rekordot mi a bús francért nem lehet a DNS szervernek csúfolt hulladékotokba bejegyezni????
/Örjöngés off

Exchange 2016 policy mizéria

Sírok.
Azt hittem, hogy egy bő hetes CU5 -> CU4 downgrade megoldja az e-mail policy bajom.
Hát nem.
Zoltan.Goemoeri@<domain> lettem. És ennek megfelelően természetesen a Fülöp családnevű kollégám Fulop lett. Konzisztens mi?
Hogy az a jó büdös.
Na szóval, ez ment a policy-ba:

%röo%g.%s@<domain>

Mostmár jó.
Csókoltatom a Microsoft-ot.

Exchange 2016 Cumulative Downgrade 5

Hosszú kihagyás után újra Microsoft Exchange került a kezeim közé. Ráadásul egyszerre több infrastruktúra is.
Mint amolyan rutinos Exchange admin, az Exchange 2016 telelepítéséhez. az aktuális CUD5-öt töltöttem le. Nem kellett volna.
1. Ha azt hiszed, hogy a %g.%s@<domain> a megfelelő SMTP policy bejegyzés akkor tévedsz:

Az Exchange elfelejtett Latin2-ül.
2. A levél szintű visszaállítás bizonyos backup szoftverekben kuka:
http://www.virtubytes.com/2017/04/17/veeam-exchange-2016-cu5-issue/
https://www.veritas.com/support/en_US/article.000126520

Office 365 - dirsync bug (ja bocs feature)

Hétfőn neki is láttam a nagy teljesen felesleges migrációnak.
Új Exchange telepítés, hibrid újrakonfiguráálás, számomra is meglepő módon, alig néhány elszállással végzett.
Az csoda számba megy nálam, hogy a Hybrid wizzard már másodszorra (persze minden adatmódosítás nélkül) képes volt hiba nélkül lefutni.
A végeredményben csak egy gond maradt. Nem tudodok az On-Premise teszt useremről levelet küldeni a cloud usereknek. Ezt, majd megoldom (úgyis várnom kellett az Amazonra, hogy megcsinálja a reverse rekordom, aminek hiánya nyugodtan lehet az ok).
Nekikezdtem a mailboxok migrációjának. Erre némely usernél ezzel a hibával örvendeztet meg:

Arra viszonylag gyorsan rájövök, hogy ezek a mailboxok nem az On-Premise környezetből lettek migrálva, hanem a felhőben "gyártódtak".
Megnézem, hogy mi a helyzet.
És tényleg nincs Mailbox GUID:

Irány a kugli.
Találok valami zavaros fórum bejegyzést, hogy a Dirsync-nek kéne ezt megoldania.
Megnézem, nincs bekapcsolva a Dirsync-en a kétirányú szinkron. Hogy ez mikor kapcsolódott ki arról lövésem sincs. Visszakapcsolom, full resync.
Probléma marad.
Ok, akkor nekiugrok, ADSI Edit. Kitöltöm. Pontosabban kitölteném, de semmi kedvem kézzel konvertálgatni a GUID formátumot HEX-be.
Kugli.
Itt a konverter:

GUID beír, migráció próba, működik.

Utóirat:
Ma nekiállok megírni ezt a cikket. Elkezdem keresni a fórumbejegyzést ami a Dirsync rendbetételét javasolta. Azt nem találom, helyette ez kerül elő:
http://community.office365.com/en-us/wikis/exchange/566.aspx
A dolog, iskolapéldája, hogy az O365 support (aki az említett fórumbejegyzésre válaszolt) mennyire van képben. A Dirsync nem írja vissza a GUID-ot és ez LE IS VAN DOKUMENTÁLVA!!!

Utóirat 2:
Azon gondolkozom, hogy a probléma esetleg proaktívan orvosolható lenne. Az EMC tud olyat, hogy bizonyos feladatokra rá lehet kapcsolódni és plusz dolgokat lehet vele csináltatni. Ezzel korábban már volt dolgom, csak most nem találom a cikket róla (lehet, hogy nem is írtam?).
Na szóval, ebbe a mechanizmusba be lehet tenni egy scriptet ami az online mailbox legyártásakor berakja a GUID-ot a helyére. Ez az a script amit most fix nincs időm megírni.

Office 365 - Murphy

Az egyik ügyfelemnek már régen tartozom az Exchange szerverén egy disclaimer beállítással. Ma reggel nekigyürkőztem és megcsináltam.
A múlt héten a főnököm, még mielőtt elutazott kiadta feladatba, hogy a sajátunkat is csináljam meg (visszajött feladatnak amit én találtam ki. :-D ).
Az ügyfél dolgán felbuzdulva nekiálltam a sajátunknak. Kitöltöttem az AD-ban a paramétereket (cím, telefonok, stb.), leszinkronizáltam az O365-be, majd bementem az online felületre, hogy legyártsam a disclaimert. Ott egy Exchange, Service Degraded ützenet fogadott:

Murphy szeret engem. :-D

Office 365 - Ahogy a Microsoft a dolgokat kezeli

Pénteken néhány kollégánk a Londoni irodában jelezte, hogy az Outlook nem tud kapcsolódni a levelezéshez.
Megnéztem, hogy mi történt az Office 365 szolgáltatással. Az Outlook hozzáférés valóban nem működött. Itt a szolgáltatásnapló:

Lefordítottam a fentieket egy közérthető párbeszédes formába. (Megjegyzés: ez a beszélgetés nem hangzott el):

Ügyfél: - Nem működik
Támogatás: - Megnéztük, működik
Ügyfél: - Nem, nem működik
Támogatás: - Mint már korábban is mondtam - MŰKÖDIK
Ügyfél: Nem, nem, nem. Nem működik. Nem tudom használni
Támogatás: - Lassan és hangosan mondom, hogy te is megértsd - M Ű K Ö D I K !!!
Ügyfél: - Ezt nem hiszem el. NEM TUDOK DOLGOZNI !!!
Támogatás: - Hopp. Tényleg nem megy. Javítjuk.

Office 365 - Csináljunk "Open Relay"-t

Szerinted nem lehet?
Pedig igen.
Amit itt leírok az nem teljesen "Open".
A dolog arról szól, hogy vannak gépeink amik levelet akarnak küldeni. Authentikáció nélkül, ki a nagyvilágba.
Rosszul hangzik? Pedig nem.
A legegyszerűbb eset, ha van egy web server amely a regisztrációról megerősítő levelet küld. A gép maga valahol van a nagyvilágban és nem az O365/Azure felhőben.
Jó-jó, de miért nem authentikáltan?
Mert az pénzbe kerül. Miért?
Mert authentikálni csak létező felhasználóval tudunk. Annak meg postaláda kell. A rendszerünk valamelyik felhasználója pedig erre nem jó, mert el kellene tenni a web szerver konfigurációjába a jelszavát (rossz ötlet).

Hogy is kell ezt összehozni?
Így:
1. Először is elmegyünk az Exchange Admin Center/Mail Flow/connectors-hoz.
2. Ott azt mondjuk, hogy Add (megnyomjuk a nagy büdös plusz gombot).
3. Ezek után beállítjuk az abrán lévő dolgokat.

(Nem kell megijedni, nincs ekkora monitorom, csaltam. a Paint.Net a mi barátunk)

Amint ezt megtettük, kész is vagyunk.
A dologhoz még az tartozik hozzá, hogy a küldő oldalon az Office 365-től az MX beállításhoz kapott FQDN-t kell használnunk mint smarthost és nem az smtp.office365.com-ot.

Office 365 - Public Folder: Van, de minek

A kollégáim kitalálták, hogy legyen közös naptár az Office 365 Exchange-ben.
Erre ugye a jól bevállt módszer a nyilvános mappa.
Megcsináltam.
Pontosabban csináltam egy nyilvános mappát ami e-mail-eket tartalmazhat.

Az Oulookban nem jelent meg.
Elmentem ebédelni.
Megjelent.
Hurrá.
Megpróbáltam az All Public Folders alá létrehozni egy naptár típusú PF-et.
Közölte nincs jogom. Remek. Az All Public Folders jogait pedig nem lehet állítani (ha mégis akkor csak PowerShell-ből, azzal pedig most nem szórakoztam).
Legyártom a naptárakat a korábban létrehozott e-mail típusú cucc alá, mindenkinek jogot adok.
Béke...

Akkor most jöjjön a kliens:
Outlook 2013. Látom a naptárat a folder nézetben. A naptár nézetben sehogy sem tudom felvenni. A mappa tulajdonságainál nyoma sincs, hogy felvehetném a naptár nézetbe, a kedvencekhez nem tudom hozzáadni. Remek.
OWA. Ezzel indítunk: http://community.office365.com/en-us/forums/158/t/160677.aspx.
MS mondja OWA-ban nincs PF
User mondja OWA-ban van PF ha hozzáadod a kedvencekhez
Másik MS mondja (ja tényleg) OWA-ban van PF
Közösen mondják Se naptár se névjegyalbum.

Hurrá.
Akkor most mi a jófrancnak van a PF? A választ tudom:
Az én bosszantásomra.

Office 365 - Dynamic Distribution Group

Kollégám próbál egy tervezett leállás levelet kiküldeni a plepsnek. Nem megy ki. A múltkor kiment.
Mi történt azóta? Katasztrófa.
A katasztrófa neve: Office 365 Hybrid Deployment
Mi történhetett?
gugli
Eredmény:
http://support.microsoft.com/kb/2685437
Ezek szerint valami email stempli hiányzik a distribution groupomról. Csináljuk meg:
A stempli nem hiányzik...
A DISTRIBUTION GROUP HIÁNYZIK!!!
Újabb keresgélés:
http://community.office365.com/en-us/forums/156/t/187434.aspx
Innen:
"In Office 365 with Hybrid Deployment, if you create Dynamic Distribution Groups on the on-premises Exchange organization, these objects are not replicated to Office 365 via DirSync. Therefore for mailboxes in the Office 365 cloud they will not see the Dynamic Distribution Group in their Global Address List, and so therefore can only email the members of the list by sending an email directly to their email address.
To show the Dynamic Distribution Group in the GAL in the cloud, you need to add a MailContact to the cloud that represents the Dynamic Distribution Group. This MailContact object should have the following mappings: 

On-Premises DDL	Cloud MailContact
Name	Name
proxyAddress	ExternalEmailAddress
Alias	Alias

Note that this MailContact object is made in Office 365 or Exchange Online and not in the on-premises AD. It is not replicated to the cloud via DirSync. If it exists on premises then the name for the DDL will appear twice in the on-premise GAL, once as a DDL and once as a contact object.
To determine the information need for the cloud contact object, run the following in Exchange Management Shell on premises: Get-DynamicDistributionGroup | fl Name,EmailAddresses,LegacyExchangeDN"


Először is, szidom mindenkinek a jó édes nénikéjét, hogy miért nem lehet ezt tisztességesen megcsinálni.

Elkezdek gondolkodni, majd nem csinálom meg a fentieket. Helyette, létrehozom mégegyszer a dinamikus disztribuciós listát a felhőben.

Hogy miért?

Mert a fenti megoldás sok sebből vérzik:

1. A felhőben lévő felhasználók az Outlookban névjegyet látnak és nem disztribuciós listát
2. A saját Exchangeben lévő felhasználók látják a névjegyet is és a disztribuciós listát is ugyanis a névjegyek szinkronja működik, ráadásul két irányban
3. Ping Pong. Miután a disztribuciós lista nem létezik a felhőben így ki sem lehet fejteni a felhőben. Küldök egy levelet a listának (pontosabban a névjegynek). A levél elmegy a saját Exchange-be, ott kifejtődik a disztribuciós lista, majd visszamegy a felhőbe. Sávszélesség és idő.
4. Mi történik, ha végül felszámolom a saját Exchange-en a transportot, mailboxot és átköltöztetem a felhőbe a transportot? A disztribuciós listára menő levelek nem fognak megérkezni.

Miért nem okoz gondot ez a megoldás? Mert nincs szinkron, így a két lista sohasem fog összecsattanni egymással.
Pontosabban fog, majd ha a Dirsync lekezeli ezeket. Akkor majd ki fogom bírni, hogy kapok néhány ütközésről szóló levelet.

Office 365 (félre)konfigurálva

Nem kis kínszenvedés árán (AD FS, aoutodiscover szívások) a céges levelezés lassan beköltözik az Office 365-ba. Hibrid konfigurációt csináltam, mert nem akartam menekülő út nélkül összerakni az egészet. Mi van ha gáz van, ha valami nem működik, stb.?
Tegnap az egyik főnököm jelzi, hogy egy specifikus embertől nem jött meg egy levél, amit végülis a magán címén megkapott, de a cégesen nem.
Nézem az Event logot és ezt látom:

Ok, akkor nézzük meg az SMTP logot. Na az nincs mert, a Manage Hybrid Configuration Wizard ugyan létrehozta ezt az inbound connectort, csak éppen a logolást nem kapcsolta be rajta.
Megnézek még egy-két beállítást, kicsit tuningolok, hátha.
Bekapcsolom a logolást, hogy lássuk mi van...

Ma reggel. Megnézem az event logot, a fenti bejegyzések változatlanul ott vannak.
Irány az SMTP log (mostmár van):

Itt látszik, hogy a feladó IP-je beleesik az Office 365 által kreált konnektor IP tartományába. Megnézem, hogy ki a feladó: messagelabs.com.
A messagelabs.com a weben a Symantec oldalára irányít.
A MessageLabs egy online levélszűrő. A Symantec felvásárolta őket jó régen:
http://www.symantec.com/about/news/release/article.jsp?prid=20081117_01
Na tehát a következő derül ki számomra:
A MessageLabs IP címei beleesnek az "Inbound from Office 365" konnector tartományába. A MessageLabs kimenő SMTP-in ki van kapcsolva a TLS, Az "Inbound from Office 365" konnektoron kötelező a TLS. Eredmény: A levelek nem jönnek be.
Ez félre van konfigurálva drága Microsoft, de nagyon.
Létrehozok egy bugfix connectort TLS enforcement nélkül és felveszem az IP-t.
Küldök egy service requestet az O365 supportnak.
Gondolkozom, további logturkálás/nslookup. Kiderül, amit sejtettem: A MessageLabs több száz forrás IP-ről küld levelet. Bugfix konnentor elvet, TLS enforcement kikapcsol (adjunk egy pofont a biztonságnak).

Továbbgondolom. Íme az elméletem:
A Manage Hybrid Configuration Wizard a teljes Azure felhő összes IP tartományát felveszi a "Inbound from Office 365" konnektorra. Valaki nem gondolta végig azt, hogy Azure cloud <> Office 365. Natív spekuláció, de el tudom képzelni, hogy a MessageLabs az Azure infrastruktúrán fut.
Tehát, ha valaki Mail szervert üzemeltet az Azure-ban és a kimenő SMTP-n a TLS nincs engedélyezve, az nem tud levelet küldeni egy Hybrid Exchange-nek.
Mi rosszabb, ugyanez valószínüleg a teljes Office 365 infrastruktúrára igaz ezek alapján:
http://community.office365.com/en-us/forums/158/t/156048.aspx
Ezzel csak az a gáz, hogy ha bemigrálom a bejövő levelezésemet is, ott már nem tudom a TLS enforcement-et kikapcsolni.

A nemzetköziség átkai

Kaptam egy levelet a főnökömtől. Szerinte valami gond van a naptárával. Ő Londonban ül és a jövő héten New York-ba megy. Szervezi a találkozóit és a rendszer nem jó időpontokat rak a naptába. London és New York között 5 óra az időeltolódás, neki pedig 4 óra eltolódással kerülnek a bejegyzések a naptárába.
Fél perc gondolkodás után, íme a megoldás:

Amazon Elastic Cloud - első benyomások

Mostanában elég sokat piszkálom a fenn nevezett cuccot. Egyenlőre nem vagyunk barátok.

Első benyomások:

+ Egyre inkább tetszik a koncepció, hogy pár dolláros óradíjjért akkora vasat gyárthatok magamnak amekkorát akarok. Tesztkörnyezethez piszok jó megoldás

- A felület kicsit kripli, egy rakás dolgot csak idiótán lehet megoldani. A virtualizációs környezetekhez képest fordított logikával

- Összerakott kész gépen nem lehet a belső hálózatos IP címet lecserélni. Hozzáadni lehet pluszban, belül lehet állítani, de az eredetileg amazon által allokált cím az marad

- Nincs gép konzol. Ez a windowsnál igen jó ötlet. Ha elírod az IP címet és nem tudod mi volt a hibás bejegyzés, ha elszúrod az RDP konfigot, ha a gép valamiért nem bootol, stb. Esélyed sincs, hogy rendbe szedd, de még arról se lesz infód, hogy mi a baja (vártam másfél órát egy w2k8 startra, mert frissítéseket konfigurált és nem láttam belőle semmit, azt hittem már megdöglött, pedig nem)

- Van snapshot, de a VSS-ről azt se tudják, hogy mi az. A konzisztens snapshot folyamat szerintük: lecsatolod a gépről a kötetet a gépről menet közben, megcsinálod a snapshotot, majd visszacsatolod. Lécci, csináld meg ezt egyszer egy éles Exchange store alatt!!! :-)

Na egyenlőre ennyi, de még barátkozunk.

Bocs papa

Kb. Két hónapja volt egy nagy rendszeren egy Exchange migráció két telephely között (valami 2000 user, sacc 3TB adat). Minden rendben le is ment (nem kevés szívás árán), de a régi szerverek ott maradtak, vész esetére. A dolog működik, így a héten el kezdtünk beszélgetni róla, hogy le kéne bombázni a régit (egy) péntek este. Ebben meg is állapodtunk.

Tegnap este nem volt energiám a dologra, így ma hajnalban kezdem neki. Némi küzdés árán sikerült is kiírtanom a szervereket.

Küldtem reggel egy levelet az ügyfélnek, meg a kollégáknak, hogy kész.

Kb. rögtön jött egy válasz az egyik kollégától, hogy...

Te ezt az ügyfél nem a jövő hétre tervezte?

Upsz. Visszanéztem az eredeti levelet amiben csak annyi volt, hogy majd egy pénteken és nem most.

Bocs papa.

Pedig totál mást lett volna kedvem csinálni ma reggel. :-(

Idiócia Windows 7/2008R2 - Jelszóváltoztatás

Kezdem a kályhától.
Elég sok különböző ügyféllel vagyok kapcsolatban. Ezek össze-vissza mindenféle VPN megoldást használnak. Elég jellemző, hogy ha bemegyek egy ügyfél VPN-jére akkor megszűnik a gépemen a net, az ügyfél gépén, meg sok esetben nem is volt (tipikusan szerver, tisztességgel lekorlátozva).
Ezek miatt kialakítottam egy virtuális gépet a saját Hyper-V infrastruktúrámon, amin fenn van az összes szükséges VPN kliens valamint a Microsoft Remote Desktop Connection Manager-ben összefogva az összes RDP kapcsolat (biztos van ennél jobb, de nem volt kedvem/időm keresni ilyet).
A fenti virtuális gépre szoktam bemenni RDP-vel és onnan managelni az ügyfelek dolgait. Így a saját gépemen megmarad a net, így tudok keresgélni, letölteni.
Az egyik ügyfélnél egy különösen idióta biztonságos konstrukcióba futottam. A VPN felépítésekor még a lokális hálózatot is kinyírta. Tehát amikor felépítettem a VPN kapcsolatot a virtuális gép felé meglévő
RDP-met is lebontotta. Innen az lett a gyakorlat, hogy a Hyper-V managerből a konzolra kapcsolódva intéztem az ügyeket (ezt legalább nem tudja kinyírni a VPN kliens).
Pár napja elkezdtem az ügyféltől kapni a figyelmeztetést, hogy lejár a jelszavam. Húztam-halasztottam, de ma már kénytelen voltam cserélni.
Bejelentkeztem (Hyper-V konzol + RDP kliens) és megpróbáltam megnyomni a Ctrl-Alt-Del-t.
Kaptam a sajtát Windows 8-amhoz ide vonatkozó ablakot. Ctrl-Alt-End: vonatkozó ablak a virtuális Windows 7-en. Millióféle kombináció full screen itt, full screen ott, Ctrl-Alt-Del, Ctrl-Alt-End, sehogy sem kapom meg a megfelelő ablakot az ügyfél Windows Server-én. RDP Manager menük végignézve A-tól Z-ig, nyoma sincs, hogy át tudnám küldeni a megfelelő billentyűzet kombinációt.
Google:
Két módszert találok:
net user parancssorból. Access Denied, mert vagyok Exchange, SPS, SCCM admin, de domain admin nem.
run32dll-es bohóckodás. Windows 7-en és ebből adódóan Windows Server 2008R2-n sem működik.
Dead End. Ez egy agyrém. Nem igaz, hogy a felhasználó számára a Ctrl-Alt-Del nyomkodásán kívül nincs más módszer a jelszóváltoztatásra!!! Örjöngök.
Gondolkoz-Gondolkoz:
OWA beficcen. Jelszó megváltoztat. Huhh.

GitHub

Ma volt némi időm, amellett, hogy rendeltem feszültségszabályozót a Kinetis projecthez, eljátszottam kicsit a GitHub-bal. Nem mondom, hogy kézre áll (ez a sourcecontroll dolog még mindíg magas nekem), de azért sikerült belerámolnom a két teljesen kész projectem (Frekimérő, Hőmérő) dolgait.
Ettől kezdve akinek kellenek a kódok, források, tervek, itt találja meg:
https://github.com/sufzoli
A napokban tervezem, hogy elkezdem feldolgozni a félkész, vagy még csak tervezett projecteket és azok is mennek ide. És ez nem csak az elektronikára vonatkozik. Ott egy rakás Exchange-es kód ami a kimúlt régi weboldalaim miatt ma nem érhető el.

Bugot fogtam

Ép a mai konferenciához végeztem az utolsó simításokat a demón amikor egy érdekes dologra lettem figyelmes. Kb. ötödször vágtam nyakon a teszt iPhone-t az Exchange-ről (remote wipe) amikor látom a safariban, hogy az automatikus címkiegészítés felhozza a saját certificate authority-m címét.

Kipróbáltam más címmel, szigorúan ügyelve arra, hogy az iCloud, vagy más szinkronizáció ne induljon el a telefon beüzemelésekor. A másik cím is feljött a listában. Puff neki, ennek bug szaga van, méghozzá biztonsági.

Telefon: iPhone 4/16gb

OS:  iOS 6.1.3

Már csak egy Apple oldalt kell keresnem, ahol bejelenthetem.