Category Archives: Exchange

Exchange 2010: Přístup Domain Admins na ActiveSync (Error 0x85010004, InvalidPolicyKey)

Pokud Vám ActiveSync hlásí chybu 0x85010004 a jste Domain Admins, pak vězte, že jedna z tajnůstek Exchange 2010 říká, že Domain Admins účty mají tento přístup zakázaný.

Obejít se to dá takto:

  1. Vezměte Active Directory Users and Computers konzoli
  2. Přepněte si režim na View / Advanced Features
  3. Odeberte uživateli skupinu Domain Admins, OK
  4. Otevřete znovu uživatele a na záložce Security jděte na Advanced a zaškrtněte Include inheritable permissions from this object’s parent, OK, OK, OK
  5. Přidejte si zpět Domain Admins
  6. …a Active Sync jede

Exchange Shell: Skript pro přesun public folders mezi dvěma Exchange servery (Replicas)

Potřebovali jsme přesunout veřejné složky (Public Folders) mezi dvěma Exchange servery, konkrétně z 2007 na 2010.

Postupů je na netu k nalezení mraky, nicméně obecně je jako jeden z kroků potřeba naklikat všem složkám nebo naskriptovat změnu Replication z jednoho serveru na druhý (z jedné DB na druhou).

Mělo by to jít pomocí skriptu MoveAllReplicas.ps1, z kterého se volá ReplaceReplicationOnPFRecursive.ps1, nicméně nám se tyto skripty v připravené podobě rozchodit nepodařilo.

Inspirovali jsme se však jejich obsahem a tak vzniknul níže uvedený primitivní skript na přenastavení všech replikací na cílový server:

$dbNew = get-publicfolderdatabase -server $newServer -erroraction Stop
$getpfcmd = "get-publicfolder -server $oldServer -identity $TopPublicFolder -Recurse -resultsize unlimited"

$tempik = invoke-expression $getpfcmd
$tempik | foreach {
    $_.Name;
    $_.Replicas.Clear();
    $_.Replicas += $dbNew.Identity;

    $_ | set-publicfolder -server $oldServer -replicas $_.Replicas
}

…výše uvádím snippet kódu, který představuje podstatnou výkonnou část. Před spuštěním je potřeba nastavit $oldServer, $newServer a $topPubliFolder (obvykle na zpětné lomítko).

Exchange 2007: Podivná authentizace starších klientů (Outlook 2003, Outlook Express)

Vynikající chybu jsem objevil v Outlook Expressu (z Win2k3 Serveru). Při připojení na standardní instalaci Exchange 2007 se při zaškrtnutí „Přihlašovat k serveru odchozí pošty“ – „Použít stejné přihlašovací údaje jako server příchozí pošty“ – klient neauthentizuje vůči serveru. Pokud však využijeme možnosti zadat authentizační údaje ručně, OE se přihlásí a poštu odešle. Pokud opět přepnete zpět na „Použít stejné jako příchozí“, tak odesílání pošty funguje, ale jen než restartujete OE.

Pominu-li tento bug v Outlook Expressu, tak problém je v tom, že standardní instalace Exchange 2007 nemá povolenu Basic authentization, resp. ji má pod podmínkou „Offer Basic Authentization only after starting TLS“. Exchange server tak v odpovědi na EHLO odpovídá jen AUTH NTLM a nenabízí AUTH LOGIN.

AUTH LOGIN povolíme odšrktnutím „Offer Basic Authentization only after starting TLS“ (Server Configuration – Hub Transport – Receive Connector – Properties – Authentication).

Manage auditing and security logs (SeSecurityPrivilege) chybí/mizí

Pokud skupině Exchange Enterprise Servers chybí právo „Manage auditing and security logs“ (SeSecurityPrivilege), což lze snadno ověřit utilitou \SUPPORT\EXDEPLOY\policytest.exe z Exchange CD, pak nám nastávají závažné potíže. Obyčejně nám začne failovat spouštění Exchange služeb, především Information Store.

Do logu můžem dostávat:

Event ID 7024, Service Control Manager:
   „The Microsoft Exchange Information Store service terminated with service-specific error 0 (0x0).“

Event ID 1121, MSExchangeIS:
   „Error 0x80004005 connecting to the Microsoft Active Directory.“

Event ID 5000, MSExchangeIS:
   „Unable to initialize the Microsoft Exchange Information Store service. – Error 0x80004005.“

Event ID 2103, MSExchangeDSAccess:
   „Process MAD.EXE (PID=2356). All Global Catalog Servers in use are not responding:“

…a podobné

Můžeme to snadno napravit setup.exe /domainprep, nicméně někdy ani to trvale nepomůže a dost krušné chvíle nám mohou nastat, pokud toto právo po čase mizí (policytest.exe nejdřív OK, později failuje).

Naštěstí už je člověk naučený, že pokud nějaké právo samovolně mizí, jsou prvním podezřelýmzásady zabezpečení (lokální, doménové, …). Je tedy potřeba ohlídat, aby nám zásady zabezpečení právo „Manage auditing and security logs“ pro doménovou skupinu „Exchange Enterprise Servers“ nelikvidovaly (je to v User Rights Assignments).

Připojení Outlooku RPC over HTTP(S) na Exchange

Na netu jsou stovky návodů, jak nakonfigurovat RPC over HTTP komunikaci Outlooku s Exchange serverem, např.

Návody jsou to celkem srozumitelné, nicméně může nastat mnoho zásadních zádrhelů, které návody nedostatečně zmiňují, či málo zdůrazňují. Některé, na které jsem narazil já:

Certifikát k HTTPS spojení musí být důvěryhodný

Pokud používáme k HTTPS certifikát generovaný vlastní certifikační autoritou (CA), pak musíme na klientském počítači zajistit, aby připojení k serveru probíhalo čistě, bez jakéhokoliv promptu Internet Exploreru na certifikát. Outlook totiž tento prompt nepodporuje a spojení zamítne.

V podstatě je potřeba nainstalovat certifikát na klienta, třeba přístupem na https://server/rpc/rpcproxy.dll. Musíme dosáhnout stavu, aby se nás to ptalo jen na heslo, na nic jiného. Nainstalovaný certifikát nám však bude fungovat jen v případě, že máme instalovaný i certifikát CA – ten je v členských počítačích domény instalován automaticky (pokud CA používá AD), na nečlenských počítačích je potřeba ho instalovat samostatně.

Pozor – narazil jsem na problém, kdy IIS mělo přidělený certifikát, ale mezi tím došlo k reinstalaci CA. Certifikát na IIS tak neodpovídal kořenovému certifikát CA. Internet Explorer to navíc pojal po svém. Místo, aby ohlásil neplatný certifikát, tak po instalaci kořenového certifikátu na jakýkoliv HTTPS požadavek vůči příslušnému serveru odpovídal chybou „Server nebyl nalezen nebo došlo k chybě v systému DNS.“ (jako kdyby server neexistoval).

Global Catalog na jiném serveru

Pokud máme scénář s jedním Exchange serverem, na kterém navíc běží i doménový řadič (DC), může se zdát, že není co řešit. Zásadní komplikace však nastane, pokud máme v doméně více DC a Global Catalog je na jiném serveru, než Exchange.

Který server je Global Catalogem poznáme v konzoli Active Directory Sites and Services, pokud si nalistujeme příslušný server, položku „NTDS Settings“ a k ní Properties – tam je zaškrtávací políčko Global Catalog. Jak přesunout GC na jiný server je mimo dosah tohoto článku.

Pokud tedy máme GC na jiném serveru, nestačí nám standardní konfigurace portů (hodnota ValidPorts), protože potřebujem na port 6004 dostat právě process lsass.exe z GC.

Jedna možnost je přesunout GC na stejný server k Exchange. Druhou možností je nastavit klíč registru „NSPI interface protocol sequences“ i na GC server a na exchange serveru nastavit v klíči „ValidPorts“ port 6004 na GC server (NetBIOS jméno i FQDN). V Outlooku pak jako server exchange vyplníme NetBIOS název GC serveru.

Pozor na to, že nám ve standardním nastavení funguje dokonce i RPCPING, protože si server s exchange na port 6004 nasadí vlastní proces lsass.exe. Nicméně Outlook zahájí komunikaci a nic se nepřipojí. V logu webové služby jsou též korektní řádky RPC_IN_DATA a RPC_OUT_DATA se success kódem 200.

Troubleshooting nástroje a doporučení

  • spouštět Outlook s parametrem outlook /rpcdiag (též Ctrl+RClick na tray-ikonu Outlooku a volba Connection Status…)
  • telnet localhost 6001,  6002, 6004 (ze serveru) dává banner „ncacn_http/1.0“
  • netstat -ano (ze serveru) nám říká, jaké procesy obsluhují jaký portu (6001-store.exe, 6002-mad.exe, 6004-lsass.exe nebo mad.exe),
  • utilita rpcping z Windows Server Resource Kitu (z klienta),
  • utilita rpcdump z Windows Server Resource Kitu (z klienta i ze serveru),
  • adresa https://server/rpc/ se musí ptát na heslo a pak odpovědět 401.3,
  • adresa https://server/rpc/rpcproxy.dll se musí ptát na heslo a pak odpovědět prázdnotou,
  • v logu webové služby musí být záznamy RPC_IN_DATA a RPC_OUT_DATA, kód 200.
  • při nastavování accountu v Outlooku musí být v základním dialogu interní jméno serveru a až v nastavení RPC over HTTPS se dávají public jména serveru (ty se musí shodovat se jménem, na které je vystaven certifikát pro SSL)

Exchange neodesílá, snaží se doručovat na divné IP adresy

Symptom

Pozoruhodné chování Exchange 2003 serveru. Neodchází maily do věšiny domén, zbytek zůstává ve frontě. Po bližším ohledání je v eventech vidět, že Exchange na některé pokusy vyhodí chybu, že mu protější strana neodpovídá. Z některých eventů je poznat, že komunikuje s podivnými IP adresami protější domény, které neodpovídají MX záznamům, ale jiným adresám v cílové doméně (nejpíš hlavní adresy domény, blíže jsem neprozkoumal).

Do domén, kde se adresa SMTP serveru náhodou shoduje s takto určenou IP adresou Exchange serveru, tak tam jsou maily doručeny v pohodě.

Příčina

Toto podivuhodné chování se projevilo na stroji Windows 2003 Server R2, který neměl na síťovém rozhraní nastaven DNS server. DNS služba však na něm běžela (to však nemusí být podstatné).

Každopádně stačilo nastavit DNS sám na sebe a vše se hned rozjelo. Čím resolvoval doposud, těžko říct. Očekával bych, že nebude resolvovat vůbec, ale nějak resolvoval…