Ostas apmaiņai. Pasta klientu savienošana ar Microsoft Exchange Server

No Rosalab Wiki

Pieraksts

Šajā rokasgrāmatā ir aprakstīts, kā savienot dažādus pasta klientus ar Microsoft Exchange serveri. Mērķis ir iegūt sistēmu, kas funkcionalitātē atbilst programmai Microsoft Outlook.

Ievades dati

Izmantošanas piemēri microsoft serveris Exchange 2010 (v14.03.0361.001) 3. servisa pakotnes atjauninājumu apkopojums 18. Testēšana tiek veikta korporatīvajā tīklā. Pasta servera ārējās pasta adreses ir norādītas DNS serveros. Exchange serverī jādarbojas šādi:

1. OWA (Outlook Web Access) - tīmekļa klients, lai piekļūtu Microsoft Exchange kopienas serverim
2. OAB (bezsaistes adrešu grāmata) - bezsaistes adrešu grāmata
3. EWS (Exchange Web Services) ir pakalpojums, kas nodrošina piekļuvi pastkastes datiem, kas saglabāti Exchange Online (kā daļa no Office 365) un Exchange lokālajā versijā (sākot ar Exchange Server 2007).

Exchange servera iestatījumi

Autentifikācija ir būtiska, lai panāktu, ka klienti, kas nav Microsoft klienti, darbojas Exchange 2010. Tā parametrus var apskatīt Exchange serverī ar lomu CAS (Client Access Server). Sāciet IIS Manager papildinājumu un noklikšķiniet uz cilnes Vietnes / Noklusējuma vietne. Pievērsiet uzmanību autentifikācijai trīs komponentos:

• OWA - štats " Ieslēgts"Priekš" Pamata autentifikācija"Un" Windows autentifikācija»:

• OAB - štats " Ieslēgts"Priekš" Pamata autentifikācija"Un" Windows autentifikācija»:

• EWS - štats " Ieslēgts"Priekš" Anonīma autentifikācija», « Pamata autentifikācija"Un" Windows autentifikācija»:

Starpslāņi (starpnieki) un palīgkomunikācijas

DavMail

Daži e-pasta klienti nevar tieši izveidot savienojumu ar Microsoft Exchange, un tiem ir nepieciešams izmantot starpslāni. Šajā piemērā starpniekserveris tiek izmantots kā starpnieks DavMail.

• Uzstādīt DavMailiegūstot administratora tiesības ar su vai sudo:

• Palaist DavMail:

• Cilnes Galvenais cilnē OWA (Exchange) URL"Ievadiet sava servera adresi formātā" https: // /EWS/Exchange.asmx "vai saiti uz OWA

formātā "https: // / owa ".

• Atcerieties porta numurus Vietējais IMAP ports"Un" Vietējais SMTP ports". Šajā piemērā tie ir attiecīgi 1143 un 1025.

Lai katru reizi manuāli neuzsāktu serveri DavMail, jums jāpievieno tā izsaukums startēšanai.

• Pāriet uz izvēlni " Sistēmas iestatījumi -\u003e Startēšana un izslēgšana -\u003e Autostart», Noklikšķiniet uz [ Pievienot lietojumprogrammu] un meklēšanas joslā ievadiet "davmail", pēc tam noklikšķiniet uz [ labi]:

Tagad vietējais pilnvarnieks DavMail automātiski startēs sistēmas palaišanas laikā. Ja tā ikona "Uzdevumjoslā" jūs traucē, varat to paslēpt. Lai to izdarītu, failā .davmail.properties rediģējiet rindu davmail.server \u003d false, nepatiesu mainot uz true:

Sudo mcedit / mājas /<имя_пользователя>/.davmail.properties

Pasta klienti, lai izveidotu savienojumu ar Exchange

Tagad jūs varat sākt konfigurēt savus e-pasta klientus.

Pērkona putns

Mozilla Thunderbird ir galvenais ROSA Linux izplatīšanas e-pasta klients, un, visticamāk, tas jau ir instalēts jūsu sistēmā un ir gatavs darbam. Ja nē, varat to instalēt no ROSA krātuvēm. Šajā piemērā tiek izmantota 52.2.1 versija.

• Uzstādīt Pērkona putns:

• Pievienojiet krievu valodas saskarni:

• Lai izmantotu kalendārus, instalējiet zibens papildinājumu:

• Palaist Pērkona putns.

• Nodaļā " Konti"punktā" Izveidot kontu»Atlasīt« E-pasts". Parādīsies apsveikuma logs.

• Atvērtajā logā noklikšķiniet uz [ Izlaidiet to un izmantojiet manu esošo pastu].

• Logā " Pasta konta iestatīšana"Ievadiet laukos" Tavs vārds», « Epasta adrese pasts"Un" Parole»Jūsu akreditācijas dati.

• Klikšķis [ Turpināt]. Programma mēģinās atrast savienojumus (neveiksmīgi) un parādīsies kļūdas ziņojums:

Šeit jums būs nepieciešami porta numuri, kurus esat iegaumējis iestatīšanas laikā DavMail.

• Kategorijām " Ienākošie"Un" Izejošais"Mainiet servera nosaukumu uz" localhost ".
• Norādīt uz IMAP"1143 osta un SMTP"- osta 1025.
• Laukā " Lietotājvārds"Norādiet UPN (User Principal Name) - lietotāja domēna nosaukums formātā" [email protected] ".
• Noklikšķiniet uz [ Atkārtoti pārbaudīt].

Ja ievadīsit pareizus akreditācijas datus, kļūdu nebūs. Sistēma var likt jums pieņemt Exchange Server sertifikātu. Ja tas nenotiek, iespējams, esat pārāk ātri izslēdzis interfeisu. DavMail.

Lietotāja kalendāra izveide

• Kategorijā Konti"Atlasīt" Izveidojiet jaunu kalendāru».
• Parādītajā logā atlasiet vērtību " Tiešsaistē"un nospiediet [ Tālāk].
• Atlasiet formātu " CalDAV"Un laukā" Adrese"Ievadiet" http: // localhost: 1080 / users / / kalendārs ":

Adrešu grāmatas izveide

Adrešu grāmata Pērkona putns neatbalsta CardDAV un to var savienot tikai ar Exchange Server LDAP direktoriju.

• Atveriet esošās adrešu grāmatas, noklikšķinot uz [ Adrešu grāmata] un atlasot vienumu " Fails -\u003e Jauns -\u003e LDAP direktorijs».

• Vedņa logā norādiet šādus parametrus:
  • Nosaukums - jebkurš piemērots nosaukums
  • Servera nosaukums - vietējais saimnieks
  • Saknes elements (bāzes DN) - ou \u003d cilvēki
  • Osta - 1389 (no Davmails)
  • Lietotājvārds (saistošs DN) - UPN lietotājvārds

• Klikšķis [ labi]. Programma lūgs ievadīt paroli.

• Atveriet opciju izvēlni Pērkona putns... Kategorijā Redakcija"Atlasīt cilni" Uzrunāšana"Un zem teksta" Ievadot adresi, meklējiet piemērotas pasta adreses "izvēles rūtiņā" Direktoriju serveris"Izvēloties savu vārdu adrešu grāmata.

Evolūcija

ROSA krātuvēs ir pieejams arī pasta klients Evolūcija (Šajā piemērā tiek izmantota versija 3.16.4).

• Uzstādīt Evolūcija:

• Uzstādiet savienotāju Apmaiņasaderīgs ar versiju 2007 un jaunākām versijām:

• Palaist Evolūcija.

• Vedņa logā noklikšķiniet uz [ Nākamais], līdz dodaties uz Konts».
• Aizpildiet laukus “ Pilnais vārds "Un" E-pasts».
• Cilnē “ Pasta saņemšana"Sarakstā" Servera tips"Atlasiet" Exchange Web Services ".
• Lai ievadītu vārdu, ievadiet lietotāja UPN vārdu formātā "Lietotājvārds@JūsuDomēns.ru".
• Laukā " Saimnieka URL"Ievadiet" https: // MailServerNameExchange / EWS / Exchange.asmx .
• Laukā " OAB URL»Ievadiet bezsaistes adrešu grāmatas URL.
• Kā autentifikācijas veidu atlasiet “Basic”.

Ja konfigurācija ir veiksmīga, programma pieprasīs paroli:

Pēc paroles ievadīšanas Evolūcija saņems piekļuvi jūsu pastkastei, adrešu grāmatai un kalendāriem.

Ja jums ir kādi jautājumi par šo rakstu, lūdzu, sazinieties ar [e-pasts aizsargāts]

Ugunsmūri (ugunsmūri) pasta serveriem (Exchange Server), porti pasta serveriem, priekšējā un aizmugurējā pasta serveriem, virtuālie serveri SMTP, POP3, IMAP4

Tāpat kā jebkuram datoram, kas savienots ar internetu, arī datoram, kurā mitinās pasta serveris, jābūt aizsargātam ar ugunsmūri. Tajā pašā laikā pasta servera instalēšanas iespējas tīkla konfigurācijas ziņā var būt ļoti dažādas:

· Vienkāršākā iespēja ir instalēt pasta serveri datorā, kas vienlaikus ir arī starpniekserveris / ugunsmūris, un pēc tam saskarnē atvērt nepieciešamos portus, kas vērsti uz internetu. Parasti tas attiecas uz mazām organizācijām;

Vēl viena iespēja ir instalēt pasta serveri vietējais tīkls un konfigurējiet to darbam, izmantojot starpniekserveri. Lai to izdarītu, varat saistīt publisko ip ar pasta serveri un nodot to caur starpniekserveri, vai izmantot tādus rīkus kā porta kartēšana starpniekserverī. Daudziem starpniekserveriem ir īpaši vedņi vai iepriekš noteikti noteikumi šāda risinājuma organizēšanai (piemēram, ISA Server). Šī opcija tiek izmantota lielākajā daļā organizāciju.

· Vēl viena būtiska iespēja ir izveidot DMZ un ievietot tajā front-end Exchange serveri (šī iespēja ir parādījusies kopš 2000. gada versijas) vai SMTP releju, kura pamatā ir cits Exchange Server, vai, piemēram, sendmail uz * nix. Parasti izmanto lielu organizāciju tīklos.

Jebkurā gadījumā pasta serverim ir jāsazinās vismaz portā TCP 25 (SMTP) un UDP 53 (DNS). Citas ostas, kuras atkarībā no tīkla konfigurācijas var pieprasīt Exchange Server (visas ir TCP):

80 HTTP - piekļuvei tīmekļa saskarnei (OWA)

· 88 Kerberos autentifikācijas protokols - ja tiek izmantota Kerberos autentifikācija (reti);

· 102 MTA .X .400 savienotājs, izmantojot TCP / IP (ja sakariem starp maršrutēšanas grupām tiek izmantots X .400 savienotājs);

110 3. pasta protokols (POP 3) - klienta piekļuvei;

· 119 Network News Transfer Protocol (NNTP) - ja tiek izmantotas ziņu grupas;

135 Klienta / servera saziņa RPC Exchange administrēšana - standarta RPC ports Exchange attālinātai administrēšanai standarta līdzekļi Sistēmas vadītājs;

· 143 interneta ziņojumu piekļuves protokols (IMAP) -klienta piekļuvei;

· 389 LDAP - lai piekļūtu direktoriju pakalpojumam;

· 443 HTTP (Secure Sockets Layer (SSL)) (un zemāk) - tie paši protokoli, kurus aizsargā SSL.

563 NNTP (SSL)

636 LDAP (SSL)

993 IMAP4 (SSL)

995 POP3 (SSL)

3268 un 3269 - vaicājumi globālajam katalogu serverim (meklēt pēc Active Directory un dalības pārbaude universālajās grupās).

Nav jēgas nosegt Exchange Server saskarni, kas vērsta uz organizācijas iekšpusi, ar ugunsmūri - tā tiks izmantota, lai mijiedarbotos ar domēna kontrolleriem, administrēšanas utilītprogrammām, sistēmām rezerves kopija utt. Interfeisam, kas ir atvērts internetam, ieteicams atstāt 53. portu (ja Exchange pati atrisinās resursdatoru nosaukumus, nevis novirzīs pieprasījumus uz vietējo DNS serveri) un 25. Ļoti bieži klientiem ir jāpiekļūst savām pastkastēm no ārpuses (no mājām, komandējuma laikā). utt.). Labākais risinājums šajā situācijā ir konfigurēt OWA (noklusējuma tīmekļa saskarni piekļuvei Exchange serverim, kas pieejams vietnē http: // servername / exchange), lai darbotos SSL un atvērtu piekļuvi tikai 443. portā. Papildus problēmu risināšanai ar droša autentifikācija un ziņojumu šifrēšana automātiski atrisina problēmu ar SMTP releju (vairāk par to vēlāk) un situāciju, kad lietotājs nejauši lejupielādē darba ziņojumu e-pasts uz mājas klienta mapēm mājas datorā un pēc tam darbā nevar atrast šos ziņojumus (nemaz nerunājot par to, ka darba pasta glabāšana mājās ir drošības pārkāpums).

Jauna iespējakas parādījās Exchange Server. sākot ar 2000. gada versiju, iespēja izmantot vairākus virtuālos SMTP un POP3 serverus ar dažādiem drošības iestatījumiem. Piemēram, SMTP serveri, kas mijiedarbojas ar internetu, var konfigurēt ar paaugstinātu drošību un stingriem piegādes ierobežojumiem, un SMTP serveri, kuru organizācijas lietotāji izmanto, var konfigurēt ar visaugstākās veiktspējas un lietotājam draudzīgiem iestatījumiem.

Ir arī jāpiemin zināms neskaidrības terminoloģijā - ļoti bieži ziņojumu filtrēšanas sistēmas tiek sauktas par ugunsmūri Exchange, kas tiks apspriests tālāk.

[Šis raksts ir provizorisks dokuments, un turpmākajos izlaidumos tas var mainīties. Tukšās sadaļas ir iekļautas kā vietturi. Ja vēlaties uzrakstīt atsauksmi, mēs priecāsimies to saņemt. Nosūtiet to mums uz epasta adrese [e-pasts aizsargāts]]

Attiecas uz:Exchange Server 2016

Informācija par tīkla portiem, kurus Exchange 2016 izmanto klienta piekļuvei un pasta plūsmai.

Šajā sadaļā ir sniegta informācija par tīkla portiem, kurus Microsoft Exchange Server 2016 izmanto, lai sazinātos ar e-pasta klientiem, interneta pasta serveriem un citiem pakalpojumiem, kas atrodas ārpus jūsu lokālās Exchange organizācijas. Pirms sākat, apsveriet šādus pamatnoteikumus.

Mēs neatbalstām tīkla trafika ierobežošanu vai modificēšanu starp aizmugures Exchange serveriem, starp aizmugures Exchange serveriem un back-end Lync vai Skype darbam serveriem, vai starp back Exchange end serveriem un aizmugures Active Directory domēna kontrolleriem jebkura veida topoloģijā. Ja izmantojat ugunsmūrus vai tīkla ierīces, kas var ierobežot vai modificēt šo tīkla trafiku, jums jākonfigurē kārtulas, lai nodrošinātu brīvu un neierobežotu komunikāciju starp šiem serveriem (noteikumi, kas atļauj ienākošo un izejošo tīkla trafiku jebkurā portā, ieskaitot nejaušas RPC porti, un jebkuru protokolu , kas nemaina nevienu bitu).

Edge Transport serveri gandrīz vienmēr atrodas perimetra tīklā, tāpēc paredzams, ka tīkla trafika starp Edge Transport serveri un internetu būs ierobežota, un starp Edge Transport serveri un iekšējo Exchange organizāciju. Šīs tīkla porti ir aprakstīti šajā sadaļā.

Jums ir paredzēts ierobežot tīkla trafiku starp ārējiem klientiem un pakalpojumiem un iekšējo Exchange organizāciju. Varat arī ierobežot trafiku starp iekšējiem klientiem un iekšējiem Exchange serveriem. Šīs tīkla porti ir aprakstīti šajā sadaļā.

Saturs

Klientiem un pakalpojumiem nepieciešamie tīkla porti

Tīkla porti, kas nepieciešami pasta plūsmai (nav Edge Transport serveru)

Tīkla porti, kas nepieciešami pasta plūsmai ar Edge Transport serveriem

Tīkla porti, kas nepieciešami hibrīdai izvietošanai

Tīkla porti, kas nepieciešami vienotajai ziņojumapmaiņai

Tīkla porti, kas e-pasta klientiem nepieciešami, lai piekļūtu pastkastēm un citiem Exchange organizācijas pakalpojumiem, ir aprakstīti šajā diagrammā un tabulā.

Piezīmes.

Šo klientu un pakalpojumu galamērķis ir klienta piekļuves pakalpojumi serverī pastkastes... Exchange 2016 klienta piekļuve (ārējā) un iekšējie pakalpojumi tiek instalēti kopā vienā pastkastes serverī. Plašāku informāciju skatiet.

Lai gan diagrammā ir parādīti klienti un pakalpojumi no interneta, iekšējiem klientiem jēdzieni ir vienādi (piemēram, klienti kontu mežā, kas resursu mežā piekļūst Exchange serveriem). Tāpat tabulā nav slejas Avots, jo avots var būt jebkura vieta, kas atrodas ārpus Exchange organizācijas (piemēram, internets vai konta mežs).

Edge Transport serveri nepiedalās tīkla trafikā, kas saistīts ar šiem klientiem un pakalpojumiem.

Uz sākumu

Tīkla porti, kas nepieciešami pasta plūsmai

Izejošais pasts

25 / TCP (SMTP)

Pastkastes serveris

Internets (viss)

Pēc noklusējuma Exchange neveido savienotājus Send, kas ļauj nosūtīt vēstules uz internetu. Manuāli jāizveido savienotāji Sūtīt. Plašāku informāciju skatiet.

Izejošais pasts (ja tas tiek nosūtīts, izmantojot ārēju transporta pakalpojumu)

25 / TCP (SMTP)

Pastkastes serveris

Internets (viss)

Izejošais pasts iet caur ārējo transporta pakalpojumu tikai tad, ja ir iespējota opcija Sūtīt savienotāju. Starpniekserveris, izmantojot klienta piekļuves serveri EAC vai -FrontEndProxyEnabled $ true parametrā Exchange pārvaldības čaulā.

Šajā gadījumā noklusējuma saņemšanas savienotājs "Outbound Proxy Frontend "ārējā transporta pakalpojumā klausās izejošo pastu no transporta pakalpojuma pastkastes serverī. Lai iegūtu papildinformāciju, skatiet rakstu.

DNS serveris nosaukuma izšķiršanai nākamajā apiņu pastā (nav parādīts)

53 / UDP, 53 / TCP (DNS)

Pastkastes serveris

DNS serveris

Uz sākumu

Parakstīts Edge Transport serveris, kas instalēts perimetra tīklā, pasta plūsmu ietekmē šādi:

Exchange organizācijas izejošais pasts nekad nenonāk caur pastkastes serveru ārējo transporta pakalpojumu. Tas vienmēr tiek novirzīts no transporta pakalpojuma Active Directory abonēto vietņu pastkastes serverī uz serves servi Edge (neatkarīgi no Exchange versijas servera Edge transportā).

Ienākošais pasts tiek novirzīts no servera Edge uz abonētās vietnes Active Directory pastkastes serveri. Tas nozīmē sekojošo:

• Pasts no Exchange 2016 vai Exchange 2013 Edge Transport servera vispirms nonāk ārējā transporta pakalpojumā un pēc tam tiek novirzīts uz transporta pakalpojumu Exchange 2016 pastkastes serverī.

  Pasts no Exchange 2010 Edge Transport servera vienmēr tiek tieši novirzīts uz transporta pakalpojumu Exchange 2016 pastkastes serverī.

Tīkla porti, kas nepieciešami pasta plūsmai Exchange organizācijās ar Edge Transport serveriem, ir aprakstīti šajā diagrammā un tabulā.

Uz sākumu

Nosaukuma izšķirtspēja

Nosaukuma izšķirtspēja

DNS nākamā apiņa izšķirtspēja ir būtiska pasta plūsmas sastāvdaļa jebkurā Exchange organizācijā. Apmaiņas serveriem, kas atbildīgi par ienākošā pasta saņemšanu vai izejošā pasta piegādi, jāspēj atrisināt gan iekšējos, gan ārējos resursdatora nosaukumus, lai pareizi virzītu pastu. Visiem iekšējiem Exchange serveriem jāspēj atrisināt iekšējos resursdatoru nosaukumus pareizai pasta maršrutēšanai. Tur ir daudz dažādi ceļi DNS infrastruktūras attīstība, taču svarīgs rezultāts ir pareizas nosaukuma izšķirtspējas nodrošināšana nākamajam apiņam visos Exchange serveros.

Attiecas uz: Exchange Server 2010 SP1

Pēdējā modificētā sadaļa: 2011-04-22

Šajā sadaļā ir sniegta informācija par portu, autentifikāciju un šifrēšanu visiem Microsoft Exchange Server 2010 izmantotajiem datu ceļiem. Sadaļā Piezīmes pēc katras tabulas tiek paskaidrotas vai identificētas nestandarta autentifikācijas vai šifrēšanas metodes.

Transporta serveri

Programmā Exchange 2010 ir divas servera lomas, kas nodrošina ziņojumu transportēšanas funkcionalitāti: Hub Transport un Edge Transport.

Šajā tabulā sniegta informācija par ostām, datu ceļu starp šiem transporta serveriem un citiem Exchange 2010 serveriem un pakalpojumiem autentifikāciju un šifrēšanu.

Datu ceļi transporta serveriem

Transporta servera piezīmes

• Visa trafika starp centrmezgla serveriem tiek šifrēta, izmantojot TLS un pašparakstītos sertifikātus, kurus instalējusi Exchange 2010 iestatīšana.
• Visa trafika starp Edge Transport serveriem un Hub Transport serveriem tiek autentificēta un šifrēta. Savstarpējo TLS izmanto kā autentifikācijas un šifrēšanas mehānismu. X.509 validācijas vietā Exchange 2010 izmanto tieša uzticēšanās... Tieša uzticēšanās nozīmē, ka sertifikāta klātbūtne Active Directory vai Active Directory vieglā direktorija pakalpojumos (AD LDS) apstiprina sertifikāta autentiskumu. Active Directory tiek uzskatīts par uzticamu krātuves motoru. Izmantojot tiešo uzticību, nav svarīgi, vai izmantojat pašu parakstītu sertifikātu vai sertifikācijas iestādes parakstītu sertifikātu. Kad Edge Transport serveris abonē Exchange organizāciju, Edge Subscription publicē Edge Transport servera sertifikātu Active Directory, lai Hub Transport serveri varētu to validēt. Microsoft Exchange EdgeSync pievieno Hub Transport servera sertifikātu kopu Active Directory vieglā direktorija pakalpojumiem (AD LDS), lai pārbaudītu servera Edge transportēšanu.
• EdgeSync izmanto drošu LDAP centrmezgla transporta servera savienojumu abonētiem Edge Transport serveriem TCP portā 50636. AD LDS klausās arī TCP portā 50389. Šis ports neizmanto SSL. Lai izveidotu savienojumu ar šo portu un apstiprinātu AD LDS datus, varat izmantot LDAP utilītprogrammas.
• Pēc noklusējuma trafiks starp Edge Transport serveriem, kas atrodas divās dažādās organizācijās, tiek šifrēts. Exchange 2010 uzstādīšana izveido pašparakstītu sertifikātu un pēc noklusējuma iespējo TLS. Tas ļauj jebkurai sūtīšanas sistēmai šifrēt ienākošo SMTP sesiju uz Exchange. Pēc noklusējuma Exchange 2010 arī mēģina izmantot TLS visiem attālajiem savienojumiem.
• Datplūsmas starp Hub Transport serveriem un pastkastes serveriem autentifikācijas metodes ir atšķirīgas, ja Hub Transport servera un pastkastes servera lomas ir instalētas vienā datorā. Vietējos pasta pārsūtījumos tiek izmantota Kerberos autentifikācija. Attālā pasta pārsūtīšana izmanto NTLM autentifikāciju.
• Exchange 2010 atbalsta arī domēna drošību. Domēna drošība ir Exchange 2010 un Microsoft Outlook 2010 funkciju kopums, kas nodrošina zemu izmaksu alternatīvu S / MIME un citus risinājumus ziņojumu pārraides drošībai internetā. Domēna drošība nodrošina veidu, kā kontrolēt drošus saziņas ceļus starp domēniem internetā. Kad šie drošie ceļi ir konfigurēti, ziņojumi no autentificēta sūtītāja, kuri tiem ir veiksmīgi izgājuši, Outlook un Outlook Web Access lietotājiem tiek rādīti kā "ar domēnu aizsargāti" ziņojumi. Papildinformāciju skatiet sadaļā Domēna drošības izpratne.
• Daudzi aģenti var darboties gan Hub Transport serveros, gan Edge Transport serveros. Parasti aizsardzības līdzekļi pret mēstules, surogātpasts izmantot informāciju no vietējā datora, kurā tie darbojas. Tādējādi praktiski nav nepieciešama mijiedarbība ar attāliem datoriem. Izņēmums ir saņēmēja filtrēšana. Saņēmēju filtrēšanai nepieciešams izsaukums uz AD LDS vai Active Directory. Mēs iesakām veikt adresātu filtrēšanu Edge Transport serverī. Šajā gadījumā AD LDS direktorijs atrodas tajā pašā datorā, kurā atrodas servera Edge Transport serveris, tāpēc attālais savienojums nav nepieciešams. Ja saņēmēja filtrēšana ir instalēta un konfigurēta Hub Transport serverī, jums ir jābūt piekļuvei Active Directory.
• Protokola analīzes aģentu izmanto Exchange 2010 sūtītāja reputācijas līdzeklis. Šis aģents arī izveido savienojumu ar dažādiem ārējiem starpniekserveriem, lai noteiktu ienākošo ziņojumu ceļus aizdomīgiem savienojumiem.
• Visas citas pret surogātpastu saistītas funkcijas izmanto datus, kas tiek apkopoti, glabāti un pieejami tikai vietējā datorā. Parasti dati, piemēram, konsolidēts safelists vai saņēmēja dati, kas filtrē saņēmēja datus, tiek pārvietoti uz lokālo AD LDS direktoriju, izmantojot Microsoft Exchange EdgeSync.
• Informācijas tiesību pārvaldības (IRM) aģenti centrmezglu serveros izveido savienojumu ar organizācijas Active Directory tiesību pārvaldības pakalpojumu (AD RMS) serveriem. Active Directory tiesību pārvaldības pakalpojumi (AD RMS) ir tīmekļa pakalpojums, kuru ieteicams nodrošināt ar SSL. Jūs izveidojat savienojumu ar AD RMS serveriem, izmantojot HTTPS, un autentifikācijai izmantojat Kerberos vai NTLM, atkarībā no jūsu AD RMS servera konfigurācijas.
• Reģistrācijas kārtulas, transporta kārtulas un ziņojumu klasifikācijas kārtulas tiek glabātas Active Directory, un tām piekļūst žurnāla žurnālists un transporta noteikumu aģents Hub Transport serveros.

  Pastkastes serveri

  Pastkastes serveros NTLM vai Kerberos autentifikācijas izmantošana ir atkarīga no lietotāja konteksta vai procesa, kurā darbojas Exchange biznesa loģikas slāņa patērētājs. Šajā kontekstā patērētāji ir visas lietojumprogrammas vai procesi, kas izmanto Exchange biznesa loģikas slāni. Rezultātā kolonnā Noklusējuma autentifikācija tabulas Datu ceļi pastkastes serveriem daudzām līnijām ir vērtība NTLM / Kerberos.

  Exchange biznesa loģikas slānis tiek izmantots, lai piekļūtu Exchange veikalam un mijiedarbotos ar to. Exchange biznesa loģikas slānis tiek izsaukts arī no Exchange veikala, lai mijiedarbotos ar ārējām lietojumprogrammām un procesiem.

  Kad Exchange biznesa loģikas slāņa patērētājs darbojas lokālas sistēmas kontekstā, Kerberos vienmēr ir autentifikācijas metode, kā patērētājs var piekļūt Exchange veikalam. Tiek izmantota Kerberos autentifikācijas metode, jo saņēmējs ir autentificēts, izmantojot konts Vietējās sistēmas dators, un tam ir nepieciešama autentificēta divvirzienu uzticēšanās.

  Ja Exchange biznesa loģikas slāņa saņēmējs nedarbojas lokālās sistēmas kontekstā, NTLM ir autentifikācijas metode. Piemēram, kad administrators palaiž Exchange Management Shell cmdlet, kas izmanto Exchange biznesa loģikas slāni, tiek izmantota NTLM autentifikācija.

  RPC trafika vienmēr tiek šifrēta.

  Šajā tabulā sniegta informācija par pastkastes serveru portiem, autentifikāciju un datu ceļa šifrēšanu.

  Datu ceļi pastkastes serveriem

  Datu ceļš	Nepieciešamās ostas	Noklusējuma autentifikācija	Atbalstītā autentifikācijas metode	Šifrēšanas atbalsts	Noklusētā datu šifrēšana
  	389 / TCP / UDP (LDAP), 3268 / TCP (LDAP GC), 88 / TCP / UDP (Kerberos), 53 / TCP / UDP (DNS), 135 / TCP (RPC tīkla pieteikšanās)			Jā, ar Kerberos šifrēšanu
  Administratīvā attālā piekļuve (attālais reģistrs)				Jā, ar IPsec
  Administratīvā attālā piekļuve (SMB, faili)				Jā, ar IPsec
  Pieejamības tīmekļa pakalpojums (piekļuve pastkastes klientam)				Jā, izmantojot RPC šifrēšanu
  Kopu veidošana				Jā, izmantojot RPC šifrēšanu
  Starp klienta piekļuves serveriem (Exchange ActiveSync)	80 / TCP, 443 / TCP (SSL)		Kerberos, sertifikāta autentifikācija	Jā, izmantojot HTTPS	Jā, izmantojot pašparakstītu sertifikātu
  Starp klienta piekļuves serveriem (Outlook Web Access)	80 / TCP, 443 / TCP (HTTPS)			Jā, ar SSL
  Klienta piekļuves serveris klienta piekļuves serverim (Exchange Web Services)				Jā, ar SSL
  Klienta piekļuves serveris klienta piekļuves serverim (POP3)				Jā, ar SSL
  Klienta piekļuves serveris klienta piekļuves serverim (IMAP4)				Jā, ar SSL
  Office Communications Server - Client Access Server (ja ir iespējota Office Communications Server un Outlook Web App integrācija)	5075-5077 / TCP (IN), 5061 / TCP (OUT)	mTLS (obligāti)	mTLS (obligāti)	Jā, ar SSL

  Piezīmes klientu piekļuves serveriem

  Serveri vienota sistēma ziņojumapmaiņa

  IP vārtejas un IP PBX atbalsta tikai sertifikātu autentifikāciju, kas izmanto savstarpēju TLS autentifikāciju, lai šifrētu SIP trafiku un autentifikāciju uz IP adreses SIP vai TCP savienojumiem. IP vārtejas neatbalsta NTLM un Kerberos autentifikāciju. Tāpēc, izmantojot autentifikāciju, kuras pamatā ir IP adrese, savienojuma IP adreses tiek izmantotas kā autentifikācijas mehānisms nešifrētiem (TCP) savienojumiem. Ja to izmanto kopā ar vienoto ziņojumapmaiņu, uz IP balstīta autentifikācija pārbauda, \u200b\u200bvai dotajai IP adresei ir atļauts izveidot savienojumu. IP adrese ir konfigurēta IP vārtejā vai IP PBX.

  IP vārtejas un IP PBX atbalsta savstarpēju TLS, lai šifrētu SIP trafiku. Pēc veiksmīgas nepieciešamo uzticamo sertifikātu importēšanas un eksportēšanas IP vārteja vai IP PBX pieprasīs sertifikātu no vienotā ziņojumapmaiņas servera un pēc tam pieprasīs sertifikātu no IP vārtejas vai IP PBX. Uzticamu sertifikātu apmaiņa starp IP vārteju vai IP PBX un vienoto ziņojumapmaiņas serveri ļauj abām ierīcēm droši sazināties, izmantojot Mutual TLS.

  Šajā tabulā sniegta informācija par portiem, autentifikāciju un šifrēšanu datu ceļiem starp Unified Messaging serveriem un citiem serveriem.

  Datu ceļi vienotajiem ziņojumapmaiņas serveriem

  Datu ceļš	Nepieciešamās ostas	Noklusējuma autentifikācija	Atbalstītā autentifikācijas metode	Šifrēšanas atbalsts	Noklusētā datu šifrēšana
  Piekļuve Active Directory	389 / TCP / UDP (LDAP), 3268 / TCP (LDAP GC), 88 / TCP / UDP (Kerberos), 53 / TCP / UDP (DNS), 135 / TCP (RPC tīkla pieteikšanās)			Jā, ar Kerberos šifrēšanu
  Vienotā ziņojumapmaiņas telefonija (IP PBX / VoIP Gateway)	5060 / TCP, 5065 / TCP, 5067 / TCP (nedrošais režīms), 5061 / TCP, 5066 / TCP, 5068 / TCP (drošais režīms), dinamiskais ports no 16000-17000 / TCP (vadība), dinamiskie UDP porti no diapazona 1024-65535 / UDP (RTP)	Pēc IP adreses	Pēc IP adreses MTLS	Jā, izmantojot SIP / TLS, SRTP
  Vienotais ziņojumapmaiņas tīmekļa pakalpojums	80 / TCP, 443 / TCP (SSL)	Integrētā Windows autentifikācija (sarunas)		Jā, ar SSL
  No vienotā ziņojumapmaiņas servera uz klienta piekļuves serveri	5075, 5076, 5077 (TCP)	Integrētā Windows autentifikācija (sarunas)	Pamata, Digest, NTLM, sarunas (Kerberos)	Jā, ar SSL
  No vienotā ziņojumapmaiņas servera uz klienta piekļuves serveri (atskaņošana pa tālruni)	Dinamiskā RPC			Jā, izmantojot RPC šifrēšanu
  No vienotā ziņojumapmaiņas servera uz centrmezgla transporta serveri				Jā, izmantojot TLS
  No vienotā ziņojumapmaiņas servera uz pastkastes serveri				Jā, izmantojot RPC šifrēšanu

  Piezīmes vienotajiem ziņojumapmaiņas serveriem

  • Veidojot UM IP vārtejas objektu Active Directory, jānosaka fiziskā IP vārtejas vai IP PBX IP adrese. Nosakot UM IP vārtejas objekta IP adresi, IP adrese tiek pievienota derīgo IP vārteju vai IP PBX (saukta arī par SIP dalībniekiem) sarakstam, ar kuriem UM serverim ir atļauts sazināties. Kad esat izveidojis UM IP vārteju, varat to saistīt ar UM numura sastādīšanas plānu. UM IP vārtejas kartēšana ar iezvanes plānu ļauj UM serveriem, kas ir piesaistīti zvanu plānam, saziņai ar IP vārteju izmantot IP adreses autentifikāciju. Ja UM IP vārteja nav izveidota vai konfigurēta pareizai IP adresei, autentifikācija neizdosies un vienotās ziņojumapmaiņas serveri nepieņems savienojumus no šīs IP vārtejas IP adreses. Turklāt, ieviešot savstarpējo TLS, IP vārteju vai IP PBX un vienotās ziņojumapmaiņas serverus, UM IP vārteja ir jākonfigurē tā, lai tā izmantotu pilnībā kvalificētu domēna vārdu (FQDN). Kad esat konfigurējis UM IP vārteju ar pilnībā kvalificētu domēna nosaukumu, pārsūtīšanas DNS uzmeklēšanas zonai jāpievieno arī šīs vārtejas resursdatora ieraksts.
  • Programmā Exchange 2010 vienotās ziņojumapmaiņas serveris var sazināties pa 5060 / TCP (nenodrošināts) vai 5061 / TCP (nodrošināts) portu, un to var konfigurēt, lai izmantotu abas porti.

  Papildinformāciju skatiet sadaļā Vienotās ziņojumapmaiņas VoIP drošības izpratne un Vienoto ziņojumapmaiņas protokolu, portu un pakalpojumu izpratne.

  Windows ugunsmūra noteikumi, ko izveidoja Exchange 2010 iestatīšana

  Windows ugunsmūris ar papildu drošību ir datorizēts valstisks ugunsmūris, kas filtrē ienākošo un izejošo trafiku, pamatojoties uz ugunsmūra noteikumiem. Exchange 2010 uzstādīšana izveido Windows ugunsmūra kārtulas, lai katrā servera lomā atvērtu portus, kas nepieciešami servera un klienta saziņai. Tādēļ, lai konfigurētu šos iestatījumus, jums vairs nav jāizmanto drošības konfigurācijas vednis. Lai iegūtu papildinformāciju par Windows ugunsmūri ar papildu drošību, skatiet sadaļu Windows ugunsmūris ar papildu drošību un IPsec (lapa var būt angļu valodā).

  Šajā tabulā ir parādīti Windows ugunsmūra noteikumi ģenerē programma Apmaiņas instalācijas, ieskaitot porti, kas ir atvērti katrā servera lomā. Šos noteikumus varat apskatīt, izmantojot Windows ugunsmūri ar Advanced Security MMC papildinājumu.

  Kārtulas nosaukums	Servera lomas	Osta	Programma
  MSExchangeADTopology - RPC (TCP ienākošais)		Dinamiskā RPC	Bin \\ MSExchangeADTopologyService.exe
  MSExchangeMonitoring - RPC (ienākošie TCP)	Client Access Server, Hub Transport Server, Edge Transport Server, Unified Messaging Server	Dinamiskā RPC	Bin \\ Microsoft.Exchange.Management.Monitoring.exe
  MSExchangeServiceHost - RPC (TCP ienākošais)		Dinamiskā RPC	Bin \\ Microsoft.Exchange.ServiceHost.exe
  MSExchangeServiceHost - RPCEPMap (TCP ienākošais)			Bin \\ Microsoft.Exchange.Service.Host
  MSExchangeRPCEPMap (GFW) (TCP ienākošais)
  MSExchangeRPC (GFW) (TCP ienākošais)	Client Access Server, Hub Transport Server, Mailbox Server, Unified Messaging Server	Dinamiskā RPC
  MSExchange - IMAP4 (GFW) (TCP ienākošais)	Klienta piekļuves serveris
  MSExchangeIMAP4 (TCP ienākošais)	Klienta piekļuves serveris		ClientAccess \\ PopImap \\ Microsoft.Exchange.Imap4Service.exe
  MSExchange - POP3 (FGW) (TCP ienākošais)	Klienta piekļuves serveris
  MSExchange - POP3 (TCP ienākošais)	Klienta piekļuves serveris		ClientAccess \\ PopImap \\ Microsoft.Exchange.Pop3Service.exe
  MSExchange - OWA (GFW) (TCP ienākošais)	Klienta piekļuves serveris	5075, 5076, 5077 (TCP)
  MSExchangeOWAAppPool (TCP ienākošie)	Klienta piekļuves serveris	5075, 5076, 5077 (TCP)	Inetsrv \\ w3wp.exe
  MSExchangeAB RPC (TCP ienākošais)	Klienta piekļuves serveris	Dinamiskā RPC
  MSExchangeAB-RPCEPMap (TCP ienākošais)	Klienta piekļuves serveris		Bin \\ Microsoft.Exchange.AddressBook.Service.exe
  MSExchangeAB-RpcHttp (TCP ienākošais)	Klienta piekļuves serveris	6002, 6004 (TCP)	Bin \\ Microsoft.Exchange.AddressBook.Service.exe
  RpcHttpLBS (TCP ienākošais)	Klienta piekļuves serveris	Dinamiskā RPC	System32 \\ Svchost.exe
  MSExchangeRPC - RPC (TCP ienākošais)		Dinamiskā RPC
  MSExchangeRPC - PRCEPMap (TCP ienākošais)	Klienta piekļuves serveris, pastkastes serveris		Bing \\ Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeRPC (TCP ienākošais)	Klienta piekļuves serveris, pastkastes serveris		Bing \\ Microsoft.Exchange.RpcClientAccess.Service.exe
  MSExchangeMailboxReplication (GFW) (TCP ienākošais)	Klienta piekļuves serveris
  MSExchangeMailboxReplication (TCP ienākošie)	Klienta piekļuves serveris		Bin \\ MSExchangeMailboxReplication.exe
  MSExchangeIS - RPC (TCP ienākošais)	Pastkastes serveris	Dinamiskā RPC
  MSExchangeIS RPCEPMap (TCP ienākošais)	Pastkastes serveris
  MSExchangeIS (GFW) (TCP ienākošais)	Pastkastes serveris	6001, 6002, 6003, 6004 (TCP)
  MSExchangeIS (TCP ienākošais)	Pastkastes serveris
  MSExchangeMailboxAssistants - RPC (TCP ienākošie)	Pastkastes serveris	Dinamiskā RPC
  MSExchangeMailboxAssistants - RPCEPMap (TCP ienākošais)	Pastkastes serveris		Bin \\ MSExchangeMailboxAssistants.exe
  MSExchangeMailSubmission - RPC (TCP ienākošais)	Pastkastes serveris	Dinamiskā RPC
  MSExchangeMailSubmission - RPCEPMap (TCP ienākošais)	Pastkastes serveris		Bin \\ MSExchangeMailSubmission.exe
  MSExchangeMigration - RPC (TCP ienākošais)	Pastkastes serveris	Dinamiskā RPC	Bin \\ MSExchangeMigration.exe
  MSExchangeMigration - RPCEPMap (TCP ienākošais)	Pastkastes serveris		Bin \\ MSExchangeMigration.exe
  MSExchangerepl - žurnāla kopētājs (TCP ienākošais)	Pastkastes serveris		Bin \\ MSExchangeRepl.exe
  MSExchangerepl - RPC (ienākošie TCP)	Pastkastes serveris	Dinamiskā RPC	Bin \\ MSExchangeRepl.exe
  MSExchangerepl - RPC-EPMap (TCP ienākošais)	Pastkastes serveris		Bin \\ MSExchangeRepl.exe
  MSExchangeSearch - RPC (TCP ienākošais)	Pastkastes serveris	Dinamiskā RPC	Bin \\ Microsoft.Exchange.Search.ExSearch.exe
  MSExchangeThrottling - RPC (TCP ienākošais)	Pastkastes serveris	Dinamiskā RPC	Bin \\ MSExchangeThrottling.exe
  MSExchangeThrottling - RPCEPMap (TCP ienākošais)	Pastkastes serveris		Bin \\ MSExchangeThrottling.exe
  MSFTED - RPC (TCP ienākošais)	Pastkastes serveris	Dinamiskā RPC
  MSFTED - RPCEPMap (TCP ienākošais)	Pastkastes serveris
  MSExchangeEdgeSync - RPC (ienākošie TCP)	Rumbas transporta serveris	Dinamiskā RPC
  MSExchangeEdgeSync RPCEPMap (TCP ienākošais)	Rumbas transporta serveris		Bin \\ Microsoft.Exchange.EdgeSyncSvc.exe
  MSExchangeTransportWorker - RPC (TCP ienākošais)	Rumbas transporta serveris	Dinamiskā RPC	Bin \\ edgetransport.exe
  MSExchangeTransportWorker - RPCEPMap (TCP ienākošais)	Rumbas transporta serveris		Bin \\ edgetransport.exe
  MSExchangeTransportWorker (GFW) (TCP ienākošais)	Rumbas transporta serveris
  MSExchangeTransportWorker (TCP ienākošais)	Rumbas transporta serveris		Bin \\ edgetransport.exe
  MSExchangeTransportLogSearch - RPC (ienākošie TCP)		Dinamiskā RPC
  MSExchangeTransportLogSearch - RPCEPMap (TCP ienākošais)	Rumbas transports, malu transports, pastkastes serveris		Bin \\ MSExchangeTransportLogSearch.exe
  SESWorker (GFW) (TCP ienākošais)	Vienotais ziņojumapmaiņas serveris
  SESWorker (TCP ienākošais)	Vienotais ziņojumapmaiņas serveris		UnifiedMessaging \\ SESWorker.exe
  UMService (GFW) (TCP ienākošais)	Vienotais ziņojumapmaiņas serveris
  UMService (TCP ienākošais)	Vienotais ziņojumapmaiņas serveris		Bin \\ UMService.exe
  UMWorkerProcess (GFW) (TCP ienākošais)	Vienotais ziņojumapmaiņas serveris	5065, 5066, 5067, 5068
  UMWorkerProcess (TCP ienākošais)	Vienotais ziņojumapmaiņas serveris	5065, 5066, 5067, 5068	Bin \\ UMWorkerProcess.exe
  UMWorkerProcess - RPC (TCP ienākošais)	Vienotais ziņojumapmaiņas serveris	Dinamiskā RPC	Bin \\ UMWorkerProcess.exe

  Piezīmes par Windows ugunsmūra noteikumiem, ko izveidoja Exchange 2010 iestatīšana

  • Serveros, kuros ir instalēta IIS, Windows atver HTTP (80. ports, TCP) un HTTPS (443. ports, TCP) porti. Exchange 2010 uzstādīšana neatver šīs porti. Tāpēc šīs ostas nav norādītas iepriekšējā tabulā.
  • IN Windows Server 2008 un Windows Server 2008 R2 Windows ugunsmūris ar papildu drošību ļauj norādīt procesu vai pakalpojumu, kuram ports ir atvērts. Tas ir drošāk, jo portu var izmantot tikai noteikumā norādītais process vai pakalpojums. Exchange iestatīšana izveido ugunsmūra kārtulas ar norādīto procesa nosaukumu. Dažos gadījumos saderības apsvērumu dēļ tiek izveidots arī papildu noteikums, kas neaprobežojas tikai ar šo procesu. Varat atspējot vai noņemt kārtulas, kas nav ierobežotas ar procesu, un saglabāt atbilstošās procesa ierobežotas kārtulas, ja jūsu pašreizējā izvietošanas vide tos atbalsta. Noteikumus, kas nav ierobežoti ar procesiem, var atšķirt ar vārdu (GFW) noteikuma nosaukumā.
  • Daudzi Exchange pakalpojumi saziņai izmanto attālās procedūras izsaukumus (RPC). Servera procesi, kas izmanto RPC, izveido savienojumu ar RPC gala punktu kartētāju, lai izgūtu dinamiskos galapunktus un reģistrētu tos galapunktu kartētāja datu bāzē. RPC klienti mijiedarbojas ar RPC gala punktu kartētāju, lai noteiktu servera procesa izmantotos galapunktus. Pēc noklusējuma RPC gala punktu kartētājs klausās 135. portu (TCP). Konfigurējot Windows ugunsmūri procesam, kas izmanto attālās procedūras izsaukumus, Exchange 2010 iestatīšana šim procesam izveido divus ugunsmūra noteikumus. Viens noteikums ļauj sazināties ar RPC gala punktu kartētāju, bet otrais ļauj sazināties ar dinamiski piešķirtu galapunktu. Plašāku informāciju par attālo procedūru izsaukumiem skatiet rakstā. Lai iegūtu papildinformāciju par Windows ugunsmūra noteikumu izveidi dinamiskai RPC, skatiet rakstu.

    Papildinformāciju skatiet Microsoft zināšanu bāzes rakstā 179442

Šajā rakstā mēs sapratīsim, kā konfigurēt statiskos RPC portus RPC klienta piekļuvei, Exchange adrešu grāmatai un koplietotās mapes Exchange 2010.

Pieņemsim, ka mums ir sarežģīta organizācija ar Exchange Server 2010 SP1 (vai jaunāku), kas ietver. CAS serveri parasti atrodas tīklā, kuru ugunsmūri atdala no tīkliem, no kuriem lietotājiem vajadzētu piekļūt (Outlook tīkli). Outlook klients izveido savienojumu ar CAS serveri, izmantojot RPC, kas nozīmē, ka jebkuru portu no brīvā porta diapazona var izmantot tīkla līmenī. Nav noslēpums, ka operētājsistēmās Windows Server 2008 un 2008 R2 diapazons 49152-65535 tiek izmantots kā dinamiskā porta diapazons RPC savienojumiem ( iepriekšējās versijas Windows Server izmantoja RPC porti diapazonā 1025-65535).

Lai izvairītos no ugunsmūru pārvēršanas par sietu, ir vēlams sašaurināt izmantoto RPC portu diapazonu, ideālā gadījumā padarot tos statiskus katrā Client Access masīvā esošajā Client Access Server. Turklāt statisko RPC pieslēgvietu izmantošana var samazināt atmiņas patēriņu slodzes līdzsvarotājos (īpaši HLB) un vienkāršot to konfigurāciju (nav jānorāda lieli ostu diapazoni).

Programmā Exchange 2010 varat iestatīt statiskos portus RPC klienta piekļuves pakalpojumam, kā arī Exchange adrešu grāmatas pakalpojumam. Outlook sazinās ar šiem pakalpojumiem, izmantojot MAPI saskarni.

Statiskais ports Exchange 2010 RPC klienta piekļuves pakalpojumam

Virtuālais pakalpojums Exchange 2010 RPC Client Access ir saistīts ar RPC Client Access pakalpojumu, ar kuru Outlook MAPI klienti izveido savienojumu programmā Exchange 2010. Kad Outlook klients izveido savienojumu ar Exchange, Exchange 2010 Client Access RPC klienta piekļuves pakalpojums ienākošajiem savienojumiem izmanto TCP gala punktu kartētāja (TCP / 135) portu un nejaušu portu no RPC dinamiskā porta diapazona (6005-59530).

Lai iestatītu statisku portu RPC klienta piekļuves pakalpojumam Exchange 2010, reģistra redaktorā atveriet šādu atslēgu:

HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ services \\ MSExchangeRPC

Izveidojiet jaunu atslēgu ar nosaukumu ParametersSystemiekšpusē izveidojiet tipa parametru REG_DWORD Ar vārdu TCP / IP ports... TCP / IP porta parametrs norāda statisko portu RPC klienta piekļuves pakalpojumam. Microsoft dokumentācijā ieteicams izvēlēties portu diapazonā no 59531 līdz 60554 un izmantot šo vērtību visos CAS serveros (mēs norādījām portu 59532, protams, to nedrīkst izmantot cita programmatūra).

Pēc statiskā porta iestatīšanas Microsoft Exchange RPC klienta piekļuves pakalpojums ir jārestartē, lai izmaiņas stātos spēkā.

Restartējiet pakalpojumu MSExchangeRPC

Statiskais ports Exchange 2010 adrešu grāmatas pakalpojumam

Programmā Exchange 2010 pirms SP1 pielāgotās konfigurācijas fails tika izmantots, lai iestatītu statisko portu Exchange 2010 adrešu grāmatas pakalpojumam Microsoft.exchange.addressbook.service.exe.config... Pēc Exchange 2010 SP1 izlaišanas, izmantojot reģistru, šim pakalpojumam varat iestatīt statisku portu. Lai to izdarītu, atveriet reģistra redaktoru un dodieties uz filiāli:

HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ services \\ MSExchangeAB \\ Parameters

Izveidojiet jaunu parametru RpcTcpPort(tipa REG_SZ) un piešķiriet tai porta numuru, kuru vēlaties izlabot Exchange adrešu grāmatas pakalpojumam. Mēs iesakām izmantot jebkuru bezmaksas portu diapazonā 59531-60554 un turpināt to izmantot visos Exchange 2010 Client Access serveros domēnā. Mēs iestatīsim RpcTcpPort \u003d 59533

Pēc tam jums ir jārestartē Microsoft Exchange adrešu grāmatas pakalpojums

Restartējiet pakalpojumu MSExchangeAB

Svarīgs: Pārejot no Exchange 2010 RTM uz SP1, šī atslēga jāiestata manuāli, tā netiek automātiski mantota.

Statiska porta konfigurēšana savienojuma izveidei ar koplietotām mapēm

Koplietotajām mapēm piekļūst no Outlook klienta, tieši izmantojot servera RPC Client Access serveri ar lomu Pastkaste. Šis iestatījums jāveic visos serveros ar lomu Pastkaste, kas satur publisko mapju datu bāzi (līdzīgi kā CAS serveriem). Atveriet reģistra redaktoru un dodieties uz filiāli

HKEY_LOCAL_MACHINE \\ SYSTEM \\ CurrentControlSet \\ services \\ MSExchangeRPC

Izveidojiet jaunu atslēgu ar nosaukumu ParametersSystem, kura iekšpusē izveidojiet parametru REG_DWORD ar nosaukumu TCP / IP ports... Iestatiet tā vērtību: TCP / IP ports \u003d 59532.

Pēc statiskas portu iestatīšanas publiskajām mapēm katrā no pastkastes serveriem jārestartē Microsoft Exchange RPC klienta piekļuves pakalpojums.

Statiskā porta lietojuma pārbaude starp Outlook un Exchange 2010

Pēc izmaiņu veikšanas pārbaudīsim, vai Outlook izveido savienojumu ar mūsu norādītajiem statiskajiem RPC portiem. Lai to izdarītu, klienta datorā restartējiet programmu Outlook un pēc tam - komandrinda palaidiet komandu:

Netstat -na