Portál AbcLinuxu, 23. července 2025 05:55
Příběh začíná heterogenním prostředním. Matka, sestra a děti. Matka se sestrou na Exchange, dvě oddělená AD. Děti jako child domény patřící matce. Protože je třeba na dětech šetřit, tak nemohou mít přeci drahý Exchange. Vybral jsem tedy Kerio Connect, do kterého jsem se z pohledu správy zamiloval. Vždy svižné web rozhraní, přehledná adresářová struktura, filtrování atd. Upgrade na novější verze bez nutnosti plánovat odstávky, protože 4min výpadku si nikdo nevšimne (s Exchange, který spápne hoďku je to neporovnatelné). Bavíme se o 400 schránkách a 1,5TB dat. Na začátku byl problém s rozšířením do Outlooku, který se časem zlepšoval. S jedním mailboxem nebýval problém, ale jedna dcera jela stylem všichni všechno, což je třeba 8 mailboxů v outlooku, každý 20GB a ten addon měl maily v lokální fdb (firebird). Bez SSD je taková věc konečná. V té době nebývaly SSD běžné. Časem se SSD naladily a i Kerio vydávalo vylepšení, až to bylo super. Podpora ActiveSync od začátku také byla, občas nějaká muška, ale dalo se.
Pak přišla Babička ze zahraničí a řekla managementu, že migruje do O365. A protože Babička je z bohatého západu, tak migrovala s nejvyšší licenční pálkou pro všechny, což je E5 za asi 50 EURO/hlava/měsíc.
Matka si řekla, že Babibička je vzor, takže se půjde také do O365 a vyzkouší se to na dětech. Takže migrace z Kerio Connect do O365. Šlo to celkem ok. Mezitím si sestra řekla, že do O365 také půjde, takže taktéž zmigrovala. Výsledkem tedy byly stále tři prostředí, navzájem nepropojitelné.
Matka si za dob covidu řekla, že chce Teams a vedení IT rozjelo Tenant mimo ten, kde měly data děti. Takže čtvrté prostředí, které nebylo zamýšleno jako prostředí, ale jako licence jen pro MS Teams. Nicméně jak to bývá, dočasná řešení bobtnají, data tam proudí, uživatelé se tam množí a ve finále z takových dočasných blbostí vzniknou fungující celky s hafec daty.
Pro tři oblasti existují čtyři prostředí, navzájem nijak nepropojitelné. Super fůra hnoje je tedy na světě. Může se začít gratulovat. Líp už to snad nejde.
Sestra je out, jiný AD strom, hodně uživatelů atd. Takže začneme tím, že se pokusíme spojit matku s dětmi. Až bude matka s dětmi spojena, tak zkusíme zbavit svět dočasného tenantu pro Teamsy. To by mělo ve finále dělat dvě prostředí. A pak je to o tom spojit matku se setrou, pokud už nebude pozdě.
Nyní probíhá fáze spojování matky s dětmi (resp. jedno dítě zůstalo s matkou, chuděra, ale aspoň z něj může být testovací subjekt). Stejný AD strom, ve kterém jsou děti v O365 a matka v Exchange, bez hybridu. Naprostý nestandard.
Jen pro představu, spálil jsem na základních přípravách 60 hodin čistého času (spíše více, nejsem úplně příkladný v doplňování časů do redmine), dalších 7 hodin test migrace a dopracování dalších uživatelských návodů. A to všechno za pomoci týpka z třetí strany, který má s migracemi a O365 zkušenosti. Týpek byl/je konzultační, takže v těch 60h jsme buď prováděli konzultaci příprav a dalších kroků, nebo jsme spolu měnili konfiguraci, nebo jsem prostě psal powershell scripty na čištění uživatelů, konsolidaci, hledání kolizí apod.
Bez nachytřeného týpka, co s tím má zkušenosti, bych to asi nikdy nedal. Má know how, zná voodoo apod. Takže když se třeba jeden uživatel špatně syncoval do O365 a nepomáhalo nic, tak pán přišel s voodoo trikem, kdy se přidal uživateli nesmyslný emailový alias a Entra AD Sync najednou prošel, protože on z dob zaříkávání technologií MS ví, že Entra AD Sync nesyncuje vždy všechno 1:1, ale někdy ví, že toto už prováděl, tak už na to nikdy nesáhne, i když je to špatně, dokud se tam neobjeví pro něj viditelně nějaká změna.
Tady je ochutnávka, jak kydání probíhá (k získání počtu akcí nutno vynásobit koeficientem sračkometu 50):
Nutno podotknout, že tím, jak světy šly vedle sebe a ne spolu, tak existují kolize, které nejdou dobře řešit. Např. pokud existuje "novak@dite1.tld", tak nemůže (může, ale neměl by) existovat "novak@matka.tld". Přesně tak, pro MS je nutný prefix. Uživatel != email. Email se generuje z aliasu a párují se na to další generované interní aliasy pro vnitřní komunikaci mezi Exchange (MSE) a O365. A teď sranda v podobě toho, že kolizní jsou i uživatelé z nejvyššího managementu.
Výše uvedené je jen třešnička, problémů se skýtá mnohem více.
Vykydání hnoje je běh na krutě dlouhou trať a vypadá to i tak, že se neobejde bez krve. MS třeba nepodporuje migrace mezi tenanty, nelze tak migrovat data mezi třeba dočansým MS Teams tenantem a hlavním. MS se odvolává na to, aby se uživatelé obrátili na třetí stranu, která to umí. Jenomže třetí strana sice umí částečně i migraci dat, ale většinou jen neexistujících uživatelů. Pokud už jsou v cílovém tenantu stejní uživatelé, tak smůla, merge dat jaksi asi není moc reálný, nebo velmi obtížný. Dále těžko říci, jak s ACL apod.
Nezbývá, než popřát v dalším kydání hnoje. Nejhorší na tom ale celé je, že se ze mně stal nejnachytřenější správce O365 z teamu. A to se mi nelíbí, protože je to věc, co bych nejraději už neřešil, odškrtnul si jako hotovo a nikdy se k tomu nevrátil.
Zdar Max
PS: Ještě přemýšlím, zda neuvolnit anonymizovanou nekompletní dokumentaci všeho, ale nevím, zda to má smysl. Je to docela rozsáhlé a bez kontextu, jak některé věci fungují, to může být stejně nicneříkající.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.