Office Communications Server 2007 – krok po kroku (część 10)

Autor: Jacek Światowiak

Opublikowano: 8 sierpnia 2008

Zawartość strony

	W poprzedniej części
	Ogólna konfiguracja komunikacji pomiędzy organizacją OCS a światem zewnętrznym
	Schemat konfiguracyjny środowiska testowego
	Konfiguracja serwera OCS-EDGE wariant I z dwoma fizycznymi interfejsami sieciowymi
	Zagadnienia konfiguracji serwerów DNS
	Manualna konfiguracja Office Communicatora 2007
	Obsługa dwóch domen sip, wewnętrznej i zewnętrznej
	Zagadnienie routingu na serwerze OCS-EDGE
	Konfiguracja serwera ISA 2006. Tworzenie definicji protokołów i obiektów sieciowych
	Tworzenie reguły dostępu do serwera Web Conferencing Edge
	Tworzenie reguły dostępu do serwera A/V Conferencing Edge
	Konfiguracja reguł publikacji na serwerze ISA
	Tworzenie Listenera
	Tworzenie właściwej reguły publikacji serwera Web
	Modyfikacja ustawień do współpracy z Live Meeting 2007
	W następnej części

W poprzedniej części

W poprzedniej części omówiliśmy zagadnienia związane z konfiguracją serwera Edge. W części 10 przedstawimy różne sposoby publikacji serwera OCS do Internetu z wykorzystaniem serwera ISA 2006 w wersji Standard Edition.

 Do początku strony

Ogólna konfiguracja komunikacji pomiędzy organizacją OCS a światem zewnętrznym

Poniższe dwie tabele syntetycznie przedstawiają konfigurację reguł na firewall’u wewnętrznych i zewnętrznym rozdzielającym strefę DMZ od Internetu oraz od sieci LAN.

Konfiguracja reguł na firewall’u zewnętrznym

Rola serwera OCS

Protokół

Port

Kierunek ruchu

Reverse Proxy

HTTPS (TCP)

443

Wchodzący

Access Edge

SIP/TLS (klient) (TCP)

SIP/MTLS (serwer) (TCP)

443

5061

Wchodzący

W obie strony

Web Conferencing Edge

PSOM/TLS (TCP)

443

Wchodzący

A/V Edge

STUN/TCP

STUN/UDP

RTP/TCP

RTP/UDP

443

3478

50000-59999

50000-59999

Wchodzący

Wchodzący

W obie strony

W obie strony

 

Tabela 10.1: Konfiguracja reguł na firewall’u zewnętrznym

Konfiguracja reguł na firewall’u wewnętrznym

Rola serwera OCS

Protokół

Port

Kierunek ruchu

Reverse Proxy

SIP/TLS (TCP)

443

Wchodzący

Access Edge

SIP/MTLS (TCP)

5061

W obie strony

Web Conferencing Edge

PSOM/MTLS (TCP)

8057

Wychodzący

A/V Edge

STUN/TCP

STUN/UDP

SIP/MTLS

443

3478

5062

Wychodzący

Wychodzący

Wychodzący

 

Tabela 10.2: Konfiguracja reguł na firewall’u wewnętrznym

Konfiguracja poniższa (rysunek 10.1) zakłada, iż w strefie DMZ posługiwać się będziemy adresami PUBLICZNYMI.

Rysunek 10.1: Schemat komunikacji organizacji OCS ze światem zewnętrznym.

Często jednak konfiguracja firewall’i jest nieco inna niż teoretyczne założenia. Serwer ISA 2006 w takim przypadku może pełnić nie tylko rolę Reverse Proxy, ale może być również firewall’em pracującym w konfiguracji 3-interfejsowej. I taką też konfigurację planujemy tu omówić. Każda z ról serwera OCS Edge musi posiadać dwa interfejsy. Jeden służący komunikacji z organizacją OCS wewnątrz sieci LAN, a drugi wykorzystywany do komunikacji ze światem zewnętrznym. W przypadku roli kombinowanej serwera OCS Edge wszystkie role (poza Reverse Proxy) zainstalowane są na tym samym serwerze, zatem konfiguracja będzie nieco bardziej skomplikowana.

Wymóg dodatkowy. Komunikacja pomiędzy siecią organizacją OCS a serwerami EDGE nie może być realizowana poprzez NAT’a, zatem wewnętrzny interfejs serwera(ów) Edge podłączony(any) jest bezpośrednio do sieci wewnętrznej. Schemat środowiska przedstawiono na rysunku poniżej.

 Do początku strony

Schemat konfiguracyjny środowiska testowego

Rysunek 10.2: Schemat konfiguracyjny środowiska testowego.

Konfiguracja serwera ISA-SE-01

Interfejs

Adres

Gateway

Typ adresu IP

Uwagi (Reguły sieciowe)

Internet (External)

50.50.50.50/24

Adres IP routera ISP

Publiczny

 

DMZ

50.51.254/

BRAK

Publiczny

Reguła Route pomiędzy siecią Internet a DMZ

LAN (Internal)

168.0.254/24

BRAK

Prywatny

Reguła NAT pomiędzy siecią Internal a External

 

Tabela 10.3: Konfiguracja serwera ISA-SE-01 (Standard Edition)

Uwaga informacyjna

Nie jest potrzebna żadna reguła sieciowa pomiędzy siecią LAN (Internal) a DMZ.

 Do początku strony

Konfiguracja serwera OCS-EDGE wariant I z dwoma fizycznymi interfejsami sieciowymi

Interfejs

Adres

Gateway

Internal

168.0.85/24

BRAK

DMZ

50.51.1/24

50.51.2/24

50.51.3/24

Zostanie określony globalnie za pomocą polecenia route add

 

Tabela 10.3: Konfiguracja serwera OCS-EDGE – wariant dwu interfejsowy

Konfiguracja serwera OCS-EDGE wariant II z czterema fizycznymi interfejsami sieciowymi

Interfejs

Adres

Gateway

Internal

168.0.85/24

BRAK

SIP

50.51.1/24

Zostanie określony globalnie za pomocą polecenia route add

Web

50.51.2/24

Zostanie określony globalnie za pomocą polecenia route add

AV

50.51.3/24

Zostanie określony globalnie za pomocą polecenia route add

 

Tabela 10.4: Konfiguracja serwera OCS-EDGE – wariant cztero interfejsowy

 Do początku strony

Zagadnienia konfiguracji serwerów DNS

ISA-SE-01 – jedynie na interfejsie Internal zdefiniowany jest adres serwera DNS, wskazuje on na kontroler domeny.

OCS-EDGE – jeżeli jest członkiem domeny – jedynie na interfejsie Internal zdefiniowany jest adres serwera DNS, wskazuje on na kontroler domeny.

OCS-EDGE – jeżeli jest członkiem grupy roboczej – na interfejsach SIP/Web/AV (interfejsach traktowanych, jako zewnętrzne) – definiujemy adres IP, serwera DNS prywatnego (znajdującego się najczęściej w strefie DMZ), lub też publicznego – znajdującego się u operatora – ISP, dla zapewnienia rozwiązywania nazw w przypadku wykorzystania funkcjonalności federacji. Dodatkowo musimy zapewnić rozwiązywanie nazw wewnętrznego serwera OCS (dla routowania wiadomości do wnętrza organizacji OCS)

Wyjaśnienia wymaga zastosowanie w strefie DMZ adresów publicznych.

Winna jest usługa odpowiadająca za komunikację A/V. Posługuje się ona własną metodą translacji adresów/portów określaną, jako STUN. Interfejs ten nie może się znajdować za urządzeniem pełniącym rolę NAT’a. Pozostałe dwa interfejsy SIP i Web mogą znajdować się za NAT’em, ale tworzenie tak niestandardowej konfiguracji może być niewskazane i niewygodne.

Konwencje nazewnicze serwerów, domen i poszczególnych funkcjonalności.

• Nazwa wewnętrzna domeny: test.local
• Nazwa publiczna domeny: test.com

Tabela 10.5: Konwencje nazewnicze domen wewnętrznych i zewnętrznych

Uwaga informacyjna

Jeżeli domena wewnętrzna nie jest zarejestrowana w ogólnoświatowym systemie DNS wówczas nie można włączyć automatyki odpowiadającej za automatyczne wykrycie i rejestrowanie użytkowników zewnętrznych w serwerze Access Edge. Dlatego też najwygodniej jest, gdy domena sip ma taką samą nazwę jak nazwa domeny publicznej danej organizacji.

Oczywiście można włączyć w organizacji OCS obsługę obu nazw domen sip, wewnętrznej jak i zewnętrznej. Wówczas użytkownicy, którzy mają się logować z zewnątrz organizacji mogą zostać zarejestrowani na nazwę publiczną domeny sip.

Inne rozwiązanie to manualna konfiguracja Office Communicatora 2007. Zostanie ona przedstawiona poniżej.

Kolejność odpytywania rekordów (SRV oraz A) w serwerze DNS przez Office Communicatora 2007

Użytkownik ma nazwę SIP zarejestrowaną jako sip:user@test.com,

Stacja robocza jest w domenie: test.local

Najpierw następuje próba odpytania rekordów SRV w przedstawionej poniżej kolejności:

_sipinternaltls._tcp.nazwa_domeny_sip_uzytkownika

_sipinternaltls._tcp.test.com

_sipinternaltls._tcp.nazwa_ domeny_sip_uzytkownika. nazwa_domeny_AD_pochodząca_z_sufixu_domenowego_stacji roboczej

_sipinternaltls._tcp.test.com.test.local

_sip._tls.nazwa_domeny_sip_uzytkownika

_sip._tls.test.com

_sip._tls.nazwa_ domeny_sip_uzytkownika. nazwa_domeny_AD_pochodząca_z_sufixu_domenowego_stacji roboczej

_sip._tls.test.com.test.local

_sipinternal._tcp.nazwa_domeny_sip_uzytkownika

_sipinternal._tcp.test.com

_sipinternal._tcp.nazwa_ domeny_sip_uzytkownika. nazwa_domeny_AD_pochodząca_z_sufixu_domenowego_stacji roboczej

_sipinternal._tcp.test.com.test.local

_sip._tcp.nazwa_domeny_sip_uzytkownika

_sip._tcp.test.com

_sip._tcp.nazwa_ domeny_sip_uzytkownika. nazwa_domeny_AD_pochodząca_z_sufixu_domenowego_stacji roboczej

_sip._tcp.test.com.test.local

Następnie wykonywane są bezpośrednie zapytania o rekordy A dla nazw:

sipinternal. nazwa_domeny_sip_uzytkownika

sipinternal.test.com

sipinternal.nazwa_ domeny_sip_uzytkownika. nazwa_domeny_AD_pochodząca_z_sufixu_domenowego_stacji roboczej

sipinternal.test.com.test.local

sip. nazwa_domeny_sip_uzytkownika

sip.test.com

sip.nazwa_ domeny_sip_uzytkownika. nazwa_domeny_AD_pochodząca_z_sufixu_domenowego_stacji roboczej

sip.test.com.test.local

sipexternal.nazwa_ domeny_sip_uzytkownika

sipexternal.test.com

sipexternal.nazwa_ domeny_sip_uzytkownika. nazwa_domeny_AD_pochodząca_z_sufixu_domenowego_stacji roboczej

sipexternal.test.com.test.local

 Do początku strony

Manualna konfiguracja Office Communicatora 2007

Z menu wybieramy Narzędzia | Opcje…

Rysunek 10.3: Rekonfiguracja Office Communicatora 2007.

Następnie w oknie opcje w zakładce Osobiste klikamy na przycisku Zaawansowane …

Rysunek 10.4: Rekonfiguracja Office Communicatora 2007.

Wybieramy ręczną metodę konfiguracji. Po nazwie publicznej serwera Access Edge musimy podać po dwukropku numer portu 443. Jest to konieczne gdyż inaczej Office Communicator 2007 próbuje zestawić połączenie na domyślny port 5061.

Rysunek 10.5: Rekonfiguracja Office Communicatora 2007.

Nazwy serwerów/funkcjonalności widziane od strony Internetu.

Funkcjonalność serwera

Nazwa publiczna serwera

Access Edge

sip.test.com

Web Conferencing Edge

web-edge.test.com

A/V Conferencing Edge

av-edge.test.com

 

Tabela 10.6: Konwencje nazewnicze poszczególnych funkcjonalności serwera Edge

 Do początku strony

Obsługa dwóch domen sip, wewnętrznej i zewnętrznej

Aby obsługiwać dwie domeny sip, należy wcześniej zrekonfigurować środowisko OCS oraz serwery Edge. Na serwerze Front-End wybieramy ustawienia Globalne i dodajemy nazwę zewnętrznej (kolejnej) obsługiwanej domeny SIP. Poniżej przedstawiany widok ustawień globalnych organizacji OCS.

Rysunek 10.6: Modyfikacja ustawień globalnych organizacji OCS. Dodanie drugiej domeny SIP.

Rysunek 10.7: Widok ustawień globalnych organizacji OCS po dodaniu drugiej domeny SIP (test.com).

Analogicznie zmiany należy wprowadzić na serwerze Edge. Z menu wybieramy opcję Properties i w zakładce Internal dodajemy kolejną obsługiwaną domenę SIP.

Rysunek 10.8: Modyfikacja ustawień serwera Edge. Dodanie drugiej domeny SIP.

 Do początku strony

Zagadnienie routingu na serwerze OCS-EDGE

W przypadku, gdy serwer posiada więcej niż jeden interfejs sieciowy łączący go z wieloma sieciami, topologię routingu nie definiuje się korzystając bezpośrednio z pól właściwości interfejsu sieciowego.

W omawianym przypadku serwer Edge posiada trzy interfejsy sieciowe podłączone do sieci DMZ. Aby dodać routing w takiej konfiguracji należy skorzystać z linii poleceń, z komendy route add.

Przykład zaprezentowany jest na rysunku poniżej.

Rysunek 10.9: Tworzenie wpisu do tabeli routingu.

 Do początku strony

Konfiguracja serwera ISA 2006. Tworzenie definicji protokołów i obiektów sieciowych

Dla wygody i porządku tworzenia reguł dostępu oraz publikacji, należy utworzyć obiekty sieciowe reprezentujące poszczególne funkcjonalności serwera OCS-EDGE: Access Edge, Web Conferencing Edge oraz A/V Edge. Poniżej przedstawiono właściwości trzech omawianych funkcjonalności.

Obiekt reprezentujący serwer Access Edge.

Rysunek 10.10: Utworzenie obiektu sieciowego reprezentującego serwer – Access Edge.

Obiekt reprezentujący serwer Web Conferencing Edge.

Rysunek 10.11: Utworzenie obiektu sieciowego reprezentującego serwer – Web Conferencing Edge.

Obiekt reprezentujący serwer A/V Edge.

Rysunek 10.12: Utworzenie obiektu sieciowego reprezentującego serwer – A/V Edge.

Serwer ISA nie posiada utworzonych definicji protokołów wykorzystywanych przez środowisko OCS 2007 (protokoły MTLS oraz STUN). Muszą one zostać utworzone manualnie. Poniżej przedstawiono tworzenie ich definicji.

Protokół MTLS

W oknie pierwszym kreatora określamy nazwę tworzonego protokołu.

Rysunek 10.13: Tworzenie definicji protokołu MTLS – okno wstępne kreatora.

Kolejne okno to dodawania i konfiguracja protokołów bazowych. Domyślnie lista jest pusta.

Rysunek 10.14: Tworzenie definicji protokołu MTLS – dodawanie protokołów bazowych dla połączenia typu primary.

Protokół MTLS to w rzeczywistości połączenie opierające się o protokół transportowy TCP/ port 5061.

Rysunek 10.15: Tworzenie definicji protokołu MTLS – wybór protokołów bazowych i dodatkowych parametrów.

Rysunek 10.16: Tworzenie definicji protokołu MTLS – okno z dodanymi parametrami protokołów bazowych.

Dla połączenia typu secondary nie definiujemy żadnych parametrów.

Rysunek 10.17: Tworzenie definicji protokołu MTLS - – dodawanie protokołów bazowych dla połączenia typu secondary.

Na koniec okno podsumowania tworzenia nowego protokołu.

Rysunek 10.18: Tworzenie definicji protokołu MTLS – okno podsumowania.

Protokół STUN.

Protokół ten zostanie omówiono analogicznie jak MTLS, jednakże pominięte zostaną okna niemające wpływu na konfigurację. Protokół STUN składać się będzie z trzech elementów:

TCP – zakres portów 50000-59999 – ruch wychodzący

UDP – zakres portów 50000-59999 – ruch wychodzący

UDP – port 3478 – ruch wychodzący

Pierwsze okno jest identyczne jak poprzednio. Określamy nawę tworzonego protokołu.

Rysunek 10.19: Tworzenie definicji protokołu STUN – okno wstępne kreatora.

Kolejne trzy okna to dodawanie definicji protokołów bazowych zgodnie z wcześniejszymi wytycznymi.

Rysunek 10.20: Tworzenie definicji protokołu STUN – wybór protokołów bazowych i dodatkowych parametrów.

Rysunek 10.21: Tworzenie definicji protokołu STUN – wybór protokołów bazowych i dodatkowych parametrów.

Rysunek 10.22: Tworzenie definicji protokołu STUN – wybór protokołów bazowych i dodatkowych parametrów.

Poniżej przedstawiamy okno podsumowania – dla połączenia typu primary.

Rysunek 10.23: Tworzenie definicji protokołu STUN – okno z dodanymi parametrami protokołów bazowych.

Analogicznie jak dla protokołu MTLS, dla połączenia typu secondary nie definiujemy żadnych parametrów.

Rysunek 10.24: Tworzenie definicji protokołu STUN - – dodawanie protokołów bazowych dla połączenia typu secondary.

Okno podsumowania pominiemy, ma widok analogiczny jak dla protokołu MTLS.

Konfiguracja reguł dostępu na serwerze ISA

Przy konfiguracji, gdy w strefie DMZ posługujemy się publicznymi adresami IP, aby zapewnić komunikację z sieci Internet do DMZ należy posłużyć się regułami dostępu (ang. Access Rule). Musimy utworzyć trzy reguły dostępu do wszystkich trzech funkcjonalności serwera Edge.

Tworzenie reguły dostępu do serwera Access Edge

Okno pierwsze to określenie nazwy reguły dostępu.

Rysunek 10.25: Określenie nazwy reguły dostępu.

W kolejnym oknie określamy czy dany ruch ma być przepuszczany, czy blokowany.

Rysunek 10.26: Okno określania przepuszczania lub blokowania danego typu ruchu sieciowego.

W następnym oknie wybieramy z listy przepuszczane protokoły sieciowe.

Rysunek 10.27: Wybór protokołów sieciowych. Okno domyślne – puste.

Dla dostępu do serwera Access Edge włączamy protokoły HTTPS oraz MTLS.

Rysunek 10.28: Wybór protokołów sieciowych.

W kolejnym oknie określamy lokalizacje skąd ruch będzie inicjowany. Tu z sieci zewnętrznej - External.

Rysunek 10.29: Określanie lokalizacji skąd ruch będzie inicjowany.

Następne okno. To określenie, dokąd dany ruch ma być przekazany. Tu do serwera pełniącego rolę serwera Access Edge.

Rysunek 10.30: Określanie lokalizacji, dokąd dany ruch będzie przekazany.

Kolejne okno to określenie, dla jakich użytkowników dany ruch ma być dozwolony/zabroniony. Tu wybieramy All Users (dla wszystkich typów użytkowników zarówno uwierzytelnionych ja i nieuwierzytelnionych)

Rysunek 10.31: Określenie, dla jakich użytkowników dany ruch sieciowy będzie dozwolony lub zabroniony.

Ostatnie okno to podsumowanie działania kreatora.

Rysunek 10.32: Podsumowanie działania kreatora.

Kolejne dwie reguły są analogiczne. Przedstawimy tylko najważniejsze okna konfiguracyjne.

 Do początku strony

Tworzenie reguły dostępu do serwera Web Conferencing Edge

Okno pierwsze to określenie nazwy reguły dostępu.

Rysunek 10.33: Określenie nazwy reguły dostępu.

Drugie okno kreatora pominiemy. Należy zezwolić na ruch do serwera Web Conferencing – Allow. Kolejne okno to wybór protokołów. Do serwera Web Conferencing dostęp dozwolony jest wyłącznie z wykorzystaniem protokołu HTTPS.

Rysunek 10.34: Wybór protokołów sieciowych.

W kolejnym oknie określamy skąd ma być inicjowany ruch sieciowy - z sieci External. W następnym, dokąd – tym razem - do serwera Web Conferencing Edge. Tak jak pokazuje rysunek poniżej.

Rysunek 10.35: Określanie lokalizacji, dokąd dany ruch będzie przekazany.

W przed ostatnim oknie, identycznie jak dla poprzedniej reguły – określamy, iż regułą działa dla wszystkich użytkowników. Okno ostatnie podsumowujące pominiemy.

 Do początku strony

Tworzenie reguły dostępu do serwera A/V Conferencing Edge

Tu już bardzo skrótowo. Proces tworzenia jest identyczny jak poprzednio. Okno pierwsze to określenie nazwy reguły dostępu.

Rysunek 10.36: Określenie nazwy reguły dostępu.

Drugie okno kreatora pominiemy. Należy zezwolić na ruch do serwera A/V Edge – Allow. Kolejne okno to wybór protokołów. Do serwera A/V Edge dostęp dozwolony jest wyłącznie z wykorzystaniem protokołu HTTPS oraz STUN.

Rysunek 10.37: Wybór protokołów sieciowych.

W kolejnym oknie określamy skąd ma być inicjowany ruch sieciowy - z sieci External. W następnym, dokąd – do serwera A/V Edge.

Rysunek 10.38: Określanie lokalizacji, dokąd dany ruch będzie przekazany.

Pozostałe okna są identyczne jak dwóch poprzednich reguł i nie będą ponownie prezentowane.

Pozostaje nierozwiązana kwestia dostępu do Web-service’ów zlokalizowanych na serwerze wewnętrznym (ocs.test.local). Tu należy wykorzystać funkcjonalność Reverse Proxy serwera ISA i opublikować funkcjonalność serwera WWW.

 Do początku strony

Konfiguracja reguł publikacji na serwerze ISA

Należy utworzyć obiekt sieciowy Listener, pracujący bez uwierzytelniania, nasłuchujący na porcie 443 serwera ISA. Komunikacja do Web service’ów jest komunikacją zabezpieczoną w oparciu o certyfikat SSL. Należy, zatem wcześniej na serwerze ISA należy zainstalować certyfikat SSL, na nazwę zewnętrzną, którą się będziemy posługiwali w celach komunikacyjnych z funkcjonalnościami Web-service’ów. Tu wybierzemy: ocs.test.com.

Poniżej przedstawiono okno żądania generacji certyfikatu bazującego na szablonie Web Server. Na rysunku 10.32 definiowane są parametry ogólne certyfikatu, zaś na 10.33 parametry dodatkowe i właściwości związane z generacją klucza publicznego i prywatnego certyfikatu. Ważne jest, aby zaznaczyć opcję: Store certificate in the local computer certificate store .

Rysunek 10.39: Parametry ogólne certyfikatu.

Rysunek 10.40: Parametry dodatkowe i właściwości związane z generacją klucza publicznego i prywatnego certyfikatu.

 Do początku strony

Tworzenie Listenera

Kolejny krok to tworzenie lub modyfikacja Listenera. Jest to obiekt sieciowy, którego zdaniem jest nasłuchiwanie na danych adresie IP oraz porcie żądań komunikacji od użytkowników zewnętrznych. Pierwsze okno kreatora to określanie nazwy tworzonego Listenera.

Rysunek 10.41: Określenie nazwy Listnenera.

W kolejnym oknie określamy czy ruch od klienta do serwera ISA ma być szyfrowany czy też nie. Tu oczywiście wybieramy komunikację szyfrowaną.

Rysunek 10.42: Wybór typu komunikacji pomiędzy klientem a serwerem ISA.

W następnym oknie określamy skąd dany typ ruchu może być inicjowany. W naszym przypadku z sieci zewnętrznej – External (Internet).

Rysunek 10.43: Określanie lokalizacji skąd ruch będzie inicjowany.

W następnym oknie przydzielamy do danego listenera (Adres IP /port) certyfikat SSL, który będzie wykorzystywany do zestawienia komunikacji szyfrowanej pomiędzy klientem a serwerem ISA (w przykładzie certyfikat na nazwę ocs.test.com).

Rysunek 10.44: Okno wyboru certyfikatu SSL.

Rysunek 10.45: Okno podsumowania wyboru i przypisania certyfikatu do danego Listenera.

W kolejnym oknie określamy czy użytkownicy mają być uwierzytelniani na Listenerze czy też nie. W omawianym przypadku, Listener nie odpowiada za uwierzytelnianie użytkowników.

Rysunek 10.46: Wybór metody uwierzytelniania na Listenerze.

Funkcjonalność Single Sign On jest w takiej konfiguracji niedostępny i wyłączona.

Rysunek 10.47: Okno zarządzania funkcjonalnością Single Sign On.

Ostatnie okno to podsumowanie działania kreatora konfiguracji Listenera.

Rysunek 10.48: Okno to podsumowanie działania kreatora konfiguracji Listenera.

Po utworzeniu Listenera, można przystąpić do tworzenia właściwej reguły publikacji serwera Web.

 Do początku strony

Tworzenie właściwej reguły publikacji serwera Web

Pierwsze okno kreatora to określanie nazwy tworzonej reguły publikacji serwera Web.

Rysunek 10.49: Określenie nazwy tworzonej reguły publikacji serwera Web.

W kolejnym oknie określamy czy dany ruch ma być przepuszczany, czy blokowany.

Rysunek 10.50: Okno określania przepuszczania lub blokowania danego typu ruchu sieciowego.

W kolejnym oknie określamy czy publikowany jest pojedynczy serwer, load balancer czy też publikowana jest farma serwerów lub wiele serwerów za pomocą jednej reguły.

Rysunek 10.51: Wybór typu publikacji serwerów Web.

W kolejnym oknie określmy nazwę wewnętrzną publikowanego serwera Web. W naszym przykładzie jest to serwer ocs.test.local.

Rysunek 10.52: Określanie nazwy wewnętrznej publikowanego serwera Web.

W kolejnym oknie można ograniczyć publikację do określonych folderów. Domyślnie cała zawartość serwera Web będzie publikowana.

Rysunek 10.53: Okno ograniczeń narzucanych na publikowany serwer Web.

W kolejnym oknie określamy nazwę zewnętrzną (publiczną) publikowanego serwera Web. W naszym przykładzie jest to ocs.test.com.

Rysunek 10.54: Określanie nazwy zewnętrznej (publicznej) publikowanego serwera Web.

W kolejnym oknie łączymy Listener z daną regułą publikacji serwera Web.

Rysunek 10.55: Łączenie Lisnetera z daną regułą publikacji serwera Web.

W kolejnym oknie określamy, czy uwierzytelnianie ma następować na regule, czy też dozwolone będzie przekazywanie poświadczeń logowania do serwera docelowego. Wybieramy opcję:

No dlegation, but client may authenticate directly.

Rysunek 10.56: Wybór metody przekazywania poświadczeń logowania.

Kolejne okno to określenie, dla jakich użytkowników dany ruch ma być dozwolony/zabroniony. Tu wybieramy All Users (dla wszystkich typów użytkowników zarówno uwierzytelnionych ja i nieuwierzytelnionych).

Rysunek 10.57: Określenie, dla jakich użytkowników dany ruch sieciowy będzie dozwolony lub zabroniony.

Ostatnie okno jest podsumowaniem działania kreatora tworzenia reguły publikacji serwera Web.

Rysunek 10.58: Okno to podsumowanie działania kreatora konfiguracji reguły publikacji serwera Web.

W oknie podsumowania można przetestować działanie reguły. Po kliknięciu na przycisku Test Rule, jeżeli wszystkie elementy będą funkcjonowały prawidłowo, otrzymamy wynik pokazany na rysunku poniżej.

Rysunek 10.59: Efekt przetestowania działania reguły – wynik zakończony powodzeniem.

 Do początku strony

Modyfikacja ustawień do współpracy z Live Meeting 2007

Klienci zewnętrzni (Live Meeting 2007) powinni się podłączyć się pod następujące (omówione w tabeli poniżej) foldery wirtualne zlokalizowane na publikowanym serwerze OCS (Standard Edition) lub na publikowanej puli serwerów Enterprise Edition. Niestety kreator konfiguracji nie umożliwia modyfikacji adresów zewnętrznych wymienionych niżej funkcjonalności. Domyślne pola te są puste i zestawienie sesji Live Meeting pomiędzy klientami zewnętrznymi a wewnętrznymi zakończy się niepowodzeniem.

Publikowany folder

Przeznaczenie

https://nazwa_zewnetrzna/ABS/ext

Folder zawiera pliki książki adresowej (Adress Book)

https://nazwa_zewnetrzna/etc/places/null

Folder zawiera informacje dotyczące aktualnego spotkania /konferencji typu Web

https://nazwa_zewnetrzna/GroupExpansion/ext/services.asmx

Folder zawiera informacje o członkostwie danej grupy

 

Tabela 10.7: Zestawienie folderów, do których powinien mieć dostęp klient Live Meeting 2007

Uwaga informacyjna

Zagadnienie to omawia artykuł z bazy wiedzy o numerze 938288. Error message when you try to use the Live Meeting console to connect to Communications Server 2007: "Live Meeting cannot connect to the meeting."

https://support.microsoft.com/kb/938288/

Poniżej pokazano braki w konfiguracji w/w elementów dla połączeń zewnętrznych.

Ustawienie odpowiadający za dystrybucję informacji o konferencjach typu Web dla klientów zewnętrznych.

Rysunek 10.60: Ustawienie odpowiadający za dystrybucję informacji o konferencjach typu Web dla klientów zewnętrznych.

Ustawienie odpowiadający za dystrybucję informacji o członkostwie w grupach dla klientów zewnętrznych.

Rysunek 10.61: Ustawienie odpowiadający za dystrybucję informacji o członkostwie w grupach dla klientów zewnętrznych.

Ustawienie odpowiadający za dystrybucję książki adresowej (Address Book) dla klientów zewnętrznych.

Rysunek 10.62: Ustawienie odpowiadający za dystrybucję książki adresowej (Address Book) dla klientów zewnętrznych.

Aby tą konfigurację zmodyfikować, nie można się posłużyć bezpośrednio konsolą do zarządzania serwerem OCS. Należy skorzystać z narzędzia wbemtest – odpowiedzialnego za konfigurację z wykorzystaniem interfejsu WMI. Narzędzie to uruchamia się z linii poleceń.

Rysunek 10.63: Uruchomienie narzędzia wbemtest.

Poniżej przedstawiono okno główne dostępne po uruchomieniu.

Rysunek 10.64: Okno główne narzędzia wbemtest dostępne po uruchomieniu.

Należy teraz kliknąć na przycisku Connect

Rysunek 10.65: Wybór przestrzeni nazewniczej WMI.

Należy teraz zmodyfikować domyślną przestrzeń nazewniczą na root\cimv2. Po czym kliknąć jeszcze raz przycisk Connect.

Rysunek 10.66: Okno zmiany przestrzeni nazewniczej.

Po połączeniu okno zmienia wygląd. Należy teraz z dostępnych opcji kliknąć na przycisku Query…

Rysunek 10.67: Okno główne po zmianie przestrzeni nazewniczej.

Teraz w oknie Query należy wpisać ciąg odpowiadający za poszukiwanie danego typu danych. Poszukiwane ciągi będą przedstawione poniżej.

Dla ustawień związanych z członkostwem w grupach:

Dla Communications Server 2007 Enterprise pool

Select * from MSFT_SIPGroupExpansionSetting where backend="server name\\sql instance"

Dla Communications Server 2007 Standard Edition

Select * from MSFT_SIPGroupExpansionSetting where backend="(local)\\rtc"

Rysunek 10.68: Okno Query z wpisanym ciągiem odpowiadającym za ustawienia związane z członkostwem w grupach.

Następnie w oknie wyniku należy kliknąć na wyświetlonym obiekcie.

Rysunek 10.69: Wyświetlony wynik zapytania.

Po czym modyfikujemy wiersz: ExternalDLExpansionWebURL

Rysunek 10.70: Modyfikacja wiersza ExternalDLExpansionWebURL.

Dla ustawień odpowiadających za dystrybucję informacji o konferencjach typu Web dla klientów zewnętrznych:

Dla Communications Server 2007 Enterprise pool

Select * from MSFT_SIPDataMCUCapabilitySetting where backend="server name\\sql instance"

Dla Communications Server 2007 Standard Edition

Select * from MSFT_SIPDataMCUCapabilitySetting where backend="(local)\\rtc"

Rysunek 10.71: Okno Query z wpisanym ciągiem odpowiadającym za konferencje typu Web dla klientów zewnętrznych.

Po czym modyfikujemy wiersz: ExternalClientContentDownloadURL

Rysunek 10.72: Modyfikacja wiersza ExternalClientContentDownloadURL.

Dla ustawień odpowiadających za dystrybucję informacji o książce adresowej dla klientów zewnętrznych:

Dla Communications Server 2007 Enterprise pool

Select * from MSFT_SIPAddressBookSetting where backend="server name\\sql instance"

Dla Communications Server 2007 Standard Edition

Select * from MSFT_SIPAddressBookSetting where backend="(local)\\rtc"

Rysunek 10.73: Okno Query z wpisanym ciągiem odpowiadającym za dystrybucję informacji o książce adresowej dla klientów zewnętrznych.

Po czym modyfikujemy wiersz: ExternalURL

Rysunek 10.74: Modyfikacja wiersza ExternalURL.

Wartości poszczególnych pól po wprowadzeniu modyfikacji:

Zmodyfikowane ustawienie odpowiadający za dystrybucję informacji o konferencjach typu Web dla klientów zewnętrznych.

Rysunek 10.75: Zmodyfikowane ustawienie odpowiadający za dystrybucję informacji o konferencjach typu Web dla klientów zewnętrznych.

Zmodyfikowane ustawienie odpowiadające za dystrybucję informacji o członkostwie w grupach dla klientów zewnętrznych.

Rysunek 10.76: Zmodyfikowane ustawienie odpowiadające za dystrybucję informacji o członkostwie w grupach dla klientów zewnętrznych.

Zmodyfikowane ustawienie odpowiadające za dystrybucję książki adresowej (Address Book) dla klientów zewnętrznych.

Rysunek 10.77: Zmodyfikowane ustawienie odpowiadające za dystrybucję książki adresowej (Address Book) dla klientów zewnętrznych.

Po tych operacjach restart usług nie jest konieczny i możemy skutecznie zestawić połączenie typu Live Meeting 2007 pomiędzy użytkownikami wewnętrznymi a znajdującymi się poza siecią LAN.

 Do początku strony

W następnej części

W kolejnej części omówione zostanę role serwerów CDR, Archiving oraz Mediation Server.

• Office Communications Server 2007 – krok po kroku (część 1)
• Office Communications Server 2007 – krok po kroku (część 2)
• Office Communications Server 2007 – krok po kroku (część 3)
• Office Communications Server 2007 – krok po kroku (część 4)
• Office Communications Server 2007 – krok po kroku (część 5)
• Office Communications Server 2007 – krok po kroku (część 6)
• Office Communications Server 2007 – krok po kroku (część 7)
• Office Communications Server 2007 – krok po kroku (część 8)
• Office Communications Server 2007 – krok po kroku (część 9)

---

Jacek Światowiak (MCT, MCSE, MCSE+M, MCSE+S, MCTS, MCP) Absolwent Wydział Elektroniki, Telekomunikacji i Informatyki Politechniki Gdańskiej. Obecnie zatrudniony w Altkom Akademia S.A. jako Trener Technologii Microsoft. Posiada bogate doświadczenie w zakresie wdrażania różnych technologii informatycznych. Od 2002 roku wykładowca Technologii i Protokołów Sieciowych na Podyplomowym Studium Politechniki Gdańskiej. Jest współautorem skryptu dla studentów informatyki: „Protokoły IPv6 – Opis protokołów. Materiały do laboratorium”. Posiada certyfikaty MCT, MCSE, MCSE+M, MCSE+S, MCTS Microsoft Exchange Server 2007, MCP ID 3621156.

Do początku strony

---