Category Archives: Exchange

Exchange: „Retention Policy“ na Public Folder (Age limit)

Po migraci na Office 365 – Exchange Online jsme potřebovali znovu nastavit na vybraných mail-enabled veřejných složkách, aby se v nich starší zprávy automaticky mazaly.

Nedělá se to přes Retention Policy jako u běžných mailboxů, ale ve vlastnostech veřejné složky je na záložce Limits přímo volba Age limits:

image

Nastavené trvá nějakou dobu, než se projeví a starší zprávy vypadnou. Posledně to chtělo tuším den. nepomáhá ani Start-Start-ManagedFolderAssistant na PF-mailbox z PowerShellu.

…tak příště už to snad nebudu hledat.

Exchange Management Shell vůči Office365

Pro slabo-poweshellisty, jako jsem já, si zapisuji postup, jak si z PS připojit session na cloudové Office365:

Podle potřeby:
>Set-ExecutionPolicy Unrestricted

>$LiveCred = Get-Credential

>$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook
.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

>Import-PSSession $Session

>...

Přihlašovací údaje je samozřejmě potřeba zadat ty z Office365.

Domain Catch-all – pokračování

Pár měsíců nazpět jsem si tu zoufal (Domain Catch-all) při neúspěšných pokusech o nastavení doménového koše pro jednu z našich domén, kterou používáme na příjem testovacích emailů, které během vývoje produkují naše aplikace. Cílem bylo aby jakýkoliv email který je odeslán na emailovou adresu *@devmail.havit.cz došel do konkrétní schránky. Tenkrát se ještě nezadařilo, neboť Exchange tvrdošíjně odmítal přijmout jakékoliv zprávy určené uživatelům které neznal a pravidlo se tak nemohlo uplatnit. To už je ale minulostí, problém se podařilo vyřešit.

Stačilo nastavit v menu mail flow v záložce accepted domains pro danou doménu s pravidlem Domain cach all volbu Internal Relay: Email is delivered to recipients in this Exchange organization or relayed to an email server at another physical or logical location.

Nastavení accepted domains pro Domain catch all pravidlo

Nastavení accepted domains pro Domain catch all pravidlo

Od té doby funguje všechno jak má. Naštěstí nemusíme řešit situaci kdybychom chtěli podobné chování pro naši regulérní doménu havit.cz.

Stránky která se tématu věnuje do větší hloubky: Catch-All for MS Exchange 2013 SP1 on specific Authoritative Domains – Server Fault

Domain Catch-all

Pro vývojářské a testovací účely máme často scénáře, že je potřeba pracovat s větším množstvím aplikačních uživatelských účtů a k nim přidruženým emailovým adresám. Samozřejmě, že jsme kvůli tomu nezakládali stovky emailových schránek na našem Exchange, ale používali jsme pravidlo, které všechny emaily došlé na adresu odpovídající patternu *@devmail.havit.cz přesměrovalo do předem určené schránky. Minulý čas je na místě, jelikož od migrace na verzi Exchange 2013, nyní už s CU3, stále ještě dokáže překvapit co za funkčnost zmizelo, nebo co nefunguje jak má.

Po tom co se objevilo spoustu nedoručitelných emailů které dříve byly korektně zpracovávané, jsem si naplánoval hodinku na vyřešení problému, s tím že pouze něco lehce dokonfiguruji a bude hotovo.

Začal jsem kontrolou konfigurace našeho SPAM filtering serveru, kde běží produkt ORF (který mohu s dobrým svědomím všem doporučit – používáme léta k naší plné spokojenosti). Bylo potřeba do nastavení přidat výjimku, jelikož jedno z aktivních pravidel a jeho výchozí nastavení nebylo kompatibilní s naším záměrem. Jedná se o Recipient validation které kontroluje zdali v organizaci existuje mailbox s daným emailem. Pokud neexistuje, tak ukončuje okamžitě SMTP relaci a nedochází k dalšímu zpracování emailu.

ORF

Při migraci z Exchange 2010 na verzi 2013 se k mé radosti původní pravidlo (Transport rule)přeneslo a zachovalo si svoje nastavení. Samotné nastavení v prostředí verze 2013 vypadá takto:

ecp

Ve verzi 2010 jsme měli pravidlo postavené na regulárním výrazu – adresa příjemce musela splňovat určitý pattern. Jak vytvářet regulární výrazy ve verzi 10: http://technet.microsoft.com/en-us/library/aa997187(v=exchg.141).aspx

Přestože bylo pravidlo aktivní, všechny emaily zaslané do domény devmail.havit.cz vracely jako nedoručené s následující hláškou: domaincatchall@devmail.havit.cz
Remote Server  returned ‚550 5.1.1 RESOLVER.ADR.RecipNotFound; not found‘. V tušení možné zrady zde jsem začal pátrat v dokumentaci pro verzi 2013 – ta nyní plně podporuje Microsoft.NET Framework regular expression (regex). Trochu jsem si upravil předchozí regulární výraz na ^[A-Za-z0-9_-]*@devmail.havit.cz$. Nastavení pravidla je vidět na následujícím obrázku:

transportrule

Nicméně kýžený výsledek se nekonal. Při dalších pokusech jsem ještě narazil na zajímavou možnost (buď jsem ji ve verzi 10 přehlédl, nebo je ve verzi 2013 nová) – to co se snažím pracně nastavit přes regulární výraz jde nyní jednodušeji přímo přes předpřipravenou podmínku:

transportrule2

Ani to mě však nedovedlo k cíli. Další cesta vedla přes pokusy o nastavení Antispam protection – Recipient filtering přímo na Exchange. Toto nejde nastavit v UI, ale je potřeba provést přes EMS(Exchange management shell) (více k Antispam konfiguraci: http://technet.microsoft.com/en-us/library/bb125187(v=exchg.150).aspx)

  • Set-RecipientFilterConfig -Enabled $false
  • pro jistotu ještě Set-RecipientFilterConfig -RecipientValidationEnabled $false

Ani toto však bohužel nevedlo k cíli. Byl jsem už poměrně rozladěný a tak jsem googlil co to šlo, až jsem narazil na podobný problém který byl na Microsoft fóru vyřešen takto:

Hi Frank – Thanks for checking in.  At this point I’ve marked it up as „can’t be done“ on exchange 2013.

Dále jsem našel ještě nějaké diskuze vedené v podobném duchu , případně vysvětlování proč tuto funkci uživatelé vlastně nepotřebují (třeba zde).

Další cesta kterou se ale vydat moc nechci, je řešení založené na doinstalování Domain catch-all agenta (https://github.com/Pro/exchange-catchall), kdoví co všechno co dosud fungovalo by se tím rozbilo. Zbývá tedy čekat na balíček s CU4 , nebo vyřešit problém nějakým workaroundem.

Toto je právě ten typ problémů, kvůli kterým přechod na Exchange 2013 zatím nemohu doporučit.

Update: Problém se asi po roce podařilo vyřešit viz Domain Catch-all – pokračování

Outlook/Exchange: Rule that applies to specific recipient email alias / Pravidlo s podmínkou na e-mail alias

I do have several generic e-mail aliases set to my Exchange mailbox. I want to create Outlook rules to process these messages separately and it was a little bit tricky to find the right condition which applies to messages sent to specific alias:

  1. You can use „with specific words in the message header“ condition, where you specify „To: <alias@domain.com>“ in Search list (or other forms applicable to message header as you need).
  2. The „with specific words in recipient’s address“ condition didn’t work for me.
  3. The „sent to people or public group“ condition didn’t work for me.

Mám na svém Exchange mailboxu nastavených několik generických aliasů typu (info@domain.com, admin@domain.com, atp.) a chtěl jsem vytvořit Outlook pravidlo, které by mi tyto zprávy zpracovávalo odděleně:

  1. Je potřeba použít podmínku „pokud obsahuje: určitá slova v záhlaví zprávy“ s volbou „To: <alias@domain.com>“ (nebo dle potřeby jiné formy použitelné v hlavičkách zpráv).
  2. Podmínka „pokud obsahuje: určitá slova v adrese příjemce“ mi nezabrala.
  3. Podmínka „odesláno uživateli: osoby nebo veřejná skupina“ taky nefungovala.

Outlook+Exchange: „Your server administrator has limited the number of items you can open simultaneously. Try closing messages or removing attachments and images from unsent messages you are composing.“

Pokud Vám Outlook (v mém případě 2013) vrací takovouto chybu (obzvláště ve spojení s Exchange 2013), pak vězte, že to ve skutečnosti znamená něco jako „příliš mnoho otevřených spojení jednoho uživatele na Exchange server“. Mně se to konkrétně děje, když si pustím Outlook na desktopu a notebooku zároveň, tak mi nejde pracovat s veřejnými složkami, protože pro ně si chce Outlook otevřít další spojení a Exchange už mu ho nedá.

Pokud zavřu jednoho z klientů, problém zmizí.

Viz též:

Update

Toto pomohlo (http://www.symantec.com/business/support/index?page=content&id=TECH198553):

  1. On each Exchange 2013 mailbox server, create a new registry DWORD value called Maximum Allowed Sessions Per User under the following registry key:
    \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
    
  2. Set Maximum Allowed Sessions Per User to 0x00001388 to allow up to 5,000 sessions per user.

Exchange 2010: Pomalý relay (MaxAcknowledgementDelay)

Po upgrade na Exchange 2010 se razantně zpomalil relay mailů z našich aplikací skrz Exchange (SMTP forwarding).

Jak se ukázalo, řešením je přepínač MaxAcknowledgementDelay na příslušném receive-connectoru:

Set-ReceiveConnector "Connector Name" -MaxAcknowledgementDelay 0

MaxAcknowledgementDelay určuje, jak dlouho může Exchange zdržet session, aby jí oznámil výsledek odeslání. Oficiální dokumentace říká:

The MaxAcknowledgementDelay parameter specifies the maximum period the transport server delays acknowledgement until it verifies that the message has been successfully delivered to all recipients. When receiving messages from a host that doesn’t support shadow redundancy, an Exchange Server 2010 transport server will delay issuing an acknowledgement until it verifies that the message has been successfully delivered to all recipients. However, if it takes too long to verify successful delivery, the transport server will time out and issue an acknowledgement anyway.

Osobně to laicky interpretuji tak, že Exchange se při relayingu snaží přijatý mail rovnou i odeslat, tak, aby té iniciující session rovnou oznámil, jestli se to podařilo. A výše uvedený časový limit říká, jak dlouho na to Exchange má, jinak inciující session pokračuje, aniž by se o výsledku odeslání přímo dozvěděla. Nastavením na 0 se řekne, že odesílající aplikace nemá zájem se problém dozvědět hned, ale holt kdyžtak dojde na NDR (Non-Delivery-Report).

Každopádně odesílání 13.000 mailů našich newsletterů z business.center.cz se z hrůzostrašného tempa 1 mail/3-10 sec vrátilo na původní čísla známá z Exchange 2007, tedy zhruba 30 minut na všechny maily (což mimochodem není nic proti dávným dobám, kdy jsme používali Merak Mail Server, a ten to dokázal převzít do fronty zhruba za 5 minut, ale to je holt jiná kategorie).

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).