Přesměrování OWA bez problémů
Administrace Exchange serveru - 34. část
Jak nastavit OWA redirect a nic nepokazit.    

Než začnu s pokračováním, tak možná pár informací na začátek. Pokud jste sledovali seriál od začátku, tak vás možná překvapí, že najednou mluvím o jiném FQDN serveru. Přecházel jsem z Vmware ESXi na Windows Server 2012 s Hyper-V. A nainstaloval jsem nový Exchange server, kterému jsem dal jméno mail.tnx.cz.

Takže dnešní článek bude o tom, jak udělat redirect pro OWA. V mém případě je adresa pro OWA https://mail.tnx.cz/owa/ Pro některé uživatele bývá taková adresa nezapamatovatelná a to ze dvou důvodů. Jsou zvyklí zadat pouze adresu webu, takže zapomenou přidat /owa/. A taky napsání https je často problém. Takže nastavíme IIS tak, aby se provedl redirect z http na https. A pokud zapomenou napsat OWA, tak to uděláme za ně. Aby všechno fungovalo, tak to předpokládá, že z venkovní a vnitřní sítě přistupujete na server stejným jménem. Pokud ne, tak si opravte DNS, aby to tak bylo. Jinak to nebude fungovat. Taky je potřeba říct, že port 80 má málokdo z venku otevřený. Takže redirect na HTTPS bude fungovat pouze zevnitř. Z venku buď povolíte přístup na portu 80 dovnitř a nebo máte firewall, který udělá redirect z TCP 80 na TCP 443 za vás.

Půjdeme do Administrative Tools a spustíme Internet Information Service (IIS) Manager. Proklikáme se na Default web site a vpravo otevřeme HTTP Redirect:

redirect01

Napíšeme adresu, na kterou chceme přesměrovat neúplné požadavky. Mělo by tam být https://FQDN vašeho serveru/owa, viz obrázek.

redirect02

Vpravo klikneme na Apply.

redirect03

Jenže teď by nám to přesměrovalo na OWA například i přístupy na Active Sync. A to nechceme. Takže tam, kde se nám to nebude líbit, tam to budeme muset odstranit. Takže klikneme vlevo na aspnet_client, potom na ikonku HTTP Redirect a zrušíme zaškrtnutí u adresy, na kterou se má redirectovat. Viz obrázek

redirect04

Klikněte vpravo na Apply. Stejným způsobem budeme pokračovat u následujících adresářů.

Autodiscover
ECP
EWS
Microsoft-Server-ActiveSync
OAB
PowerShell
Rpc
Nezapomeňte kliknout na Apply po každé provedené změně.

Pro jistotu dodám, že u Exchange, Exchweb, OWA, Public zaškrtnutí zůstane a u RpcWithCert vůbec nebude.

Tímto jsme vyřešili situaci, že někdo nedopíše OWA na konec adresy. Teď se podíváme na ptáčka SSL. Takže zůstáváme v IIS manageru, půjdeme na Default Web Site a klikneme na SSL Settings. Viz obrázek

redirect05

Zrušíme zaškrtnutí políčka u Require SSL a klikneme vpravo na Apply.

redirect06

Asi si říkáte, že je to divné. Přece člověk, který je při smyslech, nebude používat přístup na Exchange bez SSL. To je jednoduché. Tam, kde máme nastavený redirect, se stejně provede redirect na adresu, kterou jsme zadali s https, takže se stejně SSL použije. A tam, kde to máme vypnuté, tam zapneme vynucení SSL na každém adresáři zvlášť. Výjimka bude Power Shell. Tam to nezkoušejte, jinak si uříznete větev. ;-) Takže jdeme na Autodiscover. A zaškrtneme, že chceme použít SSL.

redirect07

No a teď totéž uděláme pro následující adresáře.

ecp
EWS
Microsoft-Server-ActiveSync
OAB
owa
Rpc

Je klidně možné, že pro některé adresáře to bude už zaškrtnuto. Třeba Active Sync nebo RPC.

Abychom měli jistotu, tak ještě použijeme IIS reset. Spustíme command prompt a spustíme příkaz iisreset

redirect08

A je to. Pokud máte správně nastavené DNS, tak zevnitř bude fungovat redirect na 100%. Z venku má většina lidí zakázaný port 80 na firewallu. Takže tam budou muset uživatelé opravdu zadat aspoň https://adresa serveru/ nebo budete muset povolit port 80 a nebo použít redirect na vašem firewallu, pokud to umí. A to je pro dnešek vše. Příště si povíme, jak opravit OAB, který jsme právě nabourali.

To bych vás asi nepotěšil, co? Mrkneme na to rovnou. Ta chyba se neprojeví vždy a je možné, že už je v SP2 nebo nějakém následném RU opravená. Ale v době SP1 RU6 byla stále neopravená. Projevuje se tak, že Outlook není schopný stáhnout OAB. Nejhorší je, že vám nevrátí žádnou chybu, o kterou se můžete opřít. Prostě píše, že stahuje OAB a můžete ho nechat klidně dva dny, nebude žádný timeout, žádná chyba, jen prostě OAB nestáhne a další úlohy čekají ve frontě. Důvodem je, že při nastavování práv na soubor web.config jsou z nějakého důvodu špatně nastavena práva v adresáři OAB pro Authenticated Users. Oprava je jednoduchá. Takže zpět do IIS manageru. Klikneme pravým tlačítkem na OAB a vybereme v menu Explore.

redirect09

Dostali jsme se do file systému, do adresáře, kde jsou soubory OAB. Vidíte tam soubor web.config. Pokud ne, zapněte si zobrazení skrytých a systémových souborů. (Zmáčkněte Alt na klávesnici, zobrazí se menu, v něm tools, ... hledej šmudlo) Klikneme pravým tlačítkem na soubor web.config, v menu vybereme Properties, pak vybereme záložku Security. A tady vidíme náš problém.

redirect10

Takže klikneme na tlačítko Edit. Otevře se nové okno. Tam klikneme na tlačítko Add. Napíšeme Authenticated Users. Zkontrolujeme a klikneme na OK. Authenticated Users musí mít právo Read a Read and Execute. Viz obrázek

redirect11

Apply, OK, OK. Pro jistotu doporučuju IIS reset.

A to je všechno. Příště si ukážeme, jak získat zdarma SSL certifikát od autority, která je důvěryhodná ve Windows a většině mobilních zařízení.

Poslední aktualizace - Středa, 2. Ledna 2013 21:22
 
 
 
Page 1 of 1
© TNX alias Jan Kovář. Původní design stránky byl určen pro CMS Joomla! a vytvořen společností Siteground web hosting