www.microsoft.com

Az Exchange 2013 belső és külső URL-jei bizonyos szolgáltatások különböző helyekről – a helyi hálózatról vagy az internetről – való eléréséhez szükségesek. Alapértelmezés szerint a szerver telepítésekor csak a belső URL-ek vannak megadva, és ezek a kiszolgáló fqdn-jére hivatkoznak, míg a külső URL-ek teljesen hiányoznak. .

Ez a cikk az ötödik a sorozatban, amely az Exchange 2013 telepítése utáni konfigurálásához szükséges feladatokat tárgyalja. Ha más feladatok is érdeklik, javasoljuk, hogy olvassa el a konfigurációról szóló fő cikket - vagy a fő témakört -.

Térjünk át a cikk fő céljára – a belső és külső URL-ek megváltoztatására.

Beállítás

Ehhez lépjen a könyvtárba EAC - Szerverek\Szerverek- válassza ki a kívánt szervert az egérrel (az exch02 nálam van) \\ változás(ceruza ikon) - Mobil Outlook.

A terepen Adjon meg egy külső gazdagépnevet (például contoso.com), amellyel a felhasználók csatlakozhatnak a szervezethez. előírjuk a szükséges külső címet. Nekem a mail.bissquit.com lesz. Ezenkívül nem lesz felesleges a belső csomópont nevét ugyanarra módosítani. Ön dönti el, hogy a külső és a belső elnevezések megegyeznek-e vagy eltérőek, de az azonossá tétel több mint logikusnak tűnik.

Ha nem változtatta meg a hitelesítés típusát, egy figyelmeztetés jelenik meg:

Nem rendelkezem az Exchange korábbi verzióival, ezért figyelmen kívül hagyom a figyelmeztetést.

A Powershell-en keresztül ez megtehető a parancsmag segítségével Set-OutlookAnywhere:

PowerShell

Nézzük az eredményt:

Ezután megváltoztatjuk a virtuális könyvtárak beállításait úgy, hogy külső URL-t adunk hozzájuk (alapértelmezés szerint nincs ilyen), és ugyanazt a címet állítjuk be a belső kapcsolatokhoz. Az EAC webes felületén keresztül elvégezheti a megfelelő műveleteket a címtárban Szerverek\Virtuális könyvtárak- válassza ki a kívánt könyvtárat az egérrel, kattintson változás(ceruza ikon), állítsa be a szükséges belső és külső URL-eket.

Ismételje meg a lépéseket minden virtuális könyvtárra, kivéve Automatikus felfedezés (alapértelmezett webhely). Példa a virtuális könyvtár tulajdonságainak megváltoztatására ecp ‎(alapértelmezett webhely)‎:

Elég sok parancs lesz a beállítások módosításához a PowerShell-en keresztül, mivel minden virtuális könyvtártípushoz külön parancsmagkészlet tartozik:

A vezérlőpult virtuális könyvtárának megváltoztatásához − Set-EcpVirtualDirectory.
Az Exchange Web Services virtuális könyvtárának módosítása − Set-WebServicesVirtualDirectory.
A Microsoft Exchange ActiveSync szolgáltatások virtuális címtárának módosítása − Set-ActiveSyncVirtualDirectory.
Az offline címjegyzék virtuális könyvtárának módosítása − Set-OabVirtualDirectory.
A virtuális Outlook módosításához − Set-OwaVirtualDirectory.
A PowerShell virtuális könyvtárának módosítása − Set-PowerShellVirtualDirectory.

Szóval a lényegre térve:

PowerShell

Set-EcpVirtualDirectory "exch02\ecp (alapértelmezett webhely)" -InternalUrl https://mail.bissquit.com/ecp -ExternalUrl https://mail.bissquit.com/ecp Set-WebServicesVirtualDirectory "exch02\EWS (Default Web Site) ) )" -InternalUrl https://mail.bissquit.com/EWS/Exchange.asmx -ExternalUrl https://mail.bissquit.com/EWS/Exchange.asmx Set-ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (alapértelmezett) Webhely)" -InternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync -ExternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync Set-OabVirtualDirectory "exch02\OAB (alapértelmezett webhely) " -InternalUrl https://mail.bissquit.com/OAB -ExternalUrl https://mail.bissquit.com/OAB Set-OwaVirtualDirectory "exch02\OWA (alapértelmezett webhely)" -InternalUrl https://mail.bissquit. com /owa -ExternalUrl https://mail.bissquit.com/owa Set-PowerShellVirtualDirectory "exch02\PowerShell (alapértelmezett webhely)" -InternalUrl https://mail.bissquit.com/PowerShell -ExternalUrl https://mail. bissquit .com/PowerShell

Állítsa be az -EcpVirtualDirectory-t "exch02\ecp (alapértelmezett webhely)"-Belső URL https://mail. keksz. com/ecp-ExternalUrl https://mail. keksz. com/ecp

Állítsa be a -WebServicesVirtualDirectory-t "exch02\EWS (alapértelmezett webhely)"-Belső URL https://mail. keksz. com/EWS/Exchange. asmx -ExternalUrl https://mail. keksz. com/EWS/Exchange. asmx

Állítsa be az -ActiveSyncVirtualDirectory-t "exch02\Microsoft-Server-ActiveSync (alapértelmezett webhely)"-Belső URL https://mail. keksz. com/Microsoft-Server-ActiveSync-ExternalUrl https://mail. keksz. com/Microsoft-Server-ActiveSync

Állítsa be az -OabVirtualDirectory-t "exch02\OAB (alapértelmezett webhely)"-Belső URL https://mail. keksz. com/OAB-ExternalUrl https://mail. keksz. com/OAB

Állítsa be az -OwaVirtualDirectory-t "exch02\OWA (alapértelmezett webhely)"-Belső URL https://mail. keksz. com/owa-ExternalUrl https://mail. keksz. com/owa

Állítsa be a -PowerShellVirtualDirectory-t "exch02\PowerShell (alapértelmezett webhely)"-Belső URL https://mail. keksz. com/PowerShell-ExternalUrl https://mail. keksz. com/powershell

Térjünk át a következő fejezetre.

Helyi DNS-kiszolgáló beállításai

Mivel ugyanazt a belső és külső URL-címet adtuk meg az Exchange 2013 szolgáltatásokhoz, ki kell találnunk, hogyan kell helyesen konfigurálni a helyi DNS-kiszolgáló rekordjait (előre tekintve azt mondom, hogy ezt Split DNS-nek hívják).

Jegyzet: a helyzet az, hogy a mail.bissquit.com tartomány az átjáró külső címére oldja fel, így kialszik, és amikor eléri az átjárót, visszafordul helyi hálózat. Nincs ebben semmi szörnyű, de ez egyértelműen egy extra útvonal, amely átmegy a helyi hálózatról az Exchange 2013-ra irányított összes forgalomon.

A tartományvezérlőn lépjen a DNS beépülő modulba, és hozzon létre egy új továbbítási keresési zónát:

Alapból minden beállítást meghagyunk, csak a szükséges nevet tüntetjük fel, nekem ez a bissquit.com. A zóna létrehozása után egy CNAME rekordot kell hozzáadni. A mail.bissquit.com címre van szükségünk az Exchange 2013 szerver belső címének feloldásához:

Jegyzet: vegye figyelembe, hogy egy második szintű tartomány hozzáadása a szolgáltatáshoz rendkívül rossz ötlet lehet, ha ez a tartomány (vagy altartományai) külső erőforrásokhoz vannak kötve. Ebben az esetben a helyi DNS-kiszolgáló felelősnek tekinti magát az egész zónáért, és azt a választ adja, hogy például a tartományi hely nem létezik.

A bejegyzés létrejött, nézzük meg, hogyan működik:

A mail.bissquit.com név belső címre oldódik fel, minden rendben, ahogy kell. Ha azonban megpróbálunk „pingelni” egy másik aldomaint, amelyhez nem hoztunk létre rekordokat az új zónában, a név nem oldható fel. Ennek az az oka, hogy DNS-szerverünk a teljes bissquit tartományért felelősnek (hatóságinak) tekinti magát. A webhelyrekordra vonatkozó DNS-lekérdezéseket delegálással küldheti ki kívülre:

Adja meg a kívánt domaint a névben:

Ezután írjon egy (vagy még jobb, ha több) szolgáltatója NS-kiszolgálóit, amelyekről a DNS-rekordokat kezeli. Ha nem ismer NS szervereket, futtassa az nslookup parancsot, állítsa be a rekord típusát (set type=ns), írja be a szükséges Domain név(Nekem ez a bissquit.com):

Ellenőrizzük még egyszer:

Mint látható, minden működik. Köszönjük a cikket Alexey blogján. Ennek a módszernek egy kis hátránya, hogy manuálisan kell regisztrálnia minden külső aldomaint. Igaz, nekem eddig kevés van belőlük, csak egy.

Tehát ezzel befejeződik a DNS beállítás. Általánosságban elmondható, hogy a DNS-kiszolgáló adminisztrációja csak közvetve kapcsolódik a belső és külső URL-ek beállításához, de ez egy fontos szempont, amelyet figyelembe kell venni, mivel a Technet dokumentációja az URL-ek beállításakor csak általános információkat ad arról, hogy milyen DNS-rekordokat kell létrehozni, de hogyan. nem magyarázza meg, hogy meg kell csinálni, és mik az árnyalatok:

Miután konfigurálta a belső URL-címet a Client Access kiszolgáló virtuális könyvtáraiban, be kell állítania a magán DNS-rekordokat az Outlook Web App és más csatlakozási lehetőségek számára. A konfigurációtól függően a privát DNS-rekordokat úgy kell konfigurálnia, hogy azok a belső vagy külső IP-címre vagy az ügyfél-hozzáférési kiszolgáló teljes tartománynevére mutassanak. Az alábbiakban példák láthatók azokra az ajánlott DNS-rekordokra, amelyeket létre kell hoznia a belső ügyfelek csatlakoztatásához.

FQDN DNS rekordtípus Jelentése
Mail.contoso.com CNAME ex2013CAS.corp.contoso.com
owa.contoso.com CNAME ex2013CAS.corp.contoso.com

Levelezési szolgáltatás beállítása Exchange 2010 alapján.

Úgy gondolják, hogy a hálózat nem rendelkezik elég részletes utasításokkal az Exchange 2010 kiszolgáló külső levelekkel való működéséhez való konfigurálásához. Ebben a cikkben megpróbálom a lehető legrészletesebben és elérhetőbben leírni az Exchange Server 2010 konfigurálásának folyamatát, hogy az Edge Transport Serveren keresztül külső e-mailekkel működjön.
Annak érdekében, hogy valóban teljes, lépésenkénti útmutatót készítsünk, menjünk végig a külső levelezés beállításának folyamatán a kezdetektől fogva. Ez a folyamat általában három fő szakaszból áll:

A cég domain nevének regisztrációja;
MX rekord beállítása a tartománynevet kiszolgáló DNS-kiszolgálón;
Exchange-kiszolgáló konfigurálása külső tartomány használatára.

Az első pontnál nem fogunk kitérni, mert. a cégek túlnyomó többsége már rendelkezik saját domain névvel az interneten, és akinek még nincs, az könnyedén megvásárolhatja bármelyik regisztrátortól (például RU-CENTER www.nic.ru). A domain név regisztrációja után meg kell találnia és regisztrálnia kell a domain beállításokban legalább két DNS szervert, amely kiszolgálja azt, ezt megteheti a regisztrátornál is, vagy használhat ingyenes DNS szervereket (pl. http:/ /freedns.ws /en/).
Az első szakasz befejeződött, most be kell szereznie a szervezet statikus IP-címét a szolgáltatótól, és folytathatja a második szakaszt - egy MX rekord beállítását a külső tartományt kiszolgáló DNS-kiszolgálón. Az MX rekord (Mail Exchange – levelezőszerver) határozza meg azt a levelezőszervert, amely kezeli a leveleket a domainben.

Szerkessze a zónát a DNS-kiszolgálón az alábbiak szerint:

Regisztrálunk egy A-rekordot, például a mail.firma.ru címet, és megadjuk hozzá azt a külső IP-címet, amelyen az Exchange-kiszolgáló közzétételre kerül;
Regisztrálunk egy MX rekordot, és megadjuk a gazdagép nevét - mail.firma.ru.

Megjegyzés: Ha most hozott létre egy zónát a domainhez, akkor ne gondolja, hogy a ping firma.ru azonnal a kívánt IP-címre mutat, mert elég hosszú időbe telhet, amíg az összes internetes DNS-kiszolgáló „tud” az elvégzett változtatásokról .

Az elvégzett beállítások helyességének ellenőrzéséhez a parancsot kell használni nslookup a következő módon:

Ellenőrizzük a domain MX rekordját (például mail.ru):

nslookup -type=mx mail.ru

Ennek eredményeként megtudtuk, hogy az e-mail tovább mail.ru átmegy a gazdán mxs.mail.ru .

A gazdagép IP-címének ellenőrzése mxs.mail.ru :

nslookup mxs.mail.ru 8.8.8.8

Megjegyzés: Ebben a példában ellenőrizzük, hogy nem a helyi DNS-szerverünk „tud” az mxs.mail.ru gazdagépről, hanem a Google DNS-kiszolgálója (8.8.8.8).

1. ábra: Az MX rekord ellenőrzése.

Ha minden megfelelően van konfigurálva, és a tartomány MX rekordja a kiszolgáló külső IP-címére oldódik fel, akkor közvetlenül folytathatja az Exchange beállítását.
Exchange szerver közzététele.

Két lehetőség van Exchange-kiszolgáló közzétételére az interneten:

Szerepkör szerver Hub Közlekedés a vállalkozás helyi hálózatában található, és a vállalati internetes átjárón keresztül az interneten közzéteszik;
A szerepkörrel rendelkező kiszolgáló közzétételre kerül az átjárón Edge Transport, amely ben található DMZ zónaés továbbítja a leveleket a helyinek Hub Közlekedés.

Ez a cikk megvizsgálja a második és (szerintem) leghelyesebb lehetőséget az Exchange-kiszolgáló közzétételére. A séma lehetséges hátránya, hogy további licencet kell vásárolnia az Exchange Server 2010-hez, és további Windows Server 2008-at kell telepítenie.
Megjegyzés: A Windows Server licencek és hardverköltségek megtakarítása érdekében a kis- és közepes szervezetek telepíthetik a Edge Transport közvetlenül a futó átjáróhoz Threat Management Gateway (TMG), ezt a konfigurációt a Microsoft hivatalosan is támogatja, így mi így fogjuk csinálni (az Edge-t nem tudod feltenni az ISA szerverre). Az Exchange 2010 Edge Transport TMG-re történő telepítéséről itt olvashat bővebben: http://www.alexxhost.ru/2010/04/exchange-server-2010-edge-server.html.

Ennek eredményeként az Exchange szervezeti diagramja így fog kinézni:

2. ábra: Exchange szervezeti diagram.

Ebben a cikkben nem foglalkozom az Exchange 2010 kiszolgálók és szerepkörök telepítésének folyamatával, mert ebben nincs semmi bonyolult, és ezt a témát már nem egyszer leírták más forrásokban. Koncentráljunk a konfigurációra.
Levélváltás az Edge Transporton keresztül

A konfigurálás megkezdése előtt gondoljuk át, hogy a szélső levelezőszerver (Edge) hogyan működik együtt a helyi hub-kiszolgálóval (Hub). A kiszolgálók közötti üzenetváltáshoz az Exchange csatlakozókat (összekötőket) használ, és ezeket kell konfigurálni a megfelelő levélváltáshoz. A 3. ábra szemlélteti az üzenetek fogadásának és küldésének folyamatát az Edge Transport edge szerveren keresztül:

3. ábra: Üzenetváltás Edge Transporton keresztül.

Ennek eredményeként 6 csatlakozót használnak:

Külső levelek fogadása az Edge szerver által;
Levelek küldése az Edge szerverről a Hub szerverre;
Hud-szerver, amely leveleket fogad az Edge-szervertől;
Helyi levelek küldése az internetre az Edge szerveren keresztül;
Levelek fogadása az Edge szerver által a Hub szerverről;
Levelek küldése az internetre az Edge szerver által.

A séma első pillantásra nem egyszerű, de az Exchange szerver fejlesztői gondoskodtak a rendszergazdákról, és létrehoztak egy eljárást az Edge Transport szerver előfizetésére ( Edge előfizetés), melynek eredményeként minden egyéb beállítás mellett automatikusan létrehozhatja a szükséges küldési csatlakozókat.
Az Edge Transport Server hálózati beállításainak konfigurálása

Az előfizetés előtt megfelelően konfigurálnia kell a kiszolgáló hálózati beállításait az Edge Transport szerepkörrel. Hadd emlékeztesselek arra, hogy ebben a forgatókönyvben nem szerepel a vállalat tartománystruktúrájában, hanem a DMZ zónában található, és ugyanazon a szerveren található, mint a TMG (ne felejtse el helyesen konfigurálni a TMG szabályait a levelek küldéséhez/fogadásához ). E forgatókönyv alapján a következő beállítások elvégzése javasolt:

Szerezzen be a szolgáltatótól és telepítse a külső interfészen szerver IP-címe (amelyre a korábban konfigurált MX rekord mutat), maszk, átjáró és a szolgáltató szervereinek DNS-címei;
Ha nincs saját DNS-kiszolgálója a DMZ zónában, akkor be kell írnia a fájlba otthont ad a \%Systemroot%\System32\Drivers\Etc mappában, leképezve a Hub Transport szerver nevét az IP-címére, pl. adjunk hozzá egy ehhez hasonló sort a fájl végéhez 192.168.0.10 hub.domain.local;
A felületen keres a helyi hálózatra a vállalatok beállítják az IP-címet és a maszkot. NEM kell belépnie egy átjáróba;
Állítsa be a számítógép nevét és DNS-utótagját a 4. ábrán látható módon. (akkor nem tudja módosítani ezeket a beállításokat);

4. ábra: A szerver DNS-utótagjának beállítása.

A helyi DNS-kiszolgálón hozzon létre egy A-rekordot, amely az Edge-kiszolgáló IP-címére mutat.

Ennek eredményeként az Edge szervernek fel kell tudnia oldani a Hub Transport szerepkörrel rendelkező kiszolgáló internetes címét és címét, a Hub Transport szervernek pedig tudnia kell, hogyan találja meg az Edge szervert az FQDN neve alapján (Ön használhatja a parancsokat pingés nslookup).
Edge előfizetéses kialakítás

Mint fentebb tárgyaltuk, olyan számítógép, amelyen telepítve van az Edge Transport kiszolgálói szerepkör nem fér hozzá az Active Directoryhoz. Minden konfigurációs és címzett információ a Lightweight Directory Services egy példányában ( AD LDS) Active Directory. Ezt a szolgáltatást előre telepíteni kell, az 5. ábra szerint.

5. ábra: Lightweight Directory Service (AD LDS) telepítése.

A címzett keresési feladatok végrehajtásához az Edge Transport kiszolgálónak olyan adatokra van szüksége, amelyek az Active Directoryban találhatók. Ezek az adatok szinkronizálva vannak az Edge Transport szerverrel az EdgeSync segítségével. EdgeSync olyan folyamatok gyűjteménye, amelyek Hub Transport szerver szerepkörrel rendelkező számítógépen futnak a címzett és konfigurációs információk egyirányú replikációjának megszervezésére az Active Directoryból az AD LDS-be egy Edge Transport kiszolgálón.
Az AD LDS telepítése és a hálózati beállítások megfelelő konfigurálása után megkezdheti az Edge és a Hub Transport kiszolgálók konfigurálását, hogy együttműködjenek. Ennek érdekében Edge-előfizetést adunk ki az alábbiak szerint:

Az Edge Transport szerepkörrel rendelkező kiszolgálón futtassa a következő parancsot:

New-Edge Subscription – Fájlnév c:\edge_subscr.xml

6. ábra: Edge előfizetés létrehozása.

Fogadott fájl edge_subscr.xml másolás a helyi Hub Transport szerverre;
Menjünk-hoz Exchange Management Console-> szakasz Szervezet konfigurációja-> akció Új Edge előfizetés…

7. ábra: Edge-előfizetés létrehozása a Hub Transport szerveren.

Válassza ki a kívánt AD oldalt és XML fájl előfizetések. Ne felejtse el bekapcsolva hagyni a jelölőnégyzetet a küldési összekötők automatikus létrehozásához.
A varázsló befejezése után létrejön a küldési összekötők, és egy idő után megtörténik a szinkronizálás az Edge Transport szerverrel. Annak érdekében, hogy ne várjon a szinkronizálási munkamenetre, ezt manuálisan is megteheti a következő paranccsal:

Start-EdgeSynchronization

Az Exchange 2010 speciális beállításainak konfigurálása

Noha az Edge Subscription folyamat nagyban megkönnyíti a rendszergazdák életét, nem végez minden munkát helyettük. Néhány beállítást manuálisan kell elvégezni:
Csatlakozók létrehozása

Ahogy fentebb említettük, ahhoz, hogy sikeresen válthasson leveleket az Edge szerveren keresztül, legalább 6 csatlakozóval kell rendelkeznie. Nézzük, melyek vannak alapértelmezésben:

8. ábra: Fogadási csatlakozó az Edge Transport Server-en

Alapértelmezés szerint egy összekötő jön létre az Edge Transport kiszolgálón, amely bármilyen hálózati interfészről, illetve külső és belső IP-címről fogad leveleket. 1 és 5 ábra diagramjából már rendelkezünk.
Nézzük meg a küldési csatlakozókat:

9. ábra: Küldési csatlakozók

Az Edge Subscription létrehozása során a küldési csatlakozók létrehozásának lehetőségét engedélyezve hagytuk (lásd a 7. ábrát). Most láthatjuk a Hub Transport tulajdonságaiban, szervezeti szinten, ez a két automatikusan létrehozott összekötő. Mivel ezek a csatlakozók szervezeti szintűek, így ennek megfelelően a tartomány összes többi Exchange szerverén is meglesznek, ez alól az Edge Transport sem kivétel, az egyetlen különbség az lesz, hogy az Edge-en csak olvashatóak (csak olvashatók). . Ennek eredményeként a csatlakozó Alapértelmezett-First-Site-Name az Internetre feladatokat lát el 4és 6 csatlakozók a rendszerünkből, és Bejövő a Default-First-Site-Name címre – 2.
Így a hatból öt csatlakozónk van. Nincs elég vevőcsatlakozó a Hub Transport szerveren (3. a diagramon), vagy inkább - Alapértelmezett HubName, de, IMHO, helyesebb lenne külön készíteni. Fogadási csatlakozó létrehozásához lépjen a szintre szerver konfigurációk, válasszon szerepet Hub Közlekedésés a művelet menüben nyomja meg a gombot Új fogadási csatlakozó.

10. ábra: Fogadási csatlakozó létrehozása a Hub Transport Serveren.

Írja be a csatlakozó nevét, és jelezze, hogy az lesz Belső, azaz szervezetünk Exchange szervereivel fog működni. A varázsló következő lépésében megadjuk, hogy a leveleket a szerver IP-címéről kell fogadni Edge Transport. A létrehozást a gomb megnyomásával fejezzük be Új.
A csatlakozási szoftverekkel végzett munka után folytassuk a levelek fogadására vonatkozó szabályzatok létrehozását.
Elfogadott domain és e-mail cím házirend létrehozása

Elfogadott domain bármely SMTP névtér, amelyhez a Microsoft Exchange szervezet e-maileket küld és fogad. Tekintettel arra, hogy külső domain nevünk eltér a helyitől (firma.ru és domain.local), fel kell venni egy elfogadott domaint szervezeti szinten. firma.ru, hogy az Exchange szerver működhessen vele.
Ehhez lépjen a szintre szervezet konfigurációja -> Hub Közlekedés -> Elfogadott domain.

11. ábra: Új elfogadott tartomány létrehozása.

A varázslóban írja be az elfogadott tartomány megjelenített nevét, adja meg magát a tartományt, és jelezze, hogy a tartomány lesz Irányadó, mert a címzett postafiókjai ebben az SMTP-tartományban találhatók.
Ahhoz, hogy a felhasználó fogadhasson és küldhessen leveleket az elfogadott domaineken keresztül, további e-mail címeket kell létrehoznia, ami az e-mail-címekre vonatkozó házirendekkel történik.
E-mail címekre vonatkozó szabályzat szervezeti szinten jönnek létre a Hub Transport szerepkör tulajdonságaiban a művelet kiválasztásával Új e-mail-címekre vonatkozó szabályzat…

12. ábra: E-mail cím házirend hozzáadása.

A házirendet minden típusú címzettre alkalmazni kell, szűrők nélkül, a kívánt FQDN névhez kötve (lásd a 12. ábrát), és meg kell adni az azonnali végrehajtás ütemezésében (Azonnal). Ennek eredményeként az e-mail cím szabályzat, ha egy Elfogadott tartományhoz van kötve, automatikusan létrehozza a megfelelő e-mail címeket minden olyan címzett számára, akire vonatkozik.
Megjegyzés: A címzettek további címeinek létrehozása nem történik meg azonnal, ezért, hogy ne várjon, saját maga is hozzáadhat egy e-mail címet a postafiók tulajdonságaihoz, vagy futtathatja a parancsmagot. Update-EmailAddressPolicy.

Két házirendet kell létrehoznia – egyet a tartományhoz firma.ru, másik számára domain.local. Ennek eredményeként a szervezetben minden címzettnek 2 e-mail címe lesz, ill visszaküldési címként, az alacsonyabb prioritású házirendhez tartozó lesz használva.
Ezzel befejeződik a Hub Transport szerverrel végzett munka, és áttérhet az Edge Transportre.
Cím újraírása

Tekintettel arra, hogy a külső domain és az AD domain nevek különböznek, át kell írnunk a címeket a bejövő és kimenő üzenetekben ( *.ru<->*.helyi). A Microsoft Exchange Server 2010 rendelkezik erre a célra szolgáló funkcióval cím átírása, amely lehetővé teszi a feladók és a címzettek címének megváltoztatását a bejövő és kimenő üzenetekben. További információ ezt a funkciót itt olvasható - http://technet.microsoft.com/ru-ru/library/aa996806.aspx.
Cím-újraírási házirend hozzáadásához használja a parancsmagot New-AddressRewriteEntry szerveren Edge Transprot:
New-AddressRewriteEntry -Név "Lan - Internet" -Belső cím "domain.local" - ExternalAddress "firma.ru"

13. ábra: Cím átírási szabályzat hozzáadása.

Megjegyzés: Ez a házirend nem kerül alkalmazásra azonnal; az azonnali aktiváláshoz manuálisan indíthatja újra a Microsoft Exchange Transport szolgáltatást.

Lehetséges problémák

Ezzel befejeződik az Exchange Server 2010 alapkonfigurációja, hogy a vállalati DMZ zónában található Edge Transport kiszolgálón keresztül külső levelekkel működjön együtt. A következő lépés az e-mail küldésének és fogadásának ellenőrzése. Ha valamilyen oknál fogva nem küldik el vagy nem kapják meg a levelet, akkor azt tanácsolom, hogy kezdje a következő lépésekkel:

Használja a varázslót Távoli kapcsolatelemző menüben található Eszköztár. Ez a varázsló a http://testexchangeconnectivity.com/ oldalra viszi, ahol számos Exchange-szolgáltatást tesztelhet.
Üzenetsor megtekintése Toolbox -> Queue Viewer annak meghatározása érdekében, hogy a levél melyik szakaszban ragadt meg. Ez a segédprogram nem csak az üzenetsort tudja megjeleníteni, hanem az adott sorral kapcsolatos legutóbbi hibák szövegét és a benne lévő üzenetek fejléceit is.
Csapat telnet YourServer 25 segít ellenőrizni, hogy a szerverei rendelkezésre állnak-e levelek fogadására.
Ha DNS-problémákat talált a Queue Viewerben, akkor valószínűleg nem megfelelően konfigurálta az interfészek hálózati paramétereit, vagy rosszul szerkesztette azokat host fájl.
Ezenkívül az Edge Transport szerverhez megadhat olyan DNS-kiszolgáló címeket, amelyek eltérnek a hálózati interfészekre telepítettektől, ez a menüben történik. Tulajdonságok kiválasztott szerver - lapok Belső DNS-keresésekés Külső DNS-keresések.
A csatlakozókon ellenőriznie kell a füleket hálózat, Hitelesítésés Engedélycsoport.
A Hub Transporton végzett módosítások után ne felejtse el szinkronizálni ( Kezdő-él szinkronizálás).
Ha a fentiek egyike sem segít, akkor a rendszernaplók elemzése irányába nézhet, és engedélyezheti a Protokollnaplózást az Általános lapon az összekötő tulajdonságai között. A szállítási naplóelemzésről itt olvashat bővebben - http://technet.microsoft.com/ru-ru/library/aa998617.aspx.

A Forefront Threat Management Gateway (TMG) 2010 támogatja a Microsoft Exchange Outlook Web App (OWA) for Exchange 2010, valamint az Outlook Web Access for Exchange 2007, 2003 és 2000 közzétételét. A kétrészes sorozat első részében megnézte, hogyan lehet közzétenni egy CAS-kiszolgálót. A 2. részben az Exchange OWA 2010 TMG használatával történő közzétételéhez szükséges lépéseket ismertetjük. Ha el szeretné olvasni ennek a cikksorozatnak az első részét, keresse fel az Exchange Outlook Web App (OWA) közzététele című részt a Microsoft Forefront Threat Management Gateway (TMG) 2010: 1. rész – Az ügyfél-hozzáférési kiszolgáló (CAS) előkészítésében.

Bevezetés

Tanúsítvány importálása

Az OWA közzététele előtt először importálnunk kell a webhely SSL-tanúsítványát a TMG tűzfalba. A feladat végrehajtásához lépjen a menübe Indítás / Futtatásés lépj be mmc.exe. A legördülő listából válassza ki Fájl / Beépülő modul hozzáadása vagy eltávolítása. Választ Tanúsítványok, majd nyomja meg Hozzáadás.

Válassz egy lehetőséget Számítógépes fiók.

Válassza ki a helyi számítógép kezelésének lehetőségét (helyi számítógép).

Bontsa ki a csomópontot a konzolfában Tanúsítványok. A mappa kibontása Személyes, kattintson a jobb gombbal a mappára Tanúsítványokés válassz Importálás

Adja meg a korábban exportált tanúsítványfájl helyét.

Adja meg a jelszót, és (opcionálisan) jelölje meg a privát kulcsot exportálhatóként.

Fogadja el az alapértelmezett beállítást Helyezze el az összes tanúsítványt a következő áruházban.

Hozzon létre egy OWA közzétételi szabályt

A TMG felügyeleti konzolon kattintson a jobb gombbal a tűzfal házirend csomópontjára (Tűzfalszabályzat) a konzolfában, és válassza ki Új (új), és akkor Exchange Web Client Access Publishing Rule

Adjon értelmes nevet a közzétételi szabálynak.

Választ Exchange Server 2010 a legördülő listából, és válassza ki a közzétételi lehetőséget Outlook Web Access.

Demonstrációs célból egy CAS-szervert teszünk közzé, ezért ezt a lehetőséget választjuk Egyetlen webhely vagy terheléselosztó közzététele.

Válassza az SSL használata lehetőséget a közzétett webszerverhez vagy kiszolgálófarmhoz való csatlakozáshoz.

Adjon meg egy nevet belső weboldal.

Válassza ki az adott tartományra vonatkozó kérelmek elfogadásának beállítását, majd írja be nyilvános név weboldal.

Válassz egy lehetőséget Válassza a Tanúsítvány lehetőségetés adja meg a korábban importált tanúsítványt.

Válassz egy lehetőséget Használjon HTML űrlap hitelesítéstés Windows (Active Directory) hitelesítő adatok ellenőrzésére.

Ha szükséges, engedélyezze az egyszeri bejelentkezést.

A TMG tűzfal által használt hitelesítési módszer meg kell egyeznie a weboldalon konfigurált hitelesítési módszerrel. Mivel az egyszerű hitelesítést engedélyeztük a weboldalon, ezt a lehetőséget választjuk Alapszintű hitelesítés itt.

Ha az OWA-hoz való hozzáférést bizonyos felhasználókra és/vagy csoportokra szeretné korlátozni, kérjük, adja hozzá őket ide. Ellenkező esetben fogadja el a csoportot Minden hitelesített felhasználó alapértelmezett.

A művelet megerősítéséhez nyomja meg a gombot Tesztszabály.

A TMG teszteli a szabályt, és beszámol arról, hogy működik-e vagy sem.

Következtetés

Az Exchange Client Access Server (CAS) előkészítése után a sorozat első részében, a második részben konfiguráltuk a Forefront Threat Management Gateway-t (TMG) az Exchange Outlook Web App 2010 biztonságos közzétételéhez. Importáltuk az SSL-tanúsítványt, és végigjártuk a Exchange Web Client Access Publishing Rule Wizard Publishing Rule, és a TMG diagnosztikai szolgáltatását is használta annak ellenőrzésére, hogy a közzétételi szabály megfelelően van beállítva.

Az enyém a http://spravka.zhavoronki.biz webhelyről

24.12.2012

Ez a cikk az OWA-szegmentációra összpontosít, amely a felhasználó számára az OWA-felületen keresztül elérhető összetevők korlátozására szolgál, valamint az OWA bejelentkezési és kilépési képernyőinek testreszabására.

William Lefkowitz ([e-mail védett]) a Mojave Media Group műszaki igazgatója, valamint üzenetküldési és együttműködési technológiákról szóló cikkek szerzője. MCSE minősítéssel és Microsoft Exchange MVP címmel

Az Exchange Server 2010 Outlook Web App (OWA) az Outlook Web Access új neve, amely az Exchange Server 5.0 megjelenése óta körülbelül 15 éve létezik. Az Exchange Server OWA-val való első munkamenetének vége óta a rendszergazdák folyamatosan egyedi funkciókat akartak biztosítani az OWA számára, még a támogatott testreszabásokon túl is. Az OWA módosításai a színek módosításától a teljes márkamódosításon át egészen a kezelőfelület radikális átalakításáig terjednek. Az, hogy mennyire egyszerű az OWA konfigurálása, az Exchange Server verziójától, a rendelkezésre álló konfigurációs eszközöktől és a rendszergazda tapasztalatától függ.

Az OWA modern verziója jelentősen eltér az Exchange 5.0 és 5.5 egyszerű Active Server Pages (ASP) alkalmazásától. Az Exchange Server 2007-ben bevezetett Microsoft Exchange Web Services segítségével az Exchange-adatok számos olyan forrásból érhetők el, amelyek kompatibilisek a Web Services API-val. Az Exchange Web Services szolgáltatással rendelkező Exchange Server 2010 megkönnyíti az Exchange Server adatainak eléréséhez szükséges egyéni webalkalmazások tervezését. Az Exchange 2007 négy felhasználó által választható témát ad az OWA-hoz. Az Exchange Server 2010 RTM nem valósítja meg az OWA konfigurációs beállításait; a régi Exchange 2007 témák továbbra is jelen vannak a telepítésben, de nem működnek. Az OWA-beállítások csak az Exchange Server 2010 Service Pack 1 (SP1) szervizcsomagban tértek vissza. A jelenlegi Exchange Server 2010 SP2 szervizcsomagban nincsenek más OWA-beállítások, mint amelyeket ebben a cikkben tárgyalunk.

A Microsoft megközelítése az OWA konfigurálásához

A szóban forgó OWA-módosítások közül sok megköveteli, hogy a meglévő fájlokat lecserélje a frissítettekre. Amikor témákkal, egyszerű lépcsőzetes stíluslapokkal (CSS), valamint bejelentkezési és kilépési képernyőkkel dolgozik, a változások fájlszinten történnek. Amikor a Microsoft frissíti az Exchange Server kiszolgálót – a hibák kijavítása, gyorsjavítások vagy szervizcsomagok alkalmazása – a vállalat nem garantálja, hogy a változtatások mentésre kerülnek. Az sem garantált, hogy a programkód frissítései nem befolyásolják a felhasználó által végzett testreszabásokat. Ezért archiválnia kell beállításait, és meg kell győződnie arról, hogy a frissítések alkalmazása után az OWA beállításai működni fognak. A Microsoft által az Exchange 5.5-ig terjedő összes OWA-beállításokra vonatkozó megközelítést az Outlook Web Access for Exchange testreszabására vonatkozó Microsoft támogatási szabályzat ismerteti (http://support.microsoft.com/kb/327178). Az is jó ötlet, ha a testreszabásait – akár teljes egyéni OWA-alkalmazásokról, akár fájlszintű bejelentkezési képernyő-módosításokról van szó egy márkás képernyőhöz – egy laborban fejleszti és teszteli, mielőtt a munkát élesre helyezi át.

Szegmentáció

A szegmentálás az OWA testreszabásának teljes mértékben támogatott módszere. A szegmentálásnál az adminisztrátor egyszerűen meghatározza, hogy mely OWA-összetevők láthatók a végfelhasználó számára. Sok vállalat szeretné, ha felhasználói az OWA-kliensen keresztül hozzáférnének a szolgáltatások teljes skálájához. Előfordulhat azonban, hogy egyes felhasználóknak csak korlátozott számú szolgáltatásra van szükségük napi tevékenységeikhez. Például nem is olyan régen egy gyárban dolgoztam, ahol a dolgozóknak e-mailekhez és névjegyekhez kellett hozzáférniük, de nem a naptárhoz, a feladatokhoz vagy a nyilvános mappákhoz. Az OWA-hoz való korlátozott hozzáférés megakadályozhatja, hogy a felhasználók bizalmas vagy jogosulatlan információkat fedjenek fel vagy lássanak. Az opcionális komponensekhez való hozzáférés korlátozása hatókör vagy szabályzat alapján szintén jó biztonsági technika, amely csökkenti a kockázati felületet. Ezenkívül a szegmentálás csökkentheti az OWA-munkamenetek által használt sávszélességet.

Alapértelmezés szerint az OWA olyan Exchange 2010 kiszolgálón érhető el, amelyen telepítve van a Client Access kiszolgálói szerepkör. A szegmentálás nem igényel semmit további beállítások. Az Exchange 2007-ben a szegmentálás egyszerűen kezelhető az Exchange Management Console (EMC) segítségével. A szegmentálás az EMC Client Access kiszolgálóján keresztül történik.

Az EMC-konzolon keresse meg az OWA-t kiszolgáló Client Access kiszolgálót, kattintson jobb gombbal az OWA webhelyére, és válassza a Tulajdonságok lehetőséget. A Szegmentálás lap (1. ábra) felsorolja azokat az OWA-szolgáltatásokat, amelyeket a Client Access kiszolgáló felhasználói letilthatnak és engedélyezhetnek (az 1. táblázat felsorolja az elérhető szolgáltatásokat). Válassza ki és engedélyezze az egyes funkciókat egyenként.

Az Exchange Server 2010 bevezette az OWA postafiók-házirendeket. Ezekkel a házirendekkel a rendszergazdák szegmentálást alkalmazhatnak az egyes felhasználókra vagy felhasználói csoportokra, nem pedig mindenkire, aki egy adott ügyfél-hozzáférési kiszolgálón csatlakozik az OWA-hoz. Bár a szolgáltatás neve „postafiók”, ezek a házirendek technikailag nem a postafiókokra vonatkoznak, hanem a postafiókban lévő adatok elérésére használt webalkalmazásra. Amikor a Client Access kiszolgálói szerepkör telepítve van, az alapértelmezett OWA postafiók-házirend kerül alkalmazásra. Alapértelmezés szerint az összes felsorolt, szegmentált funkció aktiválva van benne.

Az OWA postafiók-házirendek vállalati szinten vannak konfigurálva az EMC-ben, amint az a 2. ábrán látható. Válassza ki a Client Access elemet az EMC Szervezeti konfigurációs központjában; Az OWA postafiók házirendjei a középső ablaktáblában jelennek meg. Új házirend hozzáadásához kattintson a jobb gombbal a középső ablaktábla üres területére, és válassza ki az Új elemet a helyi menüből, vagy válassza ki közvetlenül az EMC-műveletek ablaktáblából. Ahogy a 2. ábra mutatja, az OWA postafiók házirendjének fő célja egy adott szegmentálási beállítás konfigurálása egy felhasználó vagy csoport számára, mivel a felhasználói felületen nincs más konfigurálandó. Célszerű a házirendnek leíró nevet adni, például azt a régiót vagy részleget, amelyre vonatkozik, vagy egy adott szegmentálási célt szerepeltetni a névben, például nincs napló. A 3. ábra az Outlook Web App Properties ablakát mutatja, ahol egy meglévő OWA-postafiók-házirendet alkalmazhat postafiók vagy dobozok. Az OWA postafiókházirendek az Exchange Management Shell (EMS) vagy a New-OWAMailboxPolicy és a Set-OWAMailboxPolicy parancsok használatával hozhatók létre és módosíthatók.

Amikor ezekkel a parancsokkal új OWA-postafiók-házirendet hoz létre vagy módosít egy meglévő házirendet, be- és kikapcsolhatja az attribútumok listáját. Ezek az attribútumok közvetlenül az 1. táblázatban felsorolt szolgáltatásokra vonatkoznak. Alapértelmezés szerint a szolgáltatások engedélyezve vannak, így általában az OWA-postaláda-házirend EMS-ben történő konfigurálásakor válassza ki a kapcsolóattribútumokat, és állítsa azokat false értékre a letiltáshoz. Az egyes parancsokhoz tartozó attribútumok listáját a Microsoft „Set-OwaMailboxPolicy” (http://technet.microsoft.com/en-us/library/dd297989.aspx) és „New-OWAMailboxPolicy” (http://technet) című cikkében találja. .microsoft. com/en-us/library/dd351067) és a help parancsban.

A szegmentálás az EMS segítségével is konfigurálható szerver vagy felhasználói szinten. A Set-CASMailbox parancs szegmentálást alkalmaz az adott OWA postafiók-házirendben meghatározottak szerint. Például a következő kód egy North America Staff nevű OWA-postafiók-szabályzatot alkalmaz Steve felhasználóra, akinek postafiók-hozzáférése van:

Set-CASMailbox -Identity Steve -OwaMailboxPolicy: "Észak-Amerika munkatársai"

Ha az OWA-postaláda-házirend nevében szóközök vannak, akkor az EMS-ben idézőjelekre van szükség. Ha az Active Directory (AD) azonos nevű szervezeti egységéhez (OU) tartozó összes felhasználóra szeretné alkalmazni az Ügyvezetők nevű OWA-postaláda-házirendet, használja a következő kódot:

Get-CASMailbox -OrganizationalUnit vezetők | Set-CASMailbox -OWAMailboxPolicy:Vezetők

Az EMS használatával listát kaphat azokról a postafiók-hozzáféréssel rendelkező felhasználókról, akikre alkalmazni kívánja az OWA-postaláda-házirendeket a tipikus meglévő attribútumok (például Cím, hely) alapján. Ehhez használja a Get-User parancsot, és a kimenetet a Set-CASMailbox parancshoz vezeti. A Get-Content paranccsal szöveges fájlból is lekérhet adatokat EMS-en keresztül:

Get-Content "c:\files\OWAPolicyList.txt" | Set-CasMailbox -OwaMailboxPolicy "Észak-Amerika munkatársai"

Az OWAPolicyList.txt egy egyszerű szöveges fájl, amely a postafiókok e-mail címeinek listáját tartalmazza, soronként egy címet:

[e-mail védett]

Természetesen adminisztrátorok Microsoft Office 365, EMS-t kell használnia a szegmentálás beállításához a vállalatában. Az Office 365 Exchange-vezérlőpultja (ECP) nem biztosít hozzáférést az OWA-házirend-felügyelethez.

Az Exchange 2010 SP2 visszahozza a Webmail egy korábban eltávolított verzióját: az OWA Minit, amely korábban Outlook Mobile Access (OMA) néven volt ismert, és az Exchange Server 2003-ban került bevezetésre. A frissített OWA Mini egy sor űrlapot tartalmaz az OWA-n belül. Az OWA részeként az OWA Mini (mobilböngészőkhöz) és az OWA Basic (nem tesztelt böngészőkhöz) is felismeri a szegmentációs jelzőket. Azok a felhasználók, akiktől megtagadják a hozzáférést az alapvető mappákhoz, például a Naptárhoz, nem férhetnek hozzá ezekhez a mappákhoz az OWA Mini (4. ábra) vagy az OWA Basic segítségével.

Képernyő 4. OWA Mini

A szegmentálás egyszerűbbé és szigorúbbá teszi az OWA webes felületét a felhasználók számára. Alapértelmezés szerint az OWA a fő Mail, Calendar, Contacts és Tasks mappákat jeleníti meg a böngészőablak bal alsó sarkában. Egyszerű példaként vegyünk egy Steve Bauer nevű felhasználót, aki kezdetben nem alkalmazta az OWA-postafiók-házirendeket, és ezért minden funkciója engedélyezve volt. Alkalmazzunk egy OWA-postafiók-házirendet, amely letiltja a naptárat, a feladatokat és a tárgyválasztást. Az 5. és 6. ábra az interfész különbségeit mutatja a házirend alkalmazása előtt és után.

A szegmentálás szerverszinten is alkalmazható a Set-VirtualDirectory paranccsal. A Set-OWAMailboxPolicy parancshoz hasonlóan engedélyezheti vagy letilthatja az egyes funkciókat. Ebben az esetben mindenki, aki csatlakozik egy adott szerverhez és virtuális könyvtárhoz, például az owához (alapértelmezett webhely), ugyanazt az OWA funkciót fogja látni. Ha bármilyen terheléselosztási módszert használ az OWA-hozzáféréshez több Client Access kiszolgálón keresztül, akkor a szegmentálási beállítások módosításait alkalmaznia kell a készlet összes Client Access kiszolgálójára. Ellenkező esetben a felhasználók különböző OWA-konfigurációkat fognak látni attól függően, hogy melyik ügyfél-hozzáférési kiszolgálóhoz csatlakoznak a terheléselosztáson keresztül.

Végül vegye figyelembe, hogy ha új OWA-postaláda-házirendet hoz létre, vagy módosítja a szerverszintű szegmentálást, és azonnal alkalmazni kívánja a házirendet vagy a módosításokat a felhasználókra, akkor előfordulhat, hogy újra kell indítania az OWA webhelyet. A Microsoft IIS újraindításakor az OWA módosításai is azonnal érvénybe lépnek. Ezt a legjobb tól megtenni parancs sor a szerveren a következő paranccsal:

Iisreset -noforce bejelentkezési és kijelentkezési képernyő testreszabása

Amikor a felhasználók hozzáférnek az OWA URL-címéhez, az első képernyő a bejelentkezési képernyő (kivéve, ha tanúsítási hiba történt). Egyes vállalatok a bejelentkezési és kijelentkezési képernyő testreszabására törekszenek, hogy hangsúlyozzák a márkaépítést, vagy megnyugtassák a felhasználókat, hogy jó helyen vannak. Az ismerős vállalati logóval és színekkel ellátott bejelentkezési képernyő biztos lehet benne, hogy a megfelelő oldalon vannak. A regisztrációs képernyőn is elhelyezhet bizonyos információkat vagy nyilatkozatot. A bejelentkezési vagy kijelentkezési képernyő beállításai nincsenek hatással az OWA alapvető funkcióira.

Az OWA bejelentkezési vagy kijelentkezési képernyői önálló webes űrlapok, amelyek több grafikus fájlt használnak. gif és CSS táblázatok a betűtípusokhoz és a formázáshoz. Az OWA-ba először bejelentkező felhasználók számára van egy további képernyő, amely szintén a beállításoktól függ, mivel ugyanazokat a CSS fájlokat és képeket tartalmazza, mint a bejelentkezési képernyő. A kezdeti bejelentkezési képernyő kilenc gifből áll, amelyek a logon.css szerint vannak elrendezve és elrendezve. A bejelentkezési képernyő egyéb szempontjait szintén a CSS-fájlban található információk határozzák meg, beleértve a betűtípus típusát és a kép GIF-eken kívül használt színeket. Ugyanazok a fájlok érvényesek az első bejelentkezési beállítási képernyőre és a kijelentkezési képernyőre. E fájlok módosításához elég egyszer megtenni; a frissítések mindhárom oldalon megjelennek. A bejelentkezési képernyők szabványos verziói, az első bejelentkezési beállítások és a kijelentkezési beállítások a 7., 8. és 9. képernyőn láthatók.

7. képernyő: Normál regisztrációs képernyő

8. ábra: Normál első regisztrációs képernyő

9. ábra: Tipikus kijelentkezési képernyő

A bejelentkezési és kijelentkezési képernyőkhöz használt fájlok a Client Access kiszolgálói szerepkörrel rendelkező Exchange-kiszolgálón, a \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\\Themes\Resources könyvtárban találhatók. A változó az Exchange Server szintjén található. Az Exchange 2010 SP2 egy 14.2.247.5 feliratú mappát mutat. Az Exchange 2010 SP2 Rollup 1 hozzáadja a 14.2.283.3 mappát. Az OWA a legújabb forrást használja.

Ahogy fentebb említettük, lehetőség szerint a beállításokat laboratóriumban kell tesztelni. Ellenkező esetben próbáljon meg biztonsági másolatot készíteni az eredeti fájlokról, mielőtt módosítja az OWA fájlokat. Szerencsére a Microsoft leíró neveket adott a gif-fájloknak. A 10. ábra a gif-ek eloszlását mutatja a regisztrációs képernyőn; A 2. táblázat felsorolja a képfájlok nevét és méretét (pixelben).

A bejelentkezési képernyő testreszabásának legegyszerűbb módja két lépésben történik: cserélje ki a gifeket megfelelőbb céglogókra, és ennek megfelelően módosítsa a logon.css és owafont.css fájlokat. Természetesen nem csak ezek a felületes változások vannak, de így minimális erőfeszítéssel maximális hatást érhet el. A 7., 8. és 9. ábrán látható Outlook Web App szöveges gif neve lgntopl.gif (a fájlnév jelentése: bejelentkezés, fent, balra). Ezzel a legegyszerűbb dolgozni, ha csak logóját szeretné hozzáadni az OWA szabványos színsémájának megváltoztatása nélkül. A cikk elkészítése során vettem egy gif fájlt, és hozzáadtam egy kitalált Las Vegas Webmail logót, amely a híres Las Vegas feliratot kölcsönözte a nevadai Las Vegas Stripről, ahogy az a 11. ábrán látható. A gif fájl mérete változatlan maradt (456 x 115 pixel), így a Client Access kiszolgálón lévő fájlok egyszerű cseréjének eredményeként az adott Client Access kiszolgálón az OWA-ba bejelentkező felhasználók az új logót fogják látni. Ha eltérő méretű fájlt alkalmaz, és nem módosítja a CSS-fájlt, akkor grafikus formázás következetlen lesz. Az egyes képek helyét az oldalon a CSS fájlban lévő adatok határozzák meg, és a pixelek helyétől függ, így ha módosítja a gif fájlok méretét, akkor ezeket a változásokat figyelembe kell vennie a CSS fájlban. Nyilvánvaló, hogy a regisztrációs képernyő testreszabásához a meglévő képek megjelenésének megváltoztatásán túlmenően bizonyos CSS-ismeretekre van szükség.

11. ábra: Testreszabott OWA bejelentkezési képernyő

A bejelentkezési képernyőn megjelenő szöveg stílusát is a logon.css fájl utasításai határozzák meg. A CSS fájlok egyszerű szöveges fájlok, amelyekben módosítható szöveg szerkesztő vagy a sok CSS-szerkesztő egyike. De ma már minden webfejlesztő program alkalmas a CSS módosítására is. A Microsoft Expression Web nagyszerű eszköz a CSS-fájlok kezeléséhez; A Microsoft Visual Studio hatékony CSS-szerkesztőként is szolgálhat, bár nyilvánvalóan nem jó ötlet csak erre a célra használni. A CSS-ben a színeket hexadecimális színkódok határozzák meg: egy szimbólum (#), amelyet egy 6 jegyű kód követ. A legtöbb CSS-szerkesztő hexadecimális színpalettát kínál. Az interneten is vannak gyors hozzáférésű források (pl. VisiBone). A marketingszakemberek, a művészek és a webprogramozók jellemzően pontos nyomtatási és webes színkódokat határoznak meg, amelyek a vállalati logók színsémáit képviselik.

A 3. táblázat felsorol néhány színt a logon.css fájlban a bejelentkezési képernyőhöz. Ebben a példában a logon.css fájl betűtípusát narancssárgáról bíborra, a felhasználónév és jelszó beviteli mező hátterét pedig világos narancsról világosszürkére változtattam. A beviteli mezők körüli szegélyt is kiemeltem úgy, hogy a ritka szürke színt gazdagabb kékre cseréltem, megváltoztattam a színkódot, és növeltem a szegély pixelfrekvenciáját. A módosítások végrehajtásához az fff3c0 értéket cccccc-re, ff6c00-at 800080-ra és a4a4a4 értéket 000080-ra változtattam a logon.css fájlban. Több revízióra is szükség volt annak ellenőrzésére, hogy a CSS-fájl mely elemei kerültek alkalmazásra az oldalra. körültekintően megőrizve biztonsági mentés logon.css, az új fájlt a Client Access szerver \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\14.2.283.3\Themes\Resources könyvtárába helyeztem. Ugyanebbe a könyvtárba másoltam az új lgntopl.gif képet is. A 12. ábra az OWA bejelentkezési képernyőjén végrehajtott egyszerű változtatásokat mutatja be. Természetesen lehetőségei nem korlátozódnak ezekre az egyszerű beállításokra. A CSS és a grafika sajátosságainak alapos ismeretében saját bejelentkezési és kijelentkezési képernyőket hozhat létre, amelyek a szabványos OWA opciókhoz képest felismerhetetlenek.

Előfordulhat, hogy a felhasználóknak törölniük kell a helyi böngésző gyorsítótárát, hogy azonnal láthassák a változásokat. Laboratóriumomban újra kellett indítanom a webhelyet, hogy a változtatásokat eljussam az ügyfelekhez. Ha bizonyos proxyalkalmazásokat vagy eszközöket használ a hálózat peremén, előfordulhat, hogy a felhasználók késéssel kapják meg a frissítéseket.

Beállítások alkalmazása

Az OWA-módosítások nem replikálódnak a Client Access kiszolgálók között. Ha több, Client Access kiszolgálói szerepkörrel rendelkező Exchange-kiszolgáló biztosít OWA-t, akkor minden testreszabást minden kiszolgálón alkalmazni kell. Csak ebben az esetben minden felhasználó ugyanazokat a képernyőket fogja látni. A felhasználók az OWA képernyőket ugyanarról a Client Access szerverről kapják, amelyre a böngészőjük mutat. Ez lehet előny és hátrány is. Néha hasznos, ha a felhasználók különböző csoportjai eltérően lépnek kapcsolatba az OWA-val egy vállalati környezetben.

Ha nem szeretne fájlszinten dolgozni az Exchange Serverben, de módosítania kell a bejelentkezési és leállítási képernyőit, néhány márkaépítő cég különféle egyedi szoftvermegoldásokhoz nyújt szolgáltatásokat, beleértve az OWA 2010-et is. Sokan mélyreható változtatásokat hajtanak végre az OWA bejelentkezési képernyőin, így hogy az alkalmazás felismerhetetlenné válik. Példa egy ilyen szolgáltatóra (az ügyfélmegoldásokhoz több képernyőképet is tartalmazó) a Techstur.com. Ha ilyen céget használ, készüljön fel arra, hogy megoldja azokat a problémákat, amelyek az OWA új szervizcsomagjainak kiadása után merülhetnek fel.

Az OWA konfigurálása az Exchange Server 2010-ben

A Rosalab Wikiből

Célja

Ez a kézikönyv leírja, hogyan lehet különféle levelezőklienseket csatlakoztatni a Microsoft Exchange kiszolgálóhoz. A cél egy olyan rendszer beszerzése, amely funkcionálisan egyenértékű a Microsoft Outlookkal.

Beviteli adat

A példák a Microsoft Exchange 2010 (v14.03.0361.001) Service Pack 3 Update RollUp 18 kiszolgálót használják. A tesztelés a vállalati hálózaton belül történik. A DNS-kiszolgálók határozzák meg a levelezőszerver külső e-mail címeit. Az Exchange szervernek futnia kell:

OWA (Outlook Web Access) – webes kliens megosztott szerver eléréséhez Microsoft munka Csere
OAB (Offline Address Book) - offline címjegyzék
EWS (Exchange Web Services) – olyan szolgáltatás, amely hozzáférést biztosít az Exchange Online-ban (az Office 365 részeként) és a helyszíni Exchange-ben (az Exchange Server 2007-től kezdve) tárolt postafiók-adatokhoz.

Exchange szerver beállításai

A hitelesítés kritikus fontosságú a nem Microsoft-ügyfelek Exchange 2010 rendszeren való sikeres működéséhez. Paramétereit megtekintheti az Exchange kiszolgálón CAS (Client Access Server) szerepkörrel. Indítsa el az IIS Manager beépülő modult, és nyissa meg a Webhelyek/Alapértelmezett webhely lapot. Figyelje meg a hitelesítést három összetevőből:

OWA – állam Beleértve" for " Alapvető hitelesítés"és" Windows hitelesítés»:

OAB – állam Beleértve" for " Alapvető hitelesítés"és" Windows hitelesítés»:

EWS - Állapot " Beleértve" for " Névtelen hitelesítés», « Alapvető hitelesítés"és" Windows hitelesítés»:

Rétegek (közvetítők) és segédeszközök

Davmail

Egyes e-mail kliensek nem tudnak közvetlenül csatlakozni a Microsoft Exchange szolgáltatáshoz, és közvetítő igénybevételét igénylik. Ebben a példában egy proxyszervert használunk közvetítőként Davmail.

Telepítés Davmail, rendszergazdai jogok megszerzésével su vagy sudo segítségével:

sudo urpmi davmail

Fuss Davmail:

A "Fő" lapon a " OWA (Exchange) URL» írja be szervere címét «https:// formátumban /EWS/Exchange.asmx" vagy egy hivatkozás az OWA-ra

"https://" formátumban /owa".

Ne felejtse el a portszámokat Helyi IMAP port"és" Helyi SMTP port". Ebben a példában ezek 1143 és 1025.

Annak érdekében, hogy ne indítsa el minden alkalommal manuálisan a szervert Davmail, hozzá kell adnia a hívását az automatikus betöltéshez.

Menj a menübe " Rendszerbeállítások → Indítás és leállítás → Automatikus indítás", megnyomni a [ Alkalmazás hozzáadása], írja be a „davmail” kifejezést a keresősávba, majd nyomja meg a [ rendben]:

Most helyi proxy Davmail automatikusan elindul a rendszer indításakor. Ha zavarja az ikonja a tálcán, lehetőség van elrejteni. Ehhez módosítsa a davmail.server=false sort a .davmail.properties fájlban, és módosítsa a false értéket igazra:

sudo mcedit /home/<имя_пользователя>/.davmail.properties

E-mail kliensek az Exchange-hez való csatlakozáshoz

Most megkezdheti a levelezőkliensek beállítását.

Thunderbird

Mozilla Thunderbird a ROSA Linux disztribúciók fő levelezőkliense, és valószínűleg már telepítve van a rendszeren, és használatra kész. Ha nem, akkor a ROSA-tárolókból telepíthető. Ez a példa az 52.2.1-es verziót használja.

Telepítés Thunderbird:

sudo urpmi mozilla-thunderbird

Orosz nyelvű felület hozzáadása:

sudo urpmi mozilla-thunderbird-en

Telepítse a naptárak használatát lehetővé tevő Lightning kiegészítőt:

sudo urpmi mozilla-thunderbird-villám

Fuss Thunderbird.

fejezetben " Fiókok "lépésben" Hozzon létre egy fiókot» válassz « Email". Megjelenik egy üdvözlő ablak.

A megnyíló ablakban kattintson a [ Ezt hagyd ki, és használd a meglévő leveleimet].

Az ablakban" Levelezési fiók beállítása» írja be a mezőkbe « A neved», « Email cím posta"és" Jelszó» az Ön hitelesítő adatait.

Nyomja meg [ Folytassa]. A program megpróbálja megtalálni a kapcsolatokat (sikertelenül), és megjelenik egy hibaüzenet:

Itt szüksége lesz azokra a portszámokra, amelyekre a beállításkor emlékszik Davmail.

kategóriákhoz " beérkező"és" kimenő' módosítsa a szerver nevét 'localhost'-ra.
Adja meg a " IMAP" port 1143, és a " SMTP"- 1025-ös port.
mezőben " Felhasználónév» Adja meg az UPN-t (User Principal Name) - a felhasználó domain nevét "Felhasználóné[email protected]" formátumban.
Kattintson a [ Újrateszt].

Ha a megfelelő hitelesítő adatokat adja meg, nem lesz hiba. A rendszer kérheti, hogy fogadja el az Exchange szerver tanúsítványát. Ha ez nem történik meg, lehet, hogy túl korán kapcsolta ki a felületet. Davmail.

Felhasználói naptár létrehozása

kategóriában " Fiókok» válassz « Hozzon létre egy új naptárt».
A megjelenő ablakban válassza ki a " Online" és nyomja meg a [ További].
Válassz formátumot " CalDAV"és a mezőn" Cím» írja be: "http://localhost:1080/users/ /naptár":

Hozzon létre egy címjegyzéket

A címjegyzék Thunderbird nem támogatja a CardDAV protokollt, és csak az Exchange Server LDAP címtárához csatlakozhat.

Nyissa meg a meglévő címjegyzékeket a [ A címjegyzék] és válassza ki a „ Fájl -> Új -> LDAP-könyvtár».

A varázsló ablakában adja meg a következő beállításokat:
- Név- bármilyen megfelelő név
- Szerver név- helyi kiszolgáló
- Gyökérelem (alap DN)-ou=emberek
- Kikötő- 1389 (tól Davmail)
- Felhasználónév (Bind DN)- UPN felhasználónév

Nyomja meg [ rendben]. A program kérni fogja a jelszó megadását.

Lépjen a beállítások menübe Thunderbird. kategóriában " Tervezés» válassza ki a lapot « Megszólítás” és a „Cím megadásakor keressen megfelelő postai címeket” szöveg alatt jelölje be a „ címtárszerver” címjegyzék nevének kiválasztásával.

evolúció

Levelező kliens is elérhető a ROSA tárolókban evolúció(ebben a példában a 3.16.4 verziót használjuk).

Telepítés evolúció:

sudo urpmi evolution

Telepítse a csatlakozót Csere, kompatibilis a 2007-es és újabb verziókkal:

sudo urpmi evolution-ews

Fuss evolúció.

A varázsló ablakában kattintson a [ Következő], amíg át nem vált a "" lapra fiók».
Töltse ki a mezőket " Teljes név"és" Email».
A lapon " Levelek fogadása» a listában « Szerver típusa» Válassza az Exchange webszolgáltatások lehetőséget.
Adja meg a felhasználó UPN-nevét „Felhasználóné[email protected]” formátumban névként.
mezőben " Gazda URL» írja be a "https://ExchangeMailServerName/EWS/Exchange.asmx .
mezőben " OAB URL» írja be az offline címjegyzék URL-jét.
Válassza ki az "Alap" hitelesítési típust.