Rozdział 21
Implementacja NT 4 Server z myślą o Active Directory
Możemy mieć różne ważne powody, aby wybrać implementację Windows NT 4 Server zamiast systemu Windows 2000 Server w projekcie infrastruktury - na razie. Niektóre z bardziej znaczących powodów to:
Istniejąca umowa serwisowa — można zlecić część lub całą instalację NT 4 Server na podstawie umowy serwisowej --> (SLA - Service Level Agreement)[Author:AJ] , gwarantującej wysoki poziom czasu sprawności (uptime) lub procentowej dostępności. Do niedawna większe organizacje świadczące usługi serwisowe i wsparcie niechętnie udzielały takich gwarancji swoim klientom bazującym na systemach NT Server. Jednakże ostatnio kilka organizacji z dużą agresywnością oferuje umowy gwarantujące dostępność aż do 99,9%. Podobne gwarancje dla instalacji Windows 2000 z Active Directory przypuszczalnie jeszcze przez jakiś czas nie będą dostępne.
Plan wdrożenia Windows 2000 Server musiałby być wyjątkowo agresywny — osobiście nigdy nie próbowałbym przekonać dowolnej średnich rozmiarów firmy do zaprojektowania planu wdrożenia, w którym etapy planowania, dowodu poprawności koncepcji i wdrożenia pilotowego miałyby zostać wykonane w czasie krótszym od roku. Podobnie duże przedsiębiorstwo na to samo potrzebowałoby przynajmniej półtora roku, przypuszczalnie dwóch lat. Taki harmonogram może być w pewnych okolicznościach uznany za niemożliwy do przyjęcia. W takiej sytuacji tym razem trzeba pozostać przy systemie NT 4 Server.
Lęk przed nieznanym — ponieważ Windows NT 4 Server jest zasadniczo podrasowaną wersją NT 3.51 Server, wielu --> odsprzedawców wartości dodanej[Author:AJ] , niezależnych konsultantów i korporacyjnych organizacji informatycznych zgromadziło jak dotąd spora doświadczenie w projektowaniu i wdrażaniu systemu NT 4 Server. Projektowanie i implementacja systemu Windows 2000 Server to całkiem inna historia. Sądząc więc według historii i złożoności produktu, trzeba będzie dość długo poczekać, zanim będziemy w stanie znaleźć większą pulę talentów dobrze zaznajomioną z systemem Windows 2000 Server i Active Directory. Jeśli taki niedobór talentów stanowi problem w firmie, może przydać się odrobina konserwatyzmu.
Jeśli firma zdecyduje się z jednego lub więcej powyższych (lub innych) powodów nadal używać NT 4 Server, trzeba zdecydowanie wziąć pod uwagę Windows 2000 Server w planach krótkoterminowych, ponieważ prędzej czy później — zapewne prędzej niż myślimy — trzeba będzie zmodernizować instalację do systemu Windows 2000 Server.
Biorąc pod uwagę potężną kampanię promocyjną Microsoftu dla Windows 2000 Server — oraz silne poparcie tego produktu ze strony społeczności niezależnych producentów oprogramowania (ISV) — z dużym prawdopodobieństwem Czytelnik będzie musiał przejść na Windows 2000 Server w roku 2002 lub najpóźniej w 2003. A taki termin jest na tyle blisko, że już trzeba brać modernizację pod uwagę w związku z wyksięgowywaniem sprzętu i oprogramowania, obsadzeniem personelem działu informatycznego i przedstawieniem długofalowych planów kierownictwu.
Krótko mówiąc, przy planowaniu projektu NT 4 Server trzeba wziąć pod uwagę modernizację do Windows 2000, ponieważ może to w przyszłości zaoszczędzić mnóstwa kłopotów przy migracji do systemu Windows 2000 Server. Bieżący rozdział koncentruje się na pomocy w dzisiejszym planowaniu instalacji NT 4 Server z widokiem na przyszłość — którą jest Windows 2000 Server.
Jeśli Czytelnik nie ma zbyt dużego doświadczenia z NT 4 Server, proszę nie tracić nadziei! W przypadku kłopotów z niektórymi pojęciami przedstawionymi w tym rozdziale proszę zajrzeć do innych publikacji zajmujących się projektowaniem systemu NT 4 --> Server, ponieważ[Author:A. J.] bieżący rozdział zakłada znajomość wszystkich podstawowych pojęć NT 4 Server. Skorzystanie z wprowadzenia do systemu NT 4 Server powinno pomóc zrozumieć wszystkie przedstawione tutaj bardziej szczegółowe zagadnienia.
Istotne rady dotyczące projektu środowiska NT 4 Server
Zaczynając projekt (lub modernizację projektu) NT 4 Server proszę pilnować, aby:
Stosować tylko TCP/IP.
Utrzymywać elegancką i uporządkowaną strukturę adresów TCP/IP.
Zaimplementować DHCP w celu przydziału adresów TCP/IP klientom.
Zmniejszyć jak najbardziej zależność od NetBIOS-u (szczególnie w przypadku instalowanych aplikacji innych producentów).
Dążyć do implementowania aplikacji uznanych za całkowicie zgodne z Windows 2000 w chwili obecnej lub — co jest niemal równie dobrym wyjściem — aplikacji, dla których istnieją już nowsze wersje certyfikowane dla Windows 2000.
Gdzie tylko można, implementować rozwiązania stosujące usługę DNS do rozwiązywania nazw.
Stosować jak najmniej domen i unikać modelu całkowitego zaufania (complete trust), gdy tylko można. Jeśli potrzebnych jest więcej domen niż jedna, należ dążyć do użycia modelu pojedynczej domeny głównej lub wielu domen głównych.
Zachować jak najprostszą strukturę grup.
Używać grup do przydziału wszelkich uprawnień, unikać przydziału jakichkolwiek uprawnień bezpośrednio użytkownikom lub komputerom, oraz wystrzegać się wbudowanych grup lokalnych domeny (Administratorzy, Użytkownicy, Operatorzy kont itp.).
Pomyśleć dwa razy przed zaimplementowaniem innych wersji językowych Windows NT 4 od angielskiej w serwerach i klientach.
W razie wątpliwości dotyczących systemu operacyjnego dla klientów wybrać Windows NT 4 Workstation.
Wybierać nowy sprzęt (dla klientów i serwerów) o parametrach przygotowanych na modernizację do Windows 2000.
Dla użytkowników Exchange Server do listy należy dodać następujące pozycje:
Dążyć do minimalizacji liczby domen Windows NT używanych przez Exchange Server.
Ograniczyć liczbę tworzonych kontenerów do absolutnego minimum.
Używać w miarę możliwości tylko Exchange 5.5 Service Pack 3.
Ograniczyć liczbę lokacji Exchange.
Jeśli zastosujemy się do tych prostych wytycznych, będziemy w o wiele lepszej sytuacji przy faktycznej migracji do systemu Windows 2000 Server. Większość wymienionych powyżej rad zostało omówionych bardziej szczegółowo w dalszej części rozdziału.
I jeszcze jedno: proszę spróbować wykonać chociaż część planowania i architektury Active Directory omówionych w tej książce przed zakończeniem projektu struktury NT 4 Server. Możemy w niej znaleźć ważną lekcję lub dwie, dotyczące tego, jak należy lub jak nie należy konstruować projektu NT 4 Server.
Nudne szczegóły TCP/IP
Należy dążyć do wdrożenia NT 4 Server za pomocą samego protokołu TCP/IP. Ułatwi to znacząco migrację do systemu Windows 2000 Server, ponieważ Active Directory korzysta tylko z sieci TCP/IP. Ponadto TCP/IP jest domyślnym wyborem w NT 4 Server, wobec czego praktycznie wszystkie implementacje systemu NT 4 Server wykonane w ostatnich latach zostały zbudowane na TCP/IP.
Aby móc używać TCP/IP, infrastruktura sieci musi być w stanie obsłużyć protokół TCP/IP. Na szczęście, w związku z niekontrolowanym sukcesem Internetu wymagania te spełnia większość istniejących sieci lokalnych i rozległych. Konsekwentnie, wymóg TCP/IP zazwyczaj jest najtrudniejszy dla urządzeń przestarzałych. Wiele nadal używanych systemów „ciężkiego kalibru” (DEC VAX i różne typy zgodnych z IBM komputerów mainframe oraz AS/400) nie jest zgodnych z TCP/IP. W takich sytuacjach zazwyczaj mamy do wyboru następujące rozwiązania:
Zacisnąć zęby i dodać obsługę TCP/IP w omawianych komputerach.
Odizolować zasoby nie używające TCP/IP w odrębnej części sieci lokalnej i postawić bramę TCP/IP do reszty sieci, lub postawić takie bramy bezpośrednio przed każdym komputerem.
Nauczyć się żyć z problemami wielo-protokołowej sieci LAN: wyższą złożonością (więcej pracy z zarządzaniem i większe ryzyko problemów), wysokim dodatkowym wykorzystaniem pasma, mniejszą zdolnością do współpracy i wyższymi wymogami od każdego klienta.
Często najłatwiejszym i najszybszym rozwiązaniem problemu jest zastosowanie kilku bram, które przekroczą przepaść pomiędzy starymi protokołami i resztą środowiska sieciowego (kilka systemów Microsoft SNA Server lub Host Integration Server może często okazać się dobrym rozwiązaniem, z wyjątkiem sytuacji bardzo nietypowych). Możemy jednak nadal napotykać problemy powodowane przez stare terminale i drukarki, oraz krytyczne dla działania firmy łącza pomiędzy przestarzałymi urządzeniami w różnych lokacjach. Lecz to już wykracza poza zakres tematyczny tego rozdziału.
Niezależnie od tego, czy mamy do czynienia z wdrożeniem całkiem nowej infrastruktury sieciowej TCP/IP czy nie, należy zawsze pamiętać o planie adresów TCP/IP. Aby uniknąć kłopotów w przyszłości, nie należy zbyt twórczo podchodzić do tego planu. Im prościej, tym lepiej, więc idealnym rozwiązaniem jest jedna podsieć (klasy A, B lub C) w każdej lokalizacji. I odwrotnie, trzeba zdecydowanie unikać schematów podziału na podsieci, w których maski podsieci będą inne od typowych (czyli 255.0.0.0, 255.255.0.0 i 255.255.255.0) w celu zaoszczędzenia adresów IP.
Krótki rzut oka na usługi DGCP, WINS i DNS
Właściwe skonfigurowanie TCP/IP w każdym komputerze w sieci może wymagać znaczących nakładów pracy administracyjnej i stworzyć mnóstwo okazji do błędów w konfiguracji. Zadaniem protokołu dynamicznej konfiguracji hosta (DHCP - Dynamic Host Configuration Protocol) jest centralizacja i zarządzanie danymi konfiguracyjnymi TCP/IP przez automatyczny przydział adresów IP i innych danych konfiguracyjnych IP do hostów IP.
Usługa DHCP jest jednym z kamieni węgielnych Active Directory, warto więc przyzwyczaić się do niej już teraz — i zebrać wymierne korzyści, które przynosi. W związku z gotowością na Windows 2000 Server, przy implementacji DHCP wystarczy zdrowy rozsądek (oraz bieżące najważniejsze wskazówki dla środowisk NT 4 Server).
--> NetBIOS jest podstawą BackOffice[Author:AJ] Jeśli zamierzamy zaimplementować któreś z aplikacji Microsoft BackOffice w środowisku Windows NT Server (na przykład, Exchange Server 5.5, SQL Server 7.0, SMS 2.0 i tak dalej) musimy wiedzieć, iż są one także zasadniczo nakierowane na NetBIOS. Na przykład, chociaż można uniknąć używania protokołu NetBIOS w podstawowej konfiguracji Exchange Server, obsługa NetBIOS-u jest potrzebna, by używać wszystkich narzędzi służących do administracji serwerem Exchange 5.5. Ponadto Exchange Server „rozmawia” z kontrolerami domen za pomocą NetBIOS-u. Nie trzeba więc szukać dalej niż pomiędzy własnymi aplikacjami Microsoftu, aby znaleźć zagrożenie kłopotami z NetBIOS-em. |
Usługa WINS (Windows Internet Naming Service) to jednak całkiem inna historia. WINS świadczy usługi rozwiązywania nazw dla hostów bazujących na protokole NetBIOS przez TCP/IP, co eliminuje rozgłoszenia NetBIOS-u. Usługa WINS jest potrzebna dla --> wszystkich [Author:AJ] systemów operacyjnych Microsoftu poprzedzających Windows 2000 Server (z powodu potrzeby rozwiązywania nazw). I chociaż usługa WINS mówiąc ściśle nie jest wymagana dla systemu Windows 2000 Server i Active Directory, prawdopodobnie będziemy musieli pozostawić ją „na chodzie” po modernizacji. Wobec tego, niezależnie od nastawienia emocjonalnego do WINS (dla osób nie zaznajomionych z tą usługą: zarządzanie WINS w dużej instalacji jest męczące; brak do tego celu dobrych narzędzi a mechanizm replikacji jest nieciekawy), usługa ta jest niezbędna sieci NT 4 Server do funkcjonowania i najprawdopodobniej do pewnego stopnia będzie potrzebna po modernizacji (może uda się uniknąć stosowania WINS przez klienty).
Jednakże z wyjątkiem wymaganego rozwiązywania nazw NetBIOS na TCP/IP dla serwerów i klientów Windows NT, powinniśmy starać się zmniejszyć użycie protokołu NetBIOS w sieci, jak tylko się da. NetBIOS powinien być uznany za rozwiązanie przestarzałe w stosunku do systemu Windows 2000 Server, dlatego też warto unikać wprowadzania dodatkowych zależności od NetBIOS-u pochodzących od innych aplikacji. Mając możliwość wyboru powinniśmy zdecydować się na DNS, ponieważ usługa DNS jest standardem rozwiązywania nazw używanym przez Windows 2000 Server. A dla aplikacji domowego wyrobu należałoby zacząć zastanawiać się nad konwersją z interfejsów API NetBIOS-u na Winsock.
Przygotowując się na Windows 2000 Server należy używać dla wszystkich klientów i serwerów Windows w sieci tylko nazw NetBIOS zgodnych ze standardem DNS. Standardowe znaki w usłudze DNS to litery od A do Z, cyfry od 0 do 9 oraz łącznik (-). Proszę też wziąć pod uwagę długość nazwy domeny, ponieważ przy migracji domeny NT 4 Server mogą bez problemów zachować swoje nazwy. Nazwy w Active Directory składają się z kilku części (np. exchserv.finance.bigwig.com), jeśli więc nie będziemy uważać, wynikowa pełna nazwa domeny może być bardzo nieporęczna i trudna do odczytania. Krótsze nazwy są łatwiejsze do zapamiętania zarówno dla użytkowników, jak administratorów.
Gdy idzie o DNS, powinniśmy przynajmniej zawrzeć strukturę domen DNS w środowisku NT 4 Server. Rozdział 7. dokładnie przedstawia procedurę implementacji struktury domen DNS, więc nie zostanie ona tu powtórzona. Trzeba jednakże wiedzieć, iż zastosowanie rozwiązywania nazw DNS na WINS może pomóc przy migracji przestarzałych rozwiązań NetBIOS. Oznacza to, że wszystkie nazwy NetBIOS mogą być równie dobrze rozwiązywane za pomocą DNS-u jak za pomocą WINS, ponieważ serwer DNS będzie odpytywać WINS w imieniu klienta, jeśli nie będzie posiadać rekordu zasobu pasującego do zapytania — i biorąc pod uwagę niewesołe widoki usługi WINS na przyszłość, zdecydowanie powinniśmy przyzwyczajać wszystkich do usługi DNS już od początku.
Wszystko ma jednak swoją cenę, która w niektórych przypadkach może być wysoka. Na przykład, rozwiązywanie nazw DNS na WINS jest własnym rozszerzeniem usługi DNS wprowadzonym przez Microsoft, więc wymaga użycia serwera DNS wbudowanego do systemu Windows NT 4 Server. Wobec tego, dysponując istniejącą strukturą domen DNS, mamy wybór pomiędzy migracją do serwera DNS Microsoftu lub oddelegowaniem strefy DNS dla infrastruktury NT 4 Server — to znaczy, jeśli chcemy skorzystać z rozwiązywania nazw DNS na WINS.
Jeśli nie dysponujemy obecnie strukturą domen DNS, powinniśmy wybrać Microsoft DNS Server: jest wbudowany w Windows NT 4 Server, rozwiązuje nazwy DNS na WINS i oczywiście doskonale pasuje do podrasowanej wersji usługi DNS zawartej w systemie Windows 2000 Server.
Klienty i serwery
Dążąc w kierunku systemu Windows 2000 Server należy zawsze wybierać Windows NT 4 Server zamiast NT 3.51 Server. Chociaż bezpośrednia modernizacja z systemu NT 3.51 Server do Windows 2000 Server jest możliwa, istnieją w przypadku takiej modernizacji pewne drobne problemy z kompatybilnością wstecz (patrz rozdział 22.), których opłaci się uniknąć.
Należy też użyć przynajmniej Service Pack 5 (a lepiej SP6a --> lub późniejszego[Author:A. J.] ) dla wszystkich serwerów NT 4 Server, ponieważ daje to najlepsze zabezpieczenie przed wszelkimi niewygodami, które mogą wystąpić podczas migracji. Chociaż wciąż jest zbyt wcześnie na przedstawienie tych niewygód, jestem pewien że wystąpią — choćby z tego powodu, iż Microsoft inwestuje --> mniej [Author:AJ] środków w zapewnienie bezproblemowej modernizacji z systemu NT 4 Server SP5 lub SP6, niż w zapewnienie takiej samej bezproblemowości dla wcześniejszych Service Pack. Wobec tego w razie kłopotów Microsoft przypuszczalnie poradzi, by zaaplikować jak najnowsze poprawki i spróbować ponownie.
O czym trzeba pamiętać przy projektowaniu architektury DNS-u Poniżej przedstawione zostały ogólne reguły projektowania dobrych rozwiązań DNS, zoptymalizowanych dla migracji do systemu Windows 2000 Server:
|
Aby maksymalnie wykorzystać liczne funkcje systemu Windows 2000 Server związane z TCO (Total Cost of Ownership - całkowite koszty posiadania), trzeba zainstalować w komputerach --> osobistych [Author:AJ] Windows 2000 Professional. Najlepszym sposobem przygotowania pod Windows 2000 Professional jest instalowanie Windows NT 4 Workstation w każdym nowym komputerze klienckim — ponieważ pozwoli to najszybciej i najbardziej bezproblemowo zaktualizować system (głównie z powodu lepszej zgodności oprogramowania, sprzętu i systemu plików z Windows 2000 Professional). Można też oczywiście rozważyć wdrożenie Windows 2000 Professional od razu, jeśli pozwoli na to sprzęt i aplikacje klienckie komputerów osobistych.
Wybór NT 4 Workstation pozwoli również organizacji obsługującej infrastrukturę nabyć na miejscu zaawansowane doświadczenie z NT, co później okaże się cenne przy zapewnieniu łatwego i szybkiego wdrożenia Windows 2000 Professional. Ponadto Microsoft twierdzi, iż użycie NT 4 Workstation zamiast Windows 98 lub ME powinno przynieść znaczące korzyści.
Oczywiście, różnica pomiędzy Windows NT 4 Workstation i Windows 98/Me nie jest tak znacząca jeśli spodziewamy się pełnej reinstalacji systemów w komputerach osobistych przy migracji do Windows 2000 Professional. Lecz nadal pozostają pewne bardzo istotne powody (i setki pomniejszych) wyboru NT 4 Workstation zamiast Windows 98 czy Me w instalacji firmy — i tylko kilka powodów dla decyzji przeciwnej.
Wybór właściwego sprzętu już na początku
Wybór sprzętu jest zagadnieniem chyba równie ważnym jak wybór systemu operacyjnego. Należy tu starać się uniknąć wszelkiego skąpienia na parametrach składników sprzętu używanego na klienty i serwery. Windows 2000 Professional i Windows 2000 Server nakładają na komputery jeszcze wyższe wymagania niż dotąd. Proszę więc wziąć pod uwagę to dodatkowe obciążenie dla wszelkiego kupowanego dziś sprzętu, ponieważ najprawdopodobniej będzie on nadal w użytku w chwili implementacji Windows 2000, niezależnie od stosowanego planu amortyzacji.
Powody by unikać Windows 95 i 98 Powód, dla którego nie warto implementować klientów Windows 95 i 98 (jak też Windows Millenium Edition), jeśli mamy możliwość wyboru, jest bardzo prosty: modernizacja Windows 95 lub Windows 98 może wymagać w dużym zakresie specjalnego traktowania. Windows 95 i 98 to w istocie typ technologii całkiem odmiennej od Windows NT 4 Workstation. Gdyby zagłębić się w ten temat, znajdziemy wiele subtelnych różnic architektury (najgorszą różnicą z punktu widzenia migracji są chyba odmienne struktury Rejestru), które razem mają negatywny wpływ na migrację aplikacji. Przy migracji z platform Windows 95 i 98 do dokonania przejścia będzie potrzebna pomoc sprzedawcy aplikacji. Do tego celu Microsoft namawia do stosowania techniki migracyjnych plików DLL (migration DLL), które pozwalają aplikacjom rozpoznać używany system operacyjny i stosownie do tego dokonać własnej aktualizacji. Migracyjne biblioteki DLL wywoływane są przez aplikację aby sprawdzić, czy wszystkie odpowiednie składniki aplikacji dla danego systemu operacyjnego są zainstalowane. Jeśli nie, wywoływany jest program instalacyjny aplikacji i załadowane zostają odpowiednie składniki. Chociaż więc Microsoft wspiera proces modernizacji z Windows 95 i 9 do Windows 2000 Professional i współpracuje z producentami aplikacji aby zachęcić ich do pracy nad migracyjnymi bibliotekami DLL, najprawdopodobniej przy modernizacji --> w miejsce[Author:A. J.] z Windows 95 lub 98 napotkamy więcej trudności niż w przypadku NT 4 Workstation. |
Jeśli chcemy uniknąć dużych wydatków czasu i pieniędzy na modernizację sprzętu w późniejszym terminie (oraz czasu potrzebnego na ich wykonanie), należy dziś wyposażyć komputer w dużą ilość pamięci i mocy obliczeniowej procesora (proszę przejrzeć wytyczne z rozdziału 2., pamiętając by w wymaganiach sprzętowych wziąć poprawkę na potrzeby aplikacji i dodatkowe miejsce na rozwój).
Przy zakupie sprzętu proszę pamiętać, że Windows 2000 w pełni obsługuje Plug and Play, Advanced Configuration i Power Interface (ACPI) oraz wiele innych nowych technologii. Po stronie serwera proszę szczególnie zwrócić uwagę na obsługę urządzeń PCI, kontrolerów macierzy i dysków instalowanych bez przerywania pracy komputera, jak również znacznie ulepszoną obsługę klastrów.
Uwaga na wersje językowe
Proszę długo i uważnie przyjrzeć się opcjom dostępnym przy wyborze wersji językowej Windows NT 4 (a szczególnie Windows NT 4 Server), ponieważ wybór języka może potencjalnie stanowić problem przy modernizacji do Windows 2000. Powód tych potencjalnych problemów jest bardzo prosty: zasadniczo nie można zmodernizować systemu do żadnej innej wersji językowej Windows 2000 niż używana przez NT 4.
Wskazówka
Istnieje nie udokumentowany i nie obsługiwany wyjątek dla modernizacji z lokalnej wersji językowej Windows NT Workstation do angielskiej wersji Windows 2000 Professional. --> Wyjątek ten jest opisany[Author:AJ] w książce Windows 2000 Professional: Advanced Configuration and Implementation, również wydawnictwa The Coriolis Group.
Nawet jeśli jesteśmy bardzo zadowoleni z bieżącej wersji językowej NT 4, w końcu możemy stwierdzić, iż wersja ta jest rozwiązaniem raczej poślednim w wielonarodowościowej instalacji Windows 2000. Microsoft wprowadził nową wersję Windows 2000 z wielojęzycznym interfejs użytkownika (MUI - Multilingual User Interface), noszącą nazwę Windows 2000 MultiLanguage Version i przeznaczoną dla scenariuszy instalacji na skalę globalną. Wersja ta pozwala użytkownikom na dostęp do informacji w preferowanym języku. W edycji MUI można lokalizować wszystko z wyjątkiem następujących pozycji (które pozostają w języku angielskim):
Wszystkie 16-bitowe składniki systemu operacyjnego.
Grafiki rastrowe.
Wszystkie klucze i wartości Rejestru.
Nazwy folderów i plików (łącznie z nazwami folderów i łączy w menu Start).
Lokalizacja odbywa się przez zaimplementowanie jednego lub kilku z dostępnych 24 pakietów językowych. Jeśli musimy zaimplementować wiele takich opcji językowych, proszę zwrócić uwagę, iż każda zajmuje sporo dodatkowego miejsca na dysku twardym: każdy język wymaga ok. 25 MB na interfejs użytkownika i od 1 MB do 20 MB na obsługę danych na dysku używanym przez system operacyjny. Wobec tego mogą okazać się potrzebne duże dyski twarde oferowane w nowych komputerach osobistych.
Wersja MUI stanowi dobry wybór zawsze, z wyjątkiem sytuacji gdy użytkownicy całkowicie nie rozumieją języka angielskiego. Ponadto wersja MUI jest bardzo atrakcyjną ofertą dla działu informatycznego, ponieważ obiecuje wyeliminować wiele komplikacji z instalowaniem wielu różnych --> wersji [Author:A. J.] tego samego systemu operacyjnego, co ułatwia wdrożenie, zapewnia równorzędność wszystkich języków, mniejsze obciążenie obsługi technicznej i łatwiejsze instalowanie Service Pack i innych aktualizacji.
Jednakże przejście na wersję MUI jest możliwe tylko z amerykańskiej angielskiej wersji językowej (U.S./English) Windows NT 4 Workstation, dlatego też należy unikać wdrażania w firmie wszelkich innych wersji językowych Windows NT Workstation. Tak, wiem że to może być trudnym zadaniem, biorąc pod uwagę różnice w znajomości języka angielskiego pomiędzy użytkownikami końcowymi na całym świecie.
Dlatego z powyższych powodów, jeśli wybierzemy instalację innej wersji językowej Windows NT 4 Workstation niż U.S./English, jedynym sposobem zaimplementowania edycji MUI przy przejściu do Windows 2000 Professional będzie pełna reinstalacja wszystkich klientów. Planowanie tego z góry nie wydaje się zbyt prawdopodobne w bardziej zdecentralizowanych typach organizacji, o ile nie uzyskamy zgody zarówno użytkowników jak kierownictwa na długo przed rozpoczęciem rozmieszczania systemów NT 4.
Zanim jednak zaczniemy nalegać na wybór Windows NT 4 Workstation w wersji U.S./English — co może być bardzo niepopularne pośród użytkowników nie używających języka angielskiego (amerykańskiego) — aby zapewnić możliwość przejścia później na wersję MUI, proszę wziąć pod uwagę, iż każda lokalna wersja językowa Windows 2000 Professional o wiele lepiej radzi sobie z wieloma różnymi językami i preferencjami istniejącymi na świecie, niż wersje Windows NT 4 Workstation. Ponieważ Windows 2000 używa jednego ogólnoświatowego kodu binarnego dla podstawowych plików wykonywalnych (bazującego na Unicode 2.0), można tworzyć scenariusze takie, jak wielojęzyczne środowiska użytkowników, wielojęzyczne sieci i wielojęzyczne dokumenty, niezależnie od wybranej wersji językowej.
Jednakże nadal pozostaną obecne problemy z --> udostępnianiem [Author:AJ] danych, obsługą użytkowników mobilnych i podstawową łącznością, jeśli wymieszamy różne wersje językowe Windows 2000 (nie wspominając o obsłudze przyprawiającej o bóle głowy). Jeśli więc nie możemy pozbyć się wersji językowych Windows NT 4 Workstation innych niż U.S./English, może się okazać, iż nasza firma jest źle przygotowana do pełnego skorzystania z opcji dostępnych dla środowisk globalnych.
Wskazówka
Wybierając system operacyjny i aplikacje trzeba wziąć pod uwagę wszelkie nałożone ograniczenia językowe. Dlatego należy dążyć do korzystania z aplikacji przygotowanych pod nowy wielojęzyczny API (MLAPI - Multilingual API), który pozwoli aplikacjom obsługiwać dane wprowadzane z klawiatury i czcionki z różnych wersji językowych, a przez to umożliwi użytkownikom uruchamianie aplikacji w preferowanym języku. Na przykład, japoński użytkownik będzie w stanie usiąść przy dowolnym komputerze osobistym bazującym na Windows 2000 Professional i przełączyć zgodny z MLAPI edytor tekstu na znaki --> alfabetu [Author:AJ] japońskiego, niezależnie od lokalnej wersji językowej zaimplementowanej w komputerze, pod warunkiem że obsługa odpowiedniego języka została uprzednio zainstalowana.
Wybór modelu domeny
Poniżej przedstawione zostały cztery modele domen Windows NT 4 Server, zdefiniowane przez Microsoft:
Pojedyncza domena (Single domain) — najlepszy model dla firm o małych i średnich rozmiarach.
Pojedyncza domena główna (Single-master domain) — najlepszy wybór dla firm, które nie mają zbyt wielu użytkowników w porównaniu z ilością sprzętu, posiadają centralny dział informatyczny i muszą dzielić udostępnione zasoby na grupy w celu zarządzania.
Wiele domen głównych (Multi-master domain) — często jedyny rozsądny wybór dla dużych firm z wieloma użytkownikami i stosunkowo scentralizowaną obsługą informatyczną (czyli firm z jednym lub niewielką liczbą centrów kierowania).
Całkowite zaufanie (Complete trust) — zazwyczaj brany pod uwagę jedynie przez firmy nie posiadające centralnego działu informatycznego. Powinien być implementowany tylko tam, gdzie nie pasuje żaden z poprzednich trzech modeli, ponieważ potencjalne ryzyko powodowane przez użytkowników z innych domen, mających dostęp do zasobów, wymaga wysokiego poziomu zaufania do wszystkich pozostałych administratorów.
Każdy z tych modeli domen posiada różne zalety i wady z których trzeba zdawać sobie sprawę, dlatego też prawie wszystkie ważne książki o Windows NT 4 Server omawiają te modele szczegółowo. Taka szczegółowa analiza nie mieści się w tematyce tej książki, więc wady i zalety każdego modelu zostały podsumowane w tabeli 21.1.
Tabela 21.2
Każdy z czterech dostępnych modeli domen ma swoje wady i zalety
Model domeny |
Główne zalety |
Główne wady |
Pojedyncza domena |
Centralne zarządzanie użytkownikami i zasobami. |
Możliwość przeciążenia PDC. |
|
Nie są wymagane relacje zaufania. |
Niemożliwość podziału użytkowników i zasobów według wydziałów. |
|
Prostsze definicje grup. |
Ograniczenie maksymalnej liczby użytkowników. |
|
|
Przy licznych serwerach możliwe wolne przeglądanie. |
Pojedyncza domena główna |
Centralne zarządzanie zabezpieczeniami. |
Wszelkie czynności związane z logowaniem zachodzą w jednej domenie, co może powodować problemy z wydajnością. |
|
Zasoby są zgromadzone logicznie w domenach zasobów. |
W każdej domenie zasobów trzeba definiować grupy lokalne. |
|
Przeglądanie jest rozłożone na domeny wydziałów. |
Lokalni administratorzy są zależni od zarządzania domeną główną przy grupowaniu użytkowników. |
|
Grupy globalne w domenie głównej pozwalają wydziałom łatwo ustawiać lokalne uprawnienia. |
|
Wiele domen głównych |
Model skalowalny do dowolnych rozmiarów organizacji. |
Liczba grup lokalnych i globalnych oraz relacji zaufania mnoży się gwałtownie ze wzrostem liczby domen. |
|
Centralne zabezpieczenia. |
Konta użytkowników i grupy nie mieszczą się w pojedynczej domenie. |
|
Wydziały mogą zarządzać zasobami we własnych domenach. |
|
|
Użytkownicy, grupy i zasoby powiązane ze sobą mogą być grupowane logicznie. |
|
Całkowite zaufanie |
Model skalowalny do dowolnych rozmiarów organizacji. |
Brak centralnego zarządzania zabezpieczeniami i wszyscy uczestnicy w wyniku rezygnują z kontroli ufając wszystkim. |
|
Nie jest wymagany centralny wydział zarządzający systemami informacyjnymi. |
Wymagane liczne relacje zaufania. |
|
Wydziały zachowują kontrolę nad własnymi użytkownikami i zasobami. |
Wydziały są zależne od praktyk zarządzania stosowanych w innych wydziałach. |
|
Logiczne grupowanie użytkowników i zasobów według wydziałów. |
|
Zasadniczo dobre, dobrze zrozumiałe powody dodawania domen to:
Przyczyny organizacyjne.
Poprawa wydajności sieci.
Jednakże nadejście systemu Windows 2000 Server z Active Directory dodaje nową zmienną do równania — łatwość przejścia na Windows 2000 Server. Ostateczny wpływ tej zmiennej jest naprawdę prosty: należy używać możliwie jak najmniej domen.
Chociaż więc migracja do systemu Windows 2000 Server jest możliwa niezależnie od wybranego modelu domen, należy najpierw przyjrzeć się uważnie potrzebom firmy aby ustalić, czy możemy użyć modelu pojedynczej domeny. Jeśli nie spełnia on potrzeb firmy, należy zawsze optować za modelem pojedynczej domeny głównej, ponieważ jest to drugi optymalny wybór z trzech pozostałych pod kątem migracji do systemu Windows 2000 Server.
Istotne doświadczenia dotyczące grup i użytkowników
Migrację z Windows NT 4 Server do Windows 2000 Server można ogromnie uprościć, jeśli będziemy w stanie dokonać prostej modernizacji obejmującej wszystkich wystawców zabezpieczeń (grupy i użytkowników). Jeśli możemy tak zrobić, nie trzeba będzie implementować żadnych zmian w podstawowej konfiguracji i uprawnieniach zabezpieczeń użytkowników przy migracji zmian SID. Jednakże taka migracja zawiera również dziedziczenie wszystkich niewłaściwych ustawień zabezpieczeń, przez co nie pozwala podczas migracji wyczyścić wszelkich niestosowności w zabezpieczeniach. Konsekwentnie, warto jeszcze bardziej niż zwykle uważać na konfigurację uprawnień w środowisku NT 4 Server. Chcąc dobrze zaprojektować strukturę zabezpieczeń w NT 4 Server należy trzymać się tych pięciu wskazówek:
Jak najprostsza struktura grup — proszę nie przeciążać każdej grupy przez kilka semantyk.
Z dala od wbudowanych grup lokalnych domeny — chociaż sprawują się dobrze w Windows NT, nie da się ich łatwo migrować do Active Directory.
Używać grup do przydziału wszelkich uprawnień — nie należy nigdy stosować przydziału uprawnień bezpośrednio do kont użytkowników.
Poświęcić więcej czasu niż zwykle na konfigurację uprawnień do systemu (systemów) plików.
Przygotować się na wymogi Active Directory dotyczące unikatowych nazw użytkowników — w systemie Windows NT 4 Server nazwy użytkowników musiały być unikatowe jedynie w obrębie każdej domeny NT 4 Server. Aby więc ułatwić przejście do Active Directory, należy w NT 4 Server zastosować schemat nazewniczy, zapewniający unikatowość nazw w skali wszystkich zaimplementowanych domen. Dla grup lokalnych o tej samej semantyce w każdej domenie należy używać takich samych nazw. I zależnie od przyszłości grup globalnych w Active Directory trzeba próbować przygotować się albo na połączenie identycznych grup globalnych w grupę uniwersalną o zasięgu całego lasu (wybierając z góry opisową nazwę), albo na przekształcenie grup globalnych w uniwersalne (zapewniając unikalność nazw grup globalnych na skalę lasu).
Podejście od strony serwera Exchange
Przygotowując projekt proszę nie zaniedbywać aplikacji serwerowych i klienckich, ponieważ mogą stanowić najtrudniejsze z wyzwań projektowych. Na przykład trzeba wziąć pod uwagę:
Czy stare aplikacje klienckie nie będą niezgodne z Windows 2000 Professional.
Czy nowsze aplikacje klienckie Windows nie będą niezgodne z mobilnością użytkowników Windows 2000 Server, udoskonalonymi funkcjami zabezpieczeń i bardziej rygorystycznym traktowaniem bibliotek DLL.
Czy trzeba będzie opracować nowe pliki skryptów służących do przydziału i publikowania aplikacji za pomocą Zasad grup (jeśli aplikacje nie są zgodne z Instalatorem systemu Windows).
Dodatkowo w najczarniejszym scenariuszu możemy dysponować aplikacjami serwerowymi, grożącymi pewnym poziomem niezgodności z systemem Windows 2000 Server. Należy też próbować ustalić, jak producent każdej aplikacji serwerowej przewiduje integrację z Active Directory, ponieważ możemy być w stanie ominąć poważne zagrożenia migracji, --> zmieniając dobór[Author:AJ] aplikacji przed zaimplementowaniem w Windows NT 4 Server.
Bieżący podrozdział przedstawia mniej teoretyczny przykład — Exchange Server 5.5 — jednego z zagrożeń integracji aplikacji serwerowych z Active Directory, oraz kilka porad, jak radzić sobie z tą integracją. Exchange Server 5.5 został wybrany do roli przykładu, ponieważ wiele organizacji stosuje go do obsługi swoich potrzeb przesyłania wiadomości przy implementacji systemu Windows NT 4 Server. Przykład ten przedstawia logikę, jakiej należy użyć przy instalacji Exchange Server 5.5 przeznaczonej do migracji w późniejszym terminie do Windows 2000 Server (nie można użyć nowszej wersji Exchange 2000 Server, ponieważ jest zależna od Active Directory).
Wobec tego najbardziej prawdopodobny scenariusz migracji dla Exchange Server jest taki:
Implementacja Windows 2000 Server
Integracja Active Directory i katalogu Exchange za pomocą narzędzia Active Directory Connector (ADC), dostępnego w pakiecie Windows 2000 Server oraz — w ulepszonej wersji — w pakiecie Exchange 2000 Server. ADC implementuje bazującą na LDAP dwukierunkową replikację pomiędzy Active Directory i Exchange Server 5.5 Service Pack 3 (koniecznie w tej wersji Exchange, ponieważ jedynie ona obsługuje --> zapisy i stronicowane wyniki)[Author:A. J.] .
Migracja z istniejącego środowiska Exchange Server do Exchange 2000 Server.
Pierwszym celem jest zastosowanie jak najmniejszej liczby lokacji Exchange, z powodu wyzwań które niesie implementacja ADC. Każda lokacja (site) Exchange musi być odwzorowana na Active Directory przez zdefiniowanie połączenia ADC. Jeśli więc utworzymy stosunkowo małą liczbę lokacji, wkład pracy w tworzenie i utrzymywanie łączy ADC będzie mniejszy, zaś obciążenie serwerów zostanie zredukowane (każde łącze ADC dodaje pewne obciążenie).
Druga rada mówi, by usiłować ograniczyć liczbę tworzonych kontenerów — a najlepiej wykorzystać tylko wstępnie zdefiniowane kontenery Exchange — ponieważ może okazać się potrzebne tworzenie połączenia ADC dla każdego kontenera przeznaczonego do replikacji, zależnie od dokładnych potrzeb replikacji. Ponadto mogą być kłopoty, gdy spróbujemy replikować dwa kontenery do tej samej OU Active Directory, a zarazem będzie trzeba replikować jakiekolwiek zmiany z Active Directory do odpowiedniego kontenera Exchange; jest to po prostu niemożliwe, ponieważ Active Directory nie jest w stanie ustalić, w którym z kontenerów Exchange należy umieścić utworzony właśnie obiekt. Ponadto należy dążyć do implementacji jedynie Exchange Server 5.5 z Service Pack 3, ponieważ wymaga tego ADC systemu Windows 2000 Server.
Jeśli z jakiegoś powodu będą trudności z wdrożeniem „czystej” instalacji Exchange Server 5.5, należy starać się umieścić przynajmniej jeden Exchange 5.5 Server w każdej lokacji, aby móc zaimplementować ADC i ułatwić migrację do Exchange 2000 Server.
Uwaga
Proszę nie martwić się niemożliwością implementacji Exchange Server 5.5 w każdej lokacji. Dozwolona jest replikacja za pomocą ADC pomiędzy Active Directory i serwerem Exchange 5.5 z innej lokacji. Proszę jednak pamiętać, iż nieobecność systemu Exchange Server 5.5 w przynajmniej jednej lokacji ograniczy elastyczność migracji i należy tego w miarę możliwości unikać.
Na koniec należy przemyśleć, jak odwzorować obiekty pomiędzy Active Directory i katalogiem Exchange, ponieważ zdecydowanie warto zapewnić połączenie obiektów o podobnej semantyce. Połączenie to jest jednak możliwe tylko jeśli posiadamy jakiś unikatowy identyfikator wspólny dla obiektów w każdym z katalogów. Zazwyczaj takim unikatowym identyfikatorem jest SID (Windows 2000 zawiera konta użytkowników z numerami SID, zaś skrzynki pocztowe Exchange zwykle kojarzone są z kontami użytkowników). Lecz jeśli zdecydujemy się przenieść część kont użytkowników do nowych domen, lub utworzyć nowe konta użytkowników dla każdego użytkownika, zapewnienie poprawnego odwzorowania może być trudne.
Najważniejsze wskazówki
Jeszcze jedna rada — proszę zaplanować przestrzeń nazw Active Directory jak najwcześniej. Proszę pamiętać o tej radzie, bo może być najważniejsza z wszystkich! Projektowanie implementacji NT 4 Server z myślą o przestrzeni nazw Active Directory stanowi najlepsze możliwe zabezpieczenie przed wdrożeniem czegoś, czego później będziemy żałować, zaczynając faktyczną migrację do systemu Windows 2000 Server z Active Directory.
W idealnych warunkach Czytelnik podczas planowania struktury Windows NT 4 Server będzie w stanie zgromadzić i zaplanować większość pozycji omówionych w rozdziałach 6. do 12. W praktyce, mimo świadomości korzyści z dążenia do tego celu, w zasadnie powinny wystarczyć zadania wymienione w tabeli 21.2, ponieważ to one zwykle mają największy wpływ na przyszły projekt Active Directory. Inaczej mówiąc, zagadnienia te zwykle są najważniejszymi czynnikami wpływającymi na struktury domen, lokacji i OU Active Directory (które należy porównać ze strukturą domen DNS i domen projektu Windows NT 4 Server), oraz struktury grup.
Tabela 21.2
Najważniejsze zagadnienia projektu NT 4 Server
Zadanie |
Co trzeba wziąć pod uwagę |
Porządki w TCP/IP. |
TCP/IP górą! Lecz proszę uniknąć potencjalnych pułapek, implementując TCP/IP według „najważniejszych wskazówek”. |
Zmniejszenie wykorzystania NetBIOS-u. |
NetBIOS jest protokołem przestarzałym. Należy więc zawsze używać nazw NetBIOS zgodnych ze standardem DNS i dążyć do jak najmniejszego wykorzystania NetBIOS-u przez aplikacje i użytkowników. |
Wdrożenie usługi DNS już teraz. |
W idealnej sytuacji powinniśmy być w stanie zaimplementować strukturę DNS w platformie NT 4 Server, ponieważ ułatwi to migrację do DDNS-u w systemie Windows 2000 Server. Dla aplikacji potrzebujących rozwiązywania nazw należy zawsze preferować DNS zamiast NetBIOS-u. |
Ograniczenie liczby domen NT 4 Server. |
Im mniej domen, tym łatwiejsza migracja. |
Zachowanie prostoty struktury grup |
Należy używać grup do przydzielania wszelkich uprawnień zabezpieczeń i unikać przeciążania każdej z grup. Jeśli to możliwe, nie należy stosować grup lokalnych domeny. |
Wybór najnowszych wersji systemu operacyjnego i Service Pack. |
Należy wybrać NT 4 Server i NT 4 Workstation zamiast wszelkich innych alternatyw i zaktualizować systemy operacyjne do najwyższego możliwego poziomu (obecnie Service Pack --> 6a[Author:AJ] ). Jeśli można, należy unikać innych wersji językowych Windows NT 4 Workstation niż U.S./English, ponieważ wybór innych wersji ogranicza wybór możliwości przy modernizacji do Windows 2000 Professional. |
Uwaga na parametry sprzętu. |
Windows 2000 obsługuje mnóstwo nowych urządzeń i nakłada jeszcze wyższe wymagania na sprzęt niż poprzednie wersje systemów operacyjnych. |
Uwaga na przyszłość używanych aplikacji. |
Zawsze należy dążyć do jak największej prostoty, aby zmniejszyć kłopoty z migracją i dokonać szczegółowej analizy opcji modernizacji dostępnych dla każdej aplikacji, aby uniknąć ślepych zaułków (np. oprogramowania niezgodnego z Windows 2000 i niemożliwego do aktualizacji po przejściu na Windows 2000). W przypadku korzystania z Exchange Server 4 lub 5 proszę przeczytać bardziej szczegółowe rady zawarte w tym rozdziale; warto też wrócić do rozdziału 15. po pełne omówienie projektowania dla systemu Exchange 2000 Server. |
Zacząć już teraz projektować przyszłą infrastrukturę Windows 2000 Server. |
Rozsądnie jest mieć punkt odniesienia (czyli podstawowy projekt Windows 2000 i Active Directory) podczas projektowania struktur Windows NT 4 Server. |
Ostatnia porada
Microsoft bez wątpienia wspomoże migrację z projektu bazującego na Windows NT 4 Server do Windows 2000 Server, ponieważ leży to w jego interesie — ponadto Microsoft zdaje sobie sprawę, iż to właśnie problemy z przestarzałymi rozwiązaniami dręczyły od lat niemal wszystkich konkurentów firmy. Proszę nie koncentrować całej uwagi na produktach Microsoftu. W ramach procesu planowania systemu Windows NT 4 Server organizacja powinna zidentyfikować aplikacje, które trzeba będzie stosować w przyszłym środowisku Windows 2000 Server. Natychmiast po zidentyfikowaniu tych aplikacji organizacja powinna zacząć porozumiewać się z dostawcami aplikacji, aby poznać ich plany rozwojowe dla Windows 2000 i Active Directory, oraz aby pomóc uniknąć wszelkich niespodzianek. To samo dotyczy wszelkiego posiadanego specjalistycznego sprzętu, który powinien pozostać w eksploatacji po wdrożeniu Windows 2000 w organizacji.
Na koniec proszę zaakceptować fakt, iż migracja niektórych projektów do Windows 2000 jest łatwiejsza niż reszty. Bieżący rozdział miał za zadanie wskazać ważne cechy rozwiązań Windows NT 4 Server, które zasadniczo powinny być dość łatwe do migracji. Większość tych zaleceń bazuje na doświadczeniach klientów Rapid Deployment Program (obecnie przechrzczonego na Joint Development Program) Microsoftu, a część zaleceń z własnych doświadczeń autora.
W następnym rozdziale poznamy najważniejsze informacje, jak radzić sobie z faktyczną migracją do systemu Windows 2000 Server i Active Directory — niezależnie od tego, czy wychodzi z idealnego projektu Windows NT 4 Server, czy nie.
15 Dokument1
Nie wiem jak to jest u nas... Też powinny być dostępne takie usługi?
Jest takie zwierzę?
Wyciąłem odnośniki do publikacji - może uzupełnić dostępnymi u nas?
W oryginale trudna do oddania gra słów.
DOS 1.0 też?
Jeszcze nie ma i nie będzie.
Nie ponimaju. Może więcej?
Lepiej niż „stacjonarnych” w tym kontekście
in-place
Zostawić?
„smaków”
lub: wspólnym użytkowaniem
Czy kanji i kana noszą nazwę „alfabetu”? Nie wiem.
Można zrozumieć na 2 sposoby (lub: grzebiąc w aplikacjach)
Nie znam.
I taki już chyba zostanie.