Planowanie przejścia na system ujednoliconej komunikacji

Autor: Jeff Goodwin

Opublikowano: 1 grudnia 2008

Zawartość strony

	Krótka historia poczty głosowej
	Planowanie migracji
	Praktyczne strategie migracji
	Migracja krok po kroku
	Znaczenie działania zgodnego z planem
	Problemy z wieloma lokalizacjami

Przejście ze starego systemu poczty głosowej na platformę ujednoliconej komunikacji może stanowić wyzwanie. Jednak dzięki odpowiedniemu planowaniu można całkiem łatwo wykonać tę migrację, minimalizując wszelkie zakłócenia, których mogą doświadczyć użytkownicy. W rzeczywistości minimalizacja zakłóceń usług powinna być prawdopodobnie podstawowym celem przy uruchamianiu tego rodzaju projektu migracji.

Aby wiedzieć, jakie przygotowania trzeba poczynić do naszej migracji, musimy najpierw zrozumieć, dlaczego firmy uważają pocztę głosową za aplikację krytyczną dla ich misji. Te podstawowe informacje pomogą nam zrozumieć, które funkcje należy zaimplementować przy przechodzeniu na system Unified Messaging i dlaczego te funkcje będą ważne dla administratorów.

Krótka historia poczty głosowej

Ponieważ nie możemy tak naprawdę zaplanować, jak osiągnąć nasz cel, jeśli nie wiemy, gdzie zacznie się nasza podróż, chcę cofnąć się i podać krótki przegląd systemów poczty głosowej – skąd pochodzą i jak są zbudowane. Istnieją spory na temat tego, kto wynalazł pierwszy system poczty głosowej. Jednak pierwszy dostępny na rynku system nosił nazwę VMX, co było skrótem od Voice Message Exchange.

VMX był pierwotnie zaprojektowany do zapewnienia metody komunikacji za pośrednictwem głosu z innymi osobami z danej firmie, tak jak dziś stosowana jest poczta e-mail. System miał takie polecenia, jak wysyłanie wiadomości, przekazywanie ich dalej oraz odpowiadanie na wiadomość. Kiedy wiadomość została zostawiona, użytkownik był o tym powiadamiany. Metody powiadamiania były różne i obejmowały wywoływanie (dzwonienie do danej osoby na określony numer telefonu) oraz światło oczekującej wiadomości (lampka wskaźnika na osobistym telefonie).

Popularność VMX nadal rosła, a organizacje zaczęły łączyć w sieć swoje systemy poczty głosowej. To zapewniało rozwiązanie poczty głosowej w całym przedsiębiorstwie, w którym pracownicy mogą wysyłać wiadomości w trybie rozgłaszania do listy dystrybucji w całej firmie.

Oczywiście aby zapewnić metodę interakcji z systemem poczty głosowej, musi być utworzony tonowy interfejs użytkownika (touch-tone user interface, TUI). Interfejsy użytkownika TUI zmieniały się przez lata i niestety nie ma standardowego interfejsu dla poczty głosowej. Osoby, które mają pocztę głosową w swoim telefonie komórkowym, prawdopodobnie przywykły do słuchania czegoś w rodzaju: „naciśnij 1, aby odebrać pocztę głosową”. Ponieważ sterowane mową systemy poczty głosowej, które wykorzystują głosowe interfejsy użytkownika (VUI) stają się coraz bardziej powszechne, sam TUI nie jest tak ważny, jak był dawniej. Nie należy jednak lekceważyć przywiązania użytkowników do określonego interfejsu.

Obecnie stosowane systemy poczty głosowej przedsiębiorstwa funkcjonują w oparciu o dwie odrębne architektury: rozproszoną i scentralizowaną. Na rysunku 1 biura w Seattle, Nowym Jorku i Austin mają rozproszoną architekturę poczty głosowej, w której systemy poczty głosowej są razem umieszczone w każdej z tych lokalizacji. Natomiast biura w Londynie, Paryżu i w Glasgow mają model scentralizowany, w którym cała infrastruktura PBX jest podłączona do sieci, a wywołania są kierowane z powrotem do centralnej lokalizacji w Londynie. Obydwa modele mają zalety i wady. Zauważmy jednak, że w modelu rozproszonym systemy poczty głosowej mogą być razem podłączone do sieci w celu dostarczania wiadomości między lokalizacjami.

Rysunek 1: Dwa popularne modele architektury poczty głosowej.

Są trzy podstawowe powody, dla których organizacja może wybrać zastosowanie modelu rozproszonego: potrzeba lokalnej dostępności, użycie niejednorodnych systemów PBX, które nie mogą być podłączone razem do sieci oraz ograniczenia jednolitego planu numeracji.

Niektóre organizacje wymagają takiego systemu poczty głosowej, aby w przypadku przerwy w działaniu sieci lokalna centrala PBX oraz system poczty głosowej nadal działały normalnie, zapewniając lokalizacji pełną funkcjonalność systemu. Systemy Interaktywnej odpowiedzi głosowej (IVR) nadal będą działać, a dzwoniący z zewnątrz będą nadal pozostawiać wiadomości. W rezultacie przerwa nie ma wpływu na użytkowników, a praca toczy się dalej jak zwykle. To może brzmieć znajomo – z tego samego powodu wiele organizacji wybiera decentralizację swoich serwerów z uruchomionym Microsoft® Exchange Server. Dana organizacja może chcieć dokonać oceny ryzyka, czy takie lokalne zapewnienie przetrwania jest konieczne.

Kiedy organizacja będzie rosła poprzez przejęcia, jej zdalne lokalizacje często będą miały platformy PBX, które nie mogą być łączone w sieć z resztą infrastruktury. W tym przypadku organizacje mogą albo wymienić PBX, co może być projektem kosztowym lub pozostawić lokalizację bez zmian i połączyć w sieć platformę poczty głosowej, tak aby dostarczyć nieprzerwaną wymianę wiadomości głosowych. Są także dostępne serwery innych firm, które pomagają łączyć w sieć odmienne systemy głosowe.

Aby połączyć ze sobą w sieć centrale PBX, wymagany jest jednolity plan numeracji (UDP). Zgodnie z UDP numery wewnętrzne telefoniczne i poczty głosowej nie mogą się pokrywać. Zwróćmy uwagę, że na rysunku 1 Seattle, Nowy Jork oraz Austin mają nakładające się zakresy numerów wewnętrznych. Wynika to z faktu, że nie ma żadnego planu UDP dla lokalizacji w Stanach Zjednoczonych. UDP może być utworzony poprzez rozszerzenie zakresów numerów wewnętrznych do 7 lub 10 cyfr, lecz to powoduje inne problemy.

Może być konieczna zmiana szablonów wybierania na każdym telefonie, zmiana wszystkich numerów wewnętrznych w centrali PBX oraz zmiana wszelkich aplikacji, które są włączone w system. A to może być powodem frustracji pracowników, którzy teraz będą musieli pamiętać i wybierać 7- lub 10-cyfrowe numery, aby się zadzwonić do kogoś na końcu korytarza.

Podczas gdy te podstawowe funkcje i wyzwania architektoniczne zostały w ciągu ostatnich lat ulepszone, podstawy poczty głosowej pozostają takie same. Wymiana wiadomości, tworzenie sieci, metody powiadamiania, interfejs użytkownika oraz architektura są ważnymi czynnikami, które trzeba mieć na uwadze przy planowaniu migracji.

 Do początku strony

Planowanie migracji

Ujednolicona komunikacja przynosi zmiany w każdej części organizacji – od sposobu interakcji użytkowników z pocztą głosową do tego, jak ta architektura jest zaprojektowana i jak administratorzy radzą sobie z zarządzaniem nią. Wszystkimi tymi różnicami trzeba się zająć podczas migracji do systemu ujednoliconej komunikacji. Poniżej podano listę spraw, które trzeba wziąć pod uwagę przy planowaniu migracji.

Tworzenie sieci dla komunikacji Każda organizacja, która przechodzi ze starszej platformy poczty głosowej do Exchange Unified Messaging musi przejść okres ich koegzystencji. Jeśli organizacja ma już wdrożoną sieć komunikacji, która jest systemem współdziałania różnych systemów głosowych, dodaje po prostu system Unified Messaging do listy istniejących systemów. Każdej organizacji gorąco polecam tworzenie sieci komunikacji, która zawiera wiele lokalizacji z odrębną pocztą głosową lub systemami PBX.

Infrastruktura Zaprojektowanie infrastruktury dla ujednoliconej komunikacji będzie wymagać podjęcia decyzji dotyczących wymagań pracy w sieci, integracji telefonii, umiejscowienia serwera i tym podobnych. Osoby niezaznajomione z podstawowymi strategiami wdrażania, powinny przeczytać mój poprzedni artykuł „Deploying Unified Messaging with Exchange Server 2007” (patrz technet.microsoft.com/magazine/cc137737).

Automatyczni operatorzy Wiele systemów zawiera kilka automatycznych operatorów – różnych, powiedzmy, w ciągu dnia, nocy i w różnych działach. Trzeba popracować ze swoim zespołem ds. telekomunikacji w organizacji, aby odzwierciedlić automatycznych operatorów w starszych systemach poczty głosowej.

Wskazanie oczekującej wiadomości Można sobie zażyczyć, aby nasze rozwiązanie działało bez wskaźników wiadomości oczekujących, lecz użytkownicy będą prawdopodobnie żądać tej funkcji. Więc nie można lekceważyć faktu, że użytkownicy są przywiązani do powiadamiania czerwoną lampką. Na szczęście jest kilka firm, które opracowały aplikacje wskaźnika wiadomości dla Exchange Servera.

Obsługa faksu Wiele starszych platform poczty głosowej obsługuje wewnętrzne wysyłanie faksów. Exchange Unified Messaging również obsługuje możliwości wewnętrznego wysyłania faksów, można więc zaplanować jego obsługę w nowym wdrożeniu.

Interaktywna odpowiedź głosowa Niektóre starsze platformy poczty głosowej obsługują aplikacje Interaktywnej odpowiedzi głosowej (IVR), których nie może zdublować Exchange Unified Messaging. Możemy pozostawić funkcjonowanie tych systemów, zanim nie znajdziemy odpowiedniej alternatywy.

Administracja Exchange Unified Messaging funkcjonuje w oparciu o Active Directory® oraz rolę Exchange Mailbox Server. Może być potrzebny plan, jak wdrożenie Unified Messaging będzie wpływać na administrację, wymagania systemu i tym podobne elementy.

Interfejs użytkownika Przy rozwijaniu nowego interfejsu użytkownika trzeba zapewnić szkolenie jego użytkownikom. Exchange Unified Messaging posługuje się interfejsem, który jest bardzo podobny do interfejsów większości dostawców Internetu, więc powinien być on dość intuicyjny dla większości użytkowników. Wykorzystuje również rozpoznawanie mowy, tak aby użytkownicy nie musieli użyć wybierania tonowego. W Exchange Server funkcja ta nosi nazwę Outlook® Voice Access.

Szkolenie Unified Messaging przynosi zmianę modelu w sposobie komunikacji użytkowników oraz użycia poczty głosowej. Poza interfejsem, trzeba użytkownikom zapewnić szkolenie w zakresie najlepszych praktyk i zaprezentować im nowe, bardzie efektywne sposoby, w jaki będą mogli się komunikować. Na przykład użytkownicy mogą nie wiedzieć, jak współdziałać z pocztą głosową w swojej skrzynce odbiorczej lub jak konfigurować niektóre zaawansowane ustawienia ujednoliconej komunikacji.

 Do początku strony

Praktyczne strategie migracji

Bez wątpienia migracja w dużej organizacji do rozwiązania ujednoliconej komunikacji zawiera wyzwania. Od 10 lat pracuję jednak z ujednoliconą komunikacją i widziałem udane migracje nawet najbardziej złożonych organizacji z bardzo specyficznymi wymaganiami.

Niezależnie od tego, czy mamy do czynienia w organizacji z jedną, czy też wieloma lokalizacjami, pomocne dla nas będzie zbudowanie swojej strategii migracji wokół następujących pięciu podstawowych kroków:

1. Zaplanowanie i zaprojektowanie rozwiązania.

2. Zainstalowanie i skonfigurowanie roli Unified Messaging Server.

3. Migracja grupy pilotażowej.

4. Poprawienie projektu w oparciu o opinie grupy pilotażowej.

5. Migracja użytkowników.

Organizacje z wieloma lokalizacjami stają oczywiście w obliczu wielu wyzwań, których nie ma w scenariuszach z jedną lokalizacją. Te problemy są omówione oddzielnie w sekcji „Problemy z wieloma lokalizacjami”.

Planowanie i projektowanie rozwiązania jest najważniejszym etapem procesu migracji. Zalecam wyznaczenie w projekcie zespołu ds. ujednoliconej komunikacji. Ten zespół powinien obejmować przedstawicieli różnych części organizacji z doświadczeniem w dziedzinie telekomunikacji, Active Directory, Exchange, pracy w sieci, zabezpieczeń, szkolenia i zarządzania projektem. Trzeba też uzyskać szczegółowy rysunek architektury istniejącej w organizacji centrali PBX, poczty głosowej oraz infrastruktur poczty e-mail.

Gdy już będziemy mieć projekt, możemy zainstalować i skonfigurować rolę Unified Messaging Server. Nie obawiajmy się instalowania serwera United Messaging równolegle z istniejącym starszym systemem poczty głosowej. Trzeba mieć jedynie pewność, że postępujemy zgodnie z udokumentowanymi najlepszymi praktykami.

W tym momencie jesteśmy gotowi do wypróbowania naszego serwera Unified Messaging. Wyznaczmy małą pilotażową grupę użytkowników i przenieśmy ją do nowego system. Grupa od 25 do 50 użytkowników będzie odpowiednia. Wybierzmy starannie użytkowników tworząc grupę pilotażową składającą się z różnych grup użytkowników, od pracowników IT i telekomunikacji do menedżerów działów i personelu sprzedaży. Uwzględniając tak szeroki zakres osób, można lepiej określić, czy nasz projekt spełnia swoje cele, jakie określone wymagania trzeba uwzględnić, jakie szkolenie może być konieczne dla użytkowników i tak dalej.

Po otrzymaniu opinii od grupy pilotażowej, trzeba poprawić projekt, aby rozwiązać wszelkie kwestie, które zostały wykryte przy testowaniu. W szczególności, trzeba ponownie przejść do spraw omówionych w punkcie „Sprawy do rozważenia" i upewnić się, że tymi punktami zajęliśmy się właściwie dla naszej organizacji. Zwróćmy uwagę, że większość dokonywanych tutaj powszechnie zmian zwykle dotyczy szkolenia.

Ostatnim krokiem jest migracja użytkowników. Istnieje wiele opinii i strategii dotyczących tego, jak przenosić system do pełnej eksploatacji. Dwie główne metodologie to stopniowa migracja oraz natychmiastowa zmiana.

Jeśli wybierzemy stopniowe przenoszenie społeczności użytkowników w ciągu tygodni lub miesięcy, utworzymy wyspy poczty głosowej między użytkownikami starego systemu i ujednoliconej komunikacji. To uniemożliwi użytkownikom przesyłanie wiadomości między sobą za pośrednictwem poczty głosowej. A jeśli projekt nie obejmuje tworzenia sieci komunikacji, zakłócimy niektóre metody komunikacji biznesowej. Jeśli więc zamierzamy tak zrobić, musimy się upewnić, że początkowy projekt obejmuje rozwiązania dla sieci komunikacji.

Przy natychmiastowej migracji przenosimy wszystkich użytkowników w jednym etapie. Organizacje zwykle wykonują ten rodzaj migracji w czasie weekendu, aby mieć czas na przetestowanie systemu, dokonanie zmian w konfiguracji i cofnięcie migracji w przypadku napotkania poważnej przeszkody.

Niezależnie od wybranej metody, trzeba koniecznie przeszkolić personel pomocy technicznej w zakresie częstych pytań i odpowiedzi, jakie zbierzemy od grupy pilotażowej. Trzeba także się upewnić, że pracownicy pomocy technicznej są biegli w wykonywaniu kluczowych zadań, obejmujących uaktywnianie użytkownika, potwierdzanie, że użytkownik jest aktywny oraz zmienianie hasła.

 Do początku strony

Migracja krok po kroku

Kiedy analizuję swoją przykładową migrację, skupiam swoją uwagę na fakcie, że podstawowym celem udanej migracji do Unified Messaging jest przeniesienie skrzynek pocztowych użytkowników ze starszej platformy poczty głosowej do Unified Messaging z możliwie jak najmniejszym zakłóceniem dla użytkowników (zarówno wewnętrznych, jak i zewnętrznych).

N rysunku 2 widać szczegóły architektury organizacji. Nie planuje ona zmiany tej mieszanej architektury Exchange. Biura amerykańskie mają główne centrum danych zlokalizowane w Seattle. Wszystkie aplikacje IT dla Austin są obsługiwane z Seattle, a biuro Nowym Jorku gwarantuje zdecentralizowane usługi Exchange. Poczta głosowa dla lokalizacji amerykańskich jest rozproszona z powodu odmiennych infrastruktur PBX. Z technicznego punktu widzenia infrastruktura PBX nie może być połączona w sieć, aby zapewnić scentralizowaną pocztę głosową. Natomiast biura europejskie mają scentralizowane centrum danych, mieszczące się w Londynie. Wszystkie aplikacje IT oraz telekomunikacyjne w Europie są obsługiwane z tego głównego centrum danych.

Rysunek 2: Przykładowa architektura przed migracją.

Cała infrastruktura poczty głosowej jest oparta na platformie Octel (teraz znanej jako Avaya). Wszystkie systemy poczty głosowej zostały połączone razem w sieć przy użyciu Octel Analog Networking (OAN), będącego firmowym protokołem sieciowym, który wykorzystuje linie telefoniczne i rozmowy międzymiastowe do wysyłania wiadomości poczty głosowej w sieci. Ta architektura umożliwia przesyłanie wiadomości głosowych pomiędzy lokalizacjami w całej korporacji.

Zespół ds. ujednoliconej komunikacji zdecydował o migracji z brzegu sieci do jej rdzenia. Dla wszystkich lokalizacji umieszczenie serwera Unified Messaging będzie wykonane zgodnie z najlepszą praktyką budowy serwera Exchange. Zespół buduje swoją własną dokumentację planów dla każdej lokalizacji, mając na uwadze kwestie omówione w części „Sprawy do rozważenia”. Dokumentacja jest wykorzystywana podczas instalacji i konfiguracji serwerów, podczas szkolenia użytkowników oraz przy planowaniu strategii migracji.

Dla każdej lokalizacji zespół planuje natychmiastowe przeniesienie do systemu jednolitej komunikacji oraz pozostawienie na miejscu starszej platformy do obsługi aplikacji IVR, które nadal pozostają w użyciu, zanim nie zostanie znalezione alternatywne rozwiązanie. Zespół zdecydował się czekać 30 dni po migracji przed przejściem do następnej lokalizacji. Ten okres oczekiwania ma sprawić, że każda lokalizacja będzie dostosowana do nowej platformy przed przeniesieniem większej liczby użytkowników i dodaniem większej liczby telefonów obsługi pomocy technicznej.

Organizacja zdecydowała, aby najpierw przenieść lokalizację w Austin. Ponieważ poczta e-mail dla Austin jest obsługiwana w Seattle, zespół instaluje rolę Unified Messaging Server w Seattle i zapewnia integrację PBX poprzez instalowanie SIP Gateway w Austin. Ponieważ starsza platforma poczty głosowej jest razem podłączona do sieci, zespół musi spełnić potrzeby pracy w sieci platformy Unified Messaging, instalując serwer Message Networking. Użytkownicy są szkoleni w nowym systemie i migracja idzie bez zakłóceń, więc zespół decyduje się na migrację Nowego Jorku w następnej kolejności.

Lokalizacja w Nowym Jorku ma swoje własne serwery Mailbox oraz Hub Transport. A zatem, według najlepszych praktyk, serwer Unified Messaging powinien być zainstalowany w Nowym Jorku. Zespół instaluje serwer, postępując zgodnie z dokumentami planowania migracji. Serwer jest dodawany do listy węzłów w serwerze Message Networking, które mają być objęte siecią poczty głosowej. Użytkownicy są szkoleni i bez problemów przechodzą na ujednoliconą komunikację.

Lokalizacja w Seattle ma już serwer Unified Messaging wdrożony na etapie migracji Austin. Zespół określił, że serwer zawiera dostateczną liczbę portów do obsługi zarówno lokalizacji w Seattle, jak i Austin. Użytkownicy w Seattle są szkoleni i przechodzą na ujednoliconą komunikację.

Architektura w Europie jest dużo łatwiejsza do zaprojektowania. Infrastruktura PBX jest połączona razem w sieć, a Exchange jest scentralizowane. Serwer Unified Messaging jest wdrożony w Londynie i wszystkie lokalizacje są przenoszone, zaczynając od najmniejszej. Ostateczna architektura jest pokazana na r ysunku 3.

Rysunek 3: Przykładowa architektura po migracji.

 Do początku strony

Znaczenie działania zgodnego z planem

Zostałem poproszony o rozwiązanie problemów wielu nieudanych migracji do jednolitej komunikacji. Wiele z tych organizacji złamało jedną lub więcej kluczowych zasad.

Po pierwsze, zawsze trzeba pamiętać, że nie jest to tylko system poczty głosowej. Jest to aplikacja krytyczna dla misji i powinna być traktowana jako taka. Użytkownicy opierają się na technologiach poczty głosowej w celu wymiany informacji. Pamiętajmy, że jest to aplikacja biznesowa i planujmy swoją migrację, biorąc pod uwagę wszystkie rozważania omówione w tym artykule.

Koniecznie trzeba zaangażować zespół telekomunikacyjny w każdą migrację do ujednoliconej komunikacji. Zespół telekomunikacyjny będzie miał najlepsze pojęcie o aplikacjach telefonii, które są integrowane z infrastrukturą korporacji.

Przy przechodzeniu do ujednoliconej komunikacji planujemy rozwiązanie dla całego przedsiębiorstwa. Chociaż na początku możemy tylko implementować pojedynczą lokalizację, powinniśmy zawsze pamiętać o szerszym obrazie. Na przykład implementowanie pojedynczej lokalizacji bez zapewnienia sieci komunikacji w innych lokalizacjach będzie miało wpływ na komunikację między użytkownikami. To oczywiście będzie duże zadanie, więc nie trzeba się obawiać konsultacji ze specjalistą, aby zaprojektować architekturę, która uwzględni wszystkie aplikacje IT.

Na koniec, nie można niedoceniać wagi szkolenia. Unified Messaging przynosi zmianę modelu w sposobie komunikacji i interakcji użytkowników z pocztą głosową. To, co wydaje nam się intuicyjne, może nie być tak intuicyjne dla innych. Dobre szkolenie jest kluczem do tworzenia możliwie jak najspokojniejszych przejść.

 Do początku strony

Problemy z wieloma lokalizacjami

Organizacje mające wiele ośrodków stają w obliczu sporej liczby wyzwań podczas wdrażania Unified Messaging. Na szczęście możemy się uczyć na podstawie niektórych problemów, z którymi już miały do czynienia inne organizacje. W tym artykule nie mogę zająć się wszystkimi problemami, lecz mogę podać te najbardziej popularne, jakie napotkałem, pracując z różnymi organizacjami.

„Mam scentralizowaną architekturę Exchange i mieszane środowisko telefonii”

Rozproszone środowisko jest łatwe do zaprojektowania. Stawiamy serwer Unified Messaging i integrujemy go z lokalną centralą PBX w każdej lokalizacji. Co jednak w przypadku, gdy mamy scentralizowane lub nawet mieszane środowisko? Pytanie, jakie musimy sobie postawić, to czy jest nam potrzebna zdolność do przetrwania lokalnej ujednoliconej komunikacji w danej lokalizacji. W takiej sytuacji lokalizacja może utracić swoje połączenia z centralnym serwerem Exchange i nadal zapewniać funkcję automatycznego operatora funkcjonalności oraz pozwalać rozmówcom zewnętrznym (całkiem możliwe, że będą to klienci) na pozostawianie wiadomości. Odpowiedź będzie przypuszczalnie zależeć od tego, jaka jest misja krytyczna tej lokalizacji oraz jaka będzie możliwość zarządzania tym rozwiązaniem.

Jeśli wymagamy lokalnej możliwości przetrwania dla naszej lokalizacji, dobrą opcją może być zdalny serwer Unified Messaging w tej lokalizacji. Jeśli nie jest to wymagane, można w lokalnej lokalizacji zainstalować bramę SIP. Exchange Unified Messaging jest elastyczny i nie wymaga wspólnej pracy w sieci z infrastrukturą PBX oraz nie jest konieczny jednolity plan numeracji.

„Jestem w trakcie uaktualniania swojej architektury Exchange”

Wielu klientów waha się, czy rozpoczynać migrację Unified Messaging, gdy są w trakcie uaktualniania swojej architektury Exchange. Moja rada jest taka, że jeśli już została podjęta decyzja o przejściu na Unified Messaging, trzeba iść naprzód i dokonać migracji w czasie uaktualniania serwera Exchange. Postępujmy zgodnie z naszymi planami uaktualnienia, a wtedy nie powinno to w znaczący sposób skomplikować projektu.

„Mam dużo małych lokalizacji z mniej niż 10 osobami, a w niektórych z nich nie ma PBX”

Wszystko, co trzeba zrobić w mniejszych lokalizacjach, które mają na miejscu centrale PBX, to lokalnie zainstalować bramę SIP. Dla lokalizacji, które nie mają na miejscu centrali PBX, istnieją techniki telefoniczne, których można użyć do przekazania rozmów do centralnej PBX w celu ich routingu do systemu Unified Messaging. Krótko mówiąc, można całkiem niedrogo wdrożyć usługi Unified Messaging w mniejszych, zdalnych lokalizacjach w organizacji.

Trzeba zwrócić uwagę, że te mniejsze lokalizacje w rzeczywistości zapewniają doskonałe obszary do testowania migracji. Jedną z popularnych strategii migracji jest rozpoczynanie jej na brzegu sieci i następnie przenoszenie się do rdzenia. Najpierw przenosimy mniejsze lokalizacje, a następnie wykonujemy analizę z zespołem, aby wykryć, co poszło dobrze i jakie problemy napotkaliśmy. Potem przy migrowaniu następnej lokalizacji możemy skorzystać z tych lekcji.

O autorze

Jeff Goodwin piastuje stanowisko Senior Technologist w firmie VIA Group. Specjalizuje się w projektowaniu i wdrożeniu technologii Exchange oraz Unified Messaging. Można skontaktować się z nim pod adresem jgoodwin@theviagroup.com.

Do początku strony