Zarządzanie środowiskiem operacyjnym użytkownika

Od pojawienia się systemu Windows 95 i NT 4, standardowy interfejs użytkownika systemu Windows został określony przez wygląd i funkcjonowanie powłoki Eksploratora (Explorer shell). Żadna z innych powłok (shell) nie osiągnęła większej popularności, przynajmniej w firmach amerykańskich.

Zarówno wygląd, jak i działanie powłoki Eksploratora (Explorer shell) jest zdefiniowane przez gałęzie Rejestru (Registry hive), NTUSER.DAT, zestaw folderów i plików nazywanych profilem użytkownika (User profile). Tajemnica zarządzania wielką liczbą użytkowników polega na znajdowaniu sposobów na zarządzanie profilami użytkowników, znajdującymi się w ich komputerach.

Na pierwszy rzut oka wygląda, jakby nie nastąpiły większe zmiany w powłoce Eksploratora (Explorer Shell) systemu Windows 2000. Ikony są trochę barwniejsze i pojawiły się nowe pozycje menu, ale w większej części składniki starej wersji pulpitu przetrwały. Niekoniecznie jest to coś złego. Przyzwyczajenie się do środowiska zajmuje użytkownikom dużo czasu. Zmiany wprowadzane są powoli. Nawet niektóre interfejsy użytkownika w systemie Linux zaczynają naśladować powłokę Eksploratora (Explorer shell), by ułatwić użytkownikom posługiwanie się nimi.

Nie należy sądzić, że w systemie Windows 2000 nie dokonano w szerokim zakresie odnowienia wnętrza Eksploratora. Wiele składników uległo gruntownej zmianie, zwłaszcza w zakresie profili użytkowników i ich obsługi.

Oprócz założeń grupowych (group policies) w niniejszym rozdziale opisano następujące aspekty zarządzania środowiskiem użytkownika:

• Zarządzanie profilami użytkowników. W tej części rozdziału opisano konfigurowanie i kontrolę nad plikami, folderami i pozycjami Rejestru, rządzącymi powłoką Eksploratora (Eksplorer Shell).

• Zarządzanie katalogami domowymi (home directories). Profil użytkownika w systemie Windows 2000 zawiera specjalny folder na dane użytkownika, ale nic nie jest tak wygodne jak dobry, staroświecki katalog domowy.

• Założenia grupowe (group policies). Stanowią nową cechę zarządzania komputerem w systemie Windows 2000. Założenia te przeszły długą drogę od pozycji Rejestru w systemie Windows 95 i NT 4. Założenia grupowe w systemie Windows 2000 są konfigurowalne i mają kilka zupełnie nowych cech. Ten fragment rozdziału podaje podstawowe informacje na temat założeń grupowych (jest ich kilka), a następnie prowadzi poprzez kolejne kroki konfiguracji, zarządzania i wykrywania usterek w kilku przykładowych założeniach.

• Skrypty logowania. Czasy łączenia plików wsadowych (batch files) i skryptów mogą ostatecznie przeminąć. W tym podrozdziale opisano zarządzanie skryptami rozproszonymi (distributed script management) w systemie Windows 2000 i nowe opcje skryptów.

• Przekierowywanie folderów (folder redirection). Próby przekonywania użytkowników do trzymania plików na serwerze, gdzie mogą być archiwizowane i chronione, są niekończącymi się zmaganiami. Nowe podejście do tego problemu stanowi przekierowywanie folderów (folder redirection), które wykorzystuje zalety jednolitej lokalizacji plików aplikacji systemu Windows 2000. W tej części rozdziału opisano mechanizm przekierowywania folderów i kilka zagadnień, na które trzeba zwrócić uwagę.

• Obsługa aplikacji DOS-a i WIN16. Stare aplikacje nie umierają nigdy ani nie zanikają szybko. Fakt, że w komputerze zainstalowano nowiutki system operacyjny wcale nie oznacza, że aplikacje również są nowe. W tej części rozdziału omówiono obsługę w systemie Windows 2000 aplikacji dla starszych wersji systemu, a następnie opisano dokładnie dwie konsole poleceń wyjaśniając działanie dostępnych narzędzi do zarządzania konfiguracją standardową.

IntelliMirror

Po przeczytaniu literatury marketingowej dotyczącej systemu Windows 2000, można zastanawiać się, dlaczego na powyższej liście podrozdziałów nie ma narzędzia IntelliMirror. Określenie IntelliMirror, nadane przez firmę Microsoft, odnosi się do zestawu funkcji ułatwiających zarządzanie użytkownikami, podobnie jak Zero Administration Kit w przypadku Windows NT, ale narzędzie to jest całkowicie zintegrowane z systemem operacyjnym.

IntelliMirror jest tylko nazwą zestawu funkcji, które pociągają za sobą automatyczne przesyłanie danych pomiędzy komputerami-klientami a serwerami: foldery offline, przekierowywanie folderów, dystrybucja oprogramowania, zasady systemowe dotyczące grup (group policies) i usługi zdalnej instalacji. Żadna z usług IntelliMirror nie musi być ładowana ani konfigurowana. W Panelu sterowania (Control Panel) nie ma ikony IntelliMirror. Żadna z funkcji IntelliMirror nie jest konfigurowana przez Kreatora IntelliMirror. To są powody, dla których IntelliMirror nie znajduje się na liście podrozdziałów. Wydaje się, że określenie IntelliMirror zaniknie wraz osiągnięciem dojrzałości przez system Windows 2000.

Konfigurowanie i zarządzanie profilami użytkowników

System Windows 2000, tak jak wszystkie wersje systemu Windows wykorzystujące Eksploratora, ma przestrzeń nazw powłoki (shell namespace), która określa, w jakiej postaci foldery systemowe są prezentowane użytkownikom. Przestrzeń nazw przedstawia hierarchię systemu plików, upraszczając pracę projektanta aplikacji. Uruchamiając Eksploratora i przechodząc do najwyższej części drzewa katalogu w lewej części okna, widać hierarchię przestrzeni nazw powłoki (shell namespace). Pulpit jest umieszczony w części głównej, a gałęzie Moje dokumenty (My Documents), Mój komputer (My Computer), Moje miejsca sieciowe (My Network Places), Kosz (Recycle Bin) i Internet Eksplorer znajdują się zaraz pod nim.

Przestrzeń nazw Eksploratora jest zorganizowana wokół zbioru folderów i plików, które wspólnie noszą nazwę profilu użytkownika (user profile). W niniejszym podrozdziale omówiono budowę profilu użytkownika i zarządzanie nim.

Budowa profilu

Profil użytkownika systemu Windows 2000 zawiera takie składniki klasycznego profilu Eksploratora, jak Pulpit (Desktop), Menu startowe (Start Menu), znaczniki kontekstu klienta tzw. „ciasteczka” (Cookies) i różne otoczenia (Hoods), razem z kilkoma nowymi składnikami wykorzystywanymi do przechowywania danych aplikacji i założeń grupowych (group policies). Kompletną listę folderów specjalnych profilu użytkownika można znaleźć w Platform SDK lub w bazie wiedzy Microsoft KnowledgeBase pod hasłem CSIDL Values. Poniżej przedstawiono listę folderów omówionych w niniejszym rozdziale.

• Dane aplikacji (Application Data). Folder ten zawiera pliki konfiguracyjne, właściwe dla danego użytkownika, aplikacji, które mogą wędrować razem z użytkownikiem. Na przykład w tym folderze są zapisane certyfikaty szyfrowania i pliki identyfikacyjne Szyfrowania systemu plików (Encrypting File System).

• Ustawienia lokalne (Local Settings). Folder ten zawiera pliki konfiguracyjne dla aplikacji stacjonarnych, właściwe dla danego użytkownika. Na przykład ustawienia internetowe są przchowywane w tym folderze.

• Moje dokumenty (My Documents). Jest to nowa lokalizacja klasycznego foldera. W systemie Windows NT 4 folder Moje dokumenty (My Documents) znajduje się poza profilem użytkownika i jest umieszczony zaraz pod katalogiem głównym woluminu systemowego. W systemie Windows 2000 folder Moje dokumenty (My Documents) umieszczony jest w profilu użytkownika, więc może być włączony do usługi Przekierowania folderu (Folder Redirection) i profilu wędrującego (roaming profiles).

• NTUSER.DAT. Jest to gałąź użytkownika w Rejestrze i jest ładowana do Rejestru, kiedy użytkownik zaloguje się, stając się poddrzewem HKEY_Current_User.

• USRCLASS.DAT. Jest to dodatkowa gałąź użytkownika w Rejestrze zapisana w folderze \Dokumenty i ustawienia\<nazwa_użytkownika>\Ustawienia lokalne\Dane Aplikacji\Microsoft\Windows (\Documents and Setings\<username>\Local Settings\Application Data\Microsoft\Windows). Przechowuje pozycje użytkownika w Rejestrze dotyczące aplikacji stacjonarnych.

• NTUSER.INI. Jest to nowy plik w systemie Windows 2000. Umieszczone w nim są ustawienia INI dla usług terminalowych (Terminal Services), pochodzące z poprzednich wersji systemu Windows. Zawiera również listę folderów wyłączonych z profilu wędrującego (roaming profiles).

• NTUSER.POL. Ten plik działa jako lokalny bufor (local cache) założeń grupowych (group policies) danego użytkownika, które są pobierane z kontrolera domeny podczas logowania się użytkownika do tej domeny.

• Szablony (Templates). W tym katalogu zapisane są szablony różnych aplikacji, takich jak AmiPro, Lotus 1-2-3 i starszych wersji Microsoft Office.

Kilka folderów profilu użytkownika jest ukrytych. Ogranicza to szanse przypadkowego usunięcia lub przeprowadzania niepożądanych eksperymentów. Aby zobaczyć pliki i foldery ukryte, należy postępować zgodnie z poniższą procedurą:

Procedura 16.1. Oglądanie plików i folderów ukrytych

1. Z menu foldera wybierz pozycje NARZĘDZIA|OPCJE FOLDERÓW (TOOLS|FOLDER OPTIONS).

2. Wybierz zakładkę Widok (View).

3. Wybierz Pokaż ukryte pliki i foldery (Show Hidden Files and Folders).

4. Wyczyść pole Ukryj chronione pliki systemu operacyjnego (Hide Protected Operating System Files) i potwierdź ostrzeżenie.

5. Wybierz i naciśnij OK.

Krok 4 umożliwia oglądanie tzw. plików podwójnie ukrytych (superhidden files). Jest to nowe określenie w systemie Windows 2000, odnoszące się do plików, które mają ustawione dwa atrybuty: Ukryty (Hidden) i Systemowy (System). Założenia grupowe (group policy) blokują zdolność użytkownika do prezentowania plików ukrytych i podwójnie ukrytych (superhidden). Więcej informacji zawarto we fragmencie niniejszego rozdziału pod nazwą „Przydzielanie założeń grupowych dla obiektów Użytkownik (User) i Komputer (Computer)”.

Ponadto oprócz ukrycia prawie wszystkich folderów z profilu użytkownika, także wiele pozycji menu Start jest usuniętych. Dotyczy to również Narzędzi administracyjnych (Administrative Tools) w systemie Windows 2000 Professional. Poniżej podano sposób przywrócenia tych opcji do menu:

Procedura 16.2. Modyfikowanie menu Start

1. Prawym klawiszem myszy kliknij Pasek zadań (Task Bar).

2. Z menu wybierz pozycję Właściwości (Properties).

3. Wybierz zakładkę Zaawansowane (Advanced).

4. Wybierz pozycje, które mają być wyświetlane w menu START.

5. Aby zapisać dokonane zmiany, naciśnij OK.

Wskazówki dotyczące Rejestru: opcje Pokaż pliki i foldery ukryte (Show Hidden Files and Folders)

Stan pola opcji Pokaż pliki i foldery ukryte (Show Hidden Files and Folders) w oknie Opcje foldera (Folder Options), razem z innymi zaawansowanymi opcjami foldera, takimi jak Ukryj rozszerzenie pliku (Hide File --> Extension) i Pokaż wskazówkę (Show Tip) zawarte są w kluczu Rejestru [Author:UP] HKLM|Software|Microsoft|Windows|CurrentVersion|Explorer|Advanced|Folder.

Nazwy, lokalizacja i prawo własności profilów

Kiedy użytkownik loguje się w komputerze z systemem Windows 2000, proces systemowy (system process) o nazwie Userinit tworzy nowy profil użytkownika kopiując zawartość profilu domyślnego użytkownika, który jest zapisany w folderze \Dokumenty i ustawienia (Documents and Settings). Proces ten różni się od inicjalizacji użytkownika w systemie NT 4 w kilku punktach:

Lokalizacje profilów

W systemie Windows NT 4 profile użytkowników są zapisane w katalogu \WINNT\Profile (\WINNT\Profiles). Windows 2000 przechowuje profile w folderze \Documents and Settings katalogu głównego partycji systemowej. Na rys 16.1 przedstawiono lokalizację i układ foldera.

Rysunek 16.1. Okno Eksploratora przedstawiające profil użytkownika systemu Windows 2000 zapisany w katalogu Documents and Settings.

Po przejściu ze starszej wersji systemu Windows na Windows 2000, istniejące profile pozostają w poprzednim miejscu, tzn. w katalogu \WINNT\Profile (\WINNT\Profiles). W tym samym katalogu zapisywane są także wszystkie nowe profile. W trakcie aktualizacji systemu do wersji Windows 2000 i załadowaniu usług Terminala (Terminal Services) jako części wstępnej aktualizacji, program instalacyjny przeniesie profile użytkowników do foldera Documents and Settings. Po standardowej aktualizacji i późniejszej instalacji usług Terminala (Terminal Services) profile pozostają w katalogu \WINNT\Profile (\WINNT\Profiles).

Lokalizację folderów profilów użytkownika można sprawdzić otwierając wiersz poleceń (command prompt) i podając polecenie Set Userprofile. Jeśli użytkownik ma profil wędrujący, podana jest ścieżka do kopii w buforze lokalnym.

Nazwy profilów

W systemie Windows NT 4, najwyższy folder w profilu ma taką samą nazwę, jak identyfikator logowania użytkownika (user logon ID). W systemie Windows 2000 nazwa profilu podstawowego tworzona jest w ten sam sposób, ale nazwy kolejnych profilów danego użytkownika powstają inaczej:

• W systemie Windows NT nazwą drugiego profilu danego użytkownika jest identyfikator logowania (logon ID) z dodanym rozszerzeniem liczbowym rozpoczynającym się od .000, na przykład JLeno.000. Utrudnia to określenie pochodzenia wielu profilów zapisanych w danym komputerze.

• W systemie Windows 2000 nazwa drugiego profilu użytkownika również zaczyna się od identyfikatora logowania (logon ID) użytkownika, ale rozszerzeniem jest domena użytkownika, np. JLeno.TonightShow. Jeśli użytkownik zaloguje się w komputerze lokalnym, a nie w domenie, to wtedy rozszerzeniem jest nazwa tego komputera.

• Jeśli użytkownik zaloguje się wykorzystując ten sam identyfikator logowania (logon ID) i domenę jako istniejący profil, do pełnej nazwy profilu dodawane jest rozszerzenie .000, np. JLeno.TonightShow.000.

Prawo własności profilu

Program systemowy Userinit nadaje uprawnienia Full Control do całego profilu zarówno użytkownikowi, jak i lokalnej grupie Administrators. Jest to zmiana w stosunku do systemu Windows NT 4, w którym tylko użytkownik jest umieszczony na liście ACL. Danie prawa dostępu grupie Administrators upraszcza obsługę profilów użytkownika bez narażania na szwank bezpieczeństwa.

Jeśli tworzy się profil mobilny (roaming profile), to profil zapisany w serwerze ma tylko konto użytkownika na liście ACL. To samo dotyczy kluczy Rejestru zapisanych w pliku NTUSER.DAT. Użytkownikowi i grupie Administrators nadano uprawnienia Full Control w komputerze lokalnym. Tylko użytkownik ma uprawnienia Full Control do kopii profilu w serwerze.

Prawo własności folderów profilów i kluczy Rejestru nadano grupie Administrators.

Wskazówka dotycząca Rejestru: Userinit

Program Userinit zapisuje nazwę profilu i identyfikator bezpieczeństwa użytkownika (SID) w kluczu Rejestru HKLM|Software|Microsoft|WindowsNT|CurrentVersion|ProfileList.

Korzystanie z profilu Wszyscy użytkownicy (All Users)

Profil Wszyscy użytkownicy (All Users), zapisany w folderze Documents and Settings, zawiera foldery, w których zapisane są równolegle profile użytkownika. Pliki z profilu Wszyscy użytkownicy (All Users) są łączone z tymi w profilu użytkownika, kiedy są wyświetlane przez powłokę (shell). Klikając prawym klawiszem myszy przycisk Start i wybierając z menu pozycję Wszyscy użytkownicy (All Users) można zobaczyć zawartość foldera Wszyscy użytkownicy (All Users). (Działa tylko dla użytkowników mających uprawnienia administratora).

Programiści aplikacji mogą wybrać, czy zainstalować skróty (shortcuts) menu Start i skróty (shortcuts) Pulpitu (Desktop) do profilu użytkownika czy profilu Wszyscy użytkownicy (All Users). Decyzja w tej sprawie zwykle zależy od tego, gdzie są zapisane pozycje Rejestru danej aplikacji. Jeśli aplikacja zapisuje pozycje Rejestru w gałęzi HKEY_Current_User, skrót (shortcut) prawdopodobnie znajdzie się w profilu użytkownika. Niektóre aplikacje są trochę sprytniejsze i umieszczają skróty w profilu Wszyscy użytkownicy (All Users), a następnie za pomocą programu instalatora budują interfejsy dla nowych użytkowników.

--> System Windows NT 4 rozróżnia pomiędzy pozycjami menu Start w profilu użytkownika a profilem Wszyscy użytkownicy (All Users),[Author:UP] umieszczając ukośną linię w menu podręcznym. W systemie Windows 2000 tak się nie dzieje. Pozycje z obydwu profilów zostają przemieszane i tworzą jedną listę. Na przykład, jeśli zostanie utworzony folder o nazwie Company Info w folderze Pulpit (Desktop), zarówno w profilu użytkownika jak i w profilu Wszyscy użytkownicy, na pulpicie pojawi się tylko jeden folder „Company Info”, w którym przedstawiona jest zawartość pojedynczych folderów w dwóch profilach.

Założenia systemowe przekierowywania folderów (Folder Redirection policy) mogą być wykorzystywane do wskazywania użytkowników w pojedynczym profilu Wszyscy użytkownicy (All Users). Upraszcza to umieszczanie elementów na pulpitach i w menu START. Więcej szczegółów podano w dalszej części niniejszego rozdziału, w podrozdziale „Zarządzanie przekierowywaniem folderów (Folder Redirections)”.

Wskazówka dotycząca Rejestru: lokalizacja profilów użytkownika

Lokalizacje profilów użytkownika zapisane są w kluczu Rejestru HKLM|Software|Microsoft|Windows NT|CurrentVersion|ProfileList.

Klucz ten zawiera podklucze o nazwach odpowiadających identyfikatorowi bezpieczeństwa (SID) użytkownika związanego z danym profilem. Wartość ProfileImagePath w kluczu profilu danego użytkownika wskazuje lokalizację profilu.

Klucz ProfileList zawiera wartości wskazujące lokalizację profilu Wszyscy użytkownicy (All Users) i profilu Domyślni użytkownicy (Default Users).

Profil .DEFAULT

Nie należy mylić profilu Domyślnego użytkownika (Default User profile) z kluczem Rejestru o nazwie .DEFAULT. Klucz ten reprezentuje gałąź Rejestru DEFAULT, która zawiera parametry użytkownika dla konta System lokalny (Local System). Gałąź DEFAULT jest zapisana razem z pozostałymi gałęziami Rejestru w folderze \WINNT\System32\Config.

Modyfikowanie profilu użytkownika domyślnego (Default User profile)

Dodając foldery i pliki do profilu Użytkownik domyślny (Default User), można skonfigurować profil standardowy i uczynić go częścią plików pulpitu, które stosuje się w całej firmie. Na przykład można dodać skróty do firmowej witryny internetowej lub aplikacji standardowych, takich jak system rejestracji czasu pracy. Dodatki do profilu Użytkownik domyślny (Default User) są dołączane do każdego nowego profilu, tworzonego kiedy użytkownik loguje się do sieci pierwszy raz.

Aby zmodyfikować standardowe środowisko Eksploratora dla nowych użytkowników, można zmienić ustawienia w gałęzi Rejestru Użytkownik domyślny, NTUSER.DAT. Jako przykład weźmy zastąpienie domyślnego tła pulpitu na firmowe. Można skopiować mapę bitową do katalogu lokalnego \WINNT, załadować gałąź NTUSER.DAT do Edytora Rejestru (Registry Editor), a następnie zmienić tapetę Pulpitu w następujący sposób:

Procedura 16.3. Zmiana pozycji Rejestru dotyczących profilu Użytkownika domyślnego

1. Uruchom Regedt32 poleceniem Uruchom (Run) lub z wiersza poleceń.

2. Przejdź do okna HKEY_USERS i podświetl ikonę HKEY_USERS.

3. Z menu wybierz REJESTR|ŁADUJ GAŁĄŹ (REGISTRY|LOAD HIVE).

4. Przejdź do miejsca, w którym zapisany jest profil Użytkownik domyślny — w folderze \Dokumenty i ustawienia (\Documents and Settings) lub WINNT\Profile (WINNT\Profiles). Kliknij dwukrotnie ikonę Ntuser.dat.

5. Edytor Rejestru (Registry Editor) poprosi o podanie nazwy dla klucza reprezentującego tę gałąź. Jest to tylko nazwa symbolu --> zastępczego (placeholder[Author:E] name) i nie ma stałego znaczenia w Rejestrze. Można nadać temu kluczowi nazwę Fred lub też bardziej formalną nazwę Default_User_Hive. Po wprowadzeniu nazwy naciśnij OK. Gałąź pojawi się jako klucz na najwyższej pozycji poddrzewa HKEY_USERS.

6. Przejdź do klucza PANEL STEROWANIA (CONTROL PANEL).

7. Znajdź pozycję Tapeta (Wallpaper). Domyślną wartością jest Brak (None).

8. Kliknij dwukrotnie pozycję Tapeta (Wallpaper), aby otworzyć okno Edytor łańcucha znaków (String Editor). Okno pojawi się, ponieważ typem danych w tej pozycji jest Reg_SZ.

9. Podaj nazwę i ścieżkę dostępu do innego pliku zapisanego w postaci mapy bitowej i naciśnij OK.

10. Aktualizacja pliku NTUSER.DAT dokonywana jest natychmiastowo, ale nie ma potwierdzenia tej operacji.

11. Teraz zwolnij gałąź. Zaznaczać górną część klucza Default_User_Hive i wybierz z menu pozycję REJESTR|ZWOLNIJ GAŁĄŹ. Edytor poprosi o potwierdzenie. Potwierdź naciskając OK. Jeśli pominiesz ten etap procedury, gałąź pozostanie zablokowana, a nowi użytkownicy otrzymają profil Rejestru z profilu systemowego .DEFAULT.

12. Zamknij Edytor Rejestru (Registry Editor).

13. Wyloguj się, a następnie zaloguj się podając identyfikator użytkownika, który jeszcze nigdy nie logował się w danym komputerze. Użytkownik otrzymuje nowy Pulpit w postaci mapy bitowej.

--> Przechowywanie[Author:E] ustawień profilu lokalnego

W razie ponownej instalacji systemu Windows 2000 w komputerze użytkownika, tracona jest konfiguracja komputera i ustawienia aplikacji, o ile profil lokalny nie został zachowany przed jej wykonaniem.

Jednym ze sposobów ochrony profilu użytkownika jest skopiowanie go do serwera razem z pozostałymi ochranianymi danymi użytkownika, sformatowanie dysku twardego, ponowne zainstalowanie systemu Windows 2000, a następnie skopiowanie profilu w to samo miejsce. W przypadku użycia tej metody konieczne jest wykonanie kilku dodatkowych kroków, aby użytkownik miał dostęp do profilu. Najpierw musi być zmieniona zawartość Rejestru, ponieważ klucz HKLM|Software|Microsoft|Windows NT|CurrentVersion|ProfileList, wskazujący profile lokalne, nie zawiera już podklucza dla profilu użytkownika --> (poniżej opisałem sposób przeprowadzenia całej operacji)[Author:E] .

Poniżej opisano sposób przechowywania profilu użytkownika przed ponowną instalacją systemu Windows 2000 i odtworzenia dostępu do tego profilu po zakończeniu tej operacji. Przyjęto, że użytkownik loguje się do domeny.

Procedura 16.4. Przechowywanie i odtwarzanie ustawień profilu lokalnego

1. Zaloguj się, wykorzystując konto z lokalnymi uprawnieniami administratora.

2. Skopiuj profil użytkownika do serwera.

3. Sformatuj dysk i zainstaluj ponownie Windows 2000.

4. Skopiuj profil użytkownika z serwera do foldera Documents and Settings.

5. Zaloguj się na konto użytkownika. Na podstawie profilu Domyślny użytkownik (Default User) powstanie wtedy nowy profil, który będzie miał rozszerzenie .000.

6. Wyloguj się.

7. Zaloguj się, wykorzystując konto administracyjne.

8. Uruchom Edytor Rejestru (Registry Editor).

9. Przejdź do gałęzi drzewa HKLM|Software|Microsoft|Windows NT|CurrentVersion|ProfileList|<user_SID>. Odpowiedni identyfikator bezpieczeństwa użytkownika (user SID) można znaleźć, sprawdzając wartość ProfileImagePath w tym kluczu.

10. Zmień wartość ProfileImagePath, aby wskazywała na starą wersję profilu.

11. Zamknij Edytor Rejestru (Registry Editor).

12. Powiedz użytkownikowi, aby się zalogował. Profil użytkownika będzie miał poprzednie ustawienia.

Kopiowanie profilów pomiędzy użytkownikami

Czasem może zaistnieć konieczność stworzenia jakiemuś użytkownikowi dostępu do profilu innego użytkownika. Na przykład Ted jest kierownikiem działu i w jego komputerze zainstalowane są narzędzia konieczne do pracy. Ted opuszcza firmę i jego miejsce zajmuje Nancy. Nancy chce zachować aplikacje i ustawienia dotyczące Teda, zamiast ponownego instalowania i konfigurowania. W tym celu konieczne jest skopiowanie profilu Teda.

Inną powszechnie spotykaną sytuacją wymagającą skopiowania profilu jest --> kolonowanie[Author:E] (cloning) profilu głównego, utworzonego, by korzystać z niego jako profilu obowiązkowego (mandatory profile). Więcej informacji na ten temat zapisano w podrozdziale zatytułowanym „Zarządzanie środowiskiem pracy użytkownika za pomocą profilów obowiązkowych (mandatory profiles)”.

Nie można po prostu zmienić pozycji w Rejestrze, żeby wskazywała na ten drugi profil, jak to opisano w poprzednim podrozdziale. Pliki, foldery i klucze Rejestru w danym profilu mają na listach ACL tylko użytkowników, którzy je utworzyli, oraz grupę Administrators. Listy ACL mogą być zmodyfikowane za jednym podejściem za pomocą Panelu Sterowania (Control Panel) i pozycji SYSTEM|PROFILE UŻYTKOWNIKA (SYSTEM PROPERTIES|USER PROFILES) w następujący sposób:

Procedura 16.5. Kopiowanie profilu użytkownika i zmiana prawa dostępu

1. Uruchom Panel sterowania (Control Panel) za pomocą menu START|USTAWIENIA|PANEL STEROWANIA (START|SETTINGS|CONTROL PANEL).

2. Uruchom applet System.

3. Wybierz zakładkę Profile użytkowników (User Profiles). Lista Profile zapisane w tym komputerze (Profiles Stored On This Computer) zawiera nazwy wszystkich użytkowników, którzy logowali się do danego komputera i otrzymali profil. Przykładowa lista zamieszczona jest na rysunku 16.2.

Rysunek 16.2. Okno Właściwości systemu (System Properties) komputera lokalnego przedstawiające listę profilów zapisanych w tym komputerze.

4. Wybierz profil, który chcesz skopiować i naciśnij przycisk Kopiuj do (Copy To). Pojawi się okno Kopiuj do (Copy To)(rys. 16.3).

Rysunek 16.3. Okno Kopiuj do (Copy To), przedstawiające opcje kopiowania profilu użytkownika.

5. W polu Kopiuj profil do (Copy Profile To) wpisz ścieżkę dostępu i nazwę pliku nowego profilu. Jeśli podana ścieżka dostępu nie istnieje, system utworzy ją. W powyższym przykładzie ścieżka dostępu wskazuje na folder lokalny Documents and Settings.

6. Trzeba zmienić również prawa dostępu do profilu. Naciśnij przycisk Zmień (Change) i wybierz nowego użytkownika i grupę spośród wszystkich przedstawionych w oknie Wybierz użytkownika lub grupę (Select User or Group).

7. W oknie Kopiuj do (Copy To) naciśnij przycisk OK. Utworzony zostanie nowy profil.

8. Uruchom Edytor Rejestru (Registry Editor).

9. Przejdź do gałęzi HKLM|Software|Microsoft|Windows NT|CurrentVersion|ProfileList|<user_SID>. Odpowiedni identyfikator bezpieczeństwa użytkownika (user SID) można znaleźć sprawdzając wartość ProfileImagePath w tym kluczu.

10. Zmień wartość ProfileImagePath, aby wskazywała na nowy profil.

11. Zamknij Edytor Rejestru (Registry Editor).

12. Powiedz użytkownikowi, aby się zalogował. Profil użytkownika będzie miał nowe ustawienia.

Innym sposobem zachowania profilu użytkownika w razie ponownego instalowania systemu jest tymczasowe skonfigurowanie profilu mobilnego (roaming profile). Sposób ten opisano w poniższym podrozdziale.

Zarządzanie profilami mobilnymi

Użytkownicy poświęcają zbyt wiele czasu dopasowując konfiguracje swoich komputerów do własnych nawyków. Użytkownik przesiadający się od jednego komputera do drugiego nie chce za każdym razem powtarzać zmian konfiguracji. Sposobem rozwiązania problemu użytkowników mobilnych (roaming users) jest zapisanie ich profilów w serwerze. Kiedy użytkownicy logują się do domeny, profile są ściągane do ich komputerów automatycznie. Profile przechowywane w serwerze noszą nazwę profilów mobilnych (roaming profiles).

Poniżej opisano sposób konfigurowania profilów wędrujących i zdarzenia występujące podczas logowania się użytkownika wędrującego.

Procedura 16.6. Sposób konfigurowania profilów mobilnych

1. Wybierz serwer, który będzie serwerem macierzystym profilów mobilnych (roaming profiles). Nazwij go serwerem profilów (profile serwer).

2. W serwerze profilów utwórz folder, w którym będą zapisane profile i udostępnij go.

3. Skonfiguruj opcję Profil (Profile) konta użytkownika, aby wskazywała na folder udostępniony, utworzony w poprzednim kroku.

4. Użytkownik loguje się w dowolnym w komputerze z systemem Windows 2000 w danej domenie.

5. WINLOGON rozpoznaje, że dany użytkownik ma korzystać z profilu mobilnego i przekazuje to procesowi systemowemu o nazwie Userinit.

6. Userinit za pomocą programu USERENV.DLL kopiuje profil użytkownika z serwera profilów na lokalny dysk twardy.

7. W ciągu dnia pracy zmiany wprowadzone do profilu przez użytkownika są zapisywane na dysku lokalnym. Poprawia to wydajność systemu i zmniejsza ruch w sieci.

8. Kiedy użytkownik wylogowuje się, Userinit kopiuje profil z powrotem do serwera profilów.

Brzmi to prosto, czyż nie? Poniekąd tak jest. Ale profile wędrujące mogą upodobnić się do pierwszego rozdziału „Opowieści o dwóch miastach” Dickensa — mogą być najlepszym i najgorszym rozwiązaniem. Mogą być najlepszym rozwiązaniem, ponieważ użytkownicy zabierają ze sobą swoje środowisko pracy do dowolnego komputera w domenie. Zapewnia im to wygodę i poprawia wydajność pracy. Administrator jest bohaterem. Mogą być najgorszym rozwiązaniem, ponieważ znaczny wysiłek przy integracji systemu jest poświęcony na stworzenie odpowiedniego środowiska pracy dla użytkowników wędrujących. Czasem wyjdzie coś na opak i użytkownicy nie będą w stanie znaleźć swoich plików. Admnistrator, który znajdzie się w takiej sytuacji, powinien starać się nie myśleć o zakończeniu wspomnianej powyżej książki.

Ograniczenia rozmiaru Rejestru a profile wędrujące

Dość powszechnym problemem z profilami mobilnymi (roaming profiles) w systemie Windows NT 4 jest błąd „Brak zasobów”, pojawiający się, kiedy użytkownik mobilny (roaming user) próbuje zalogować się po raz pierwszy do nowego komputera.

Błąd ten pojawia się, ponieważ plik NTUSER.DAT w profilu użytkownika jest zbyt duży, aby zmieścić się w obszarze pamięci tego komputera, ograniczonym domyślnym rozmiarem Rejestru (Registry Size Limit — RSL).

W systemie Windows NT4 niezbyt eleganckim, ale skutecznym rozwiązaniem tego problemu jest zalogowanie się jako administrator i powiększenie RSL za pomocą Właściwości systemu (System Properties) w Panelu sterowania (Control Panel).

W systemie Windows 2000 wartość RSL jest zwiększana automatycznie, jeśli okaże się zbyt mała aby pomieścić profil użytkownika.

Planowanie wdrażania profilów mobilnych (roaming profiles)

Aby zaplanować obsługę profilów mobilnych (roaming profiles) koniecznie trzeba odpowiedzieć na wiele pytań.

• Czy użytkownicy logują się zarówno na komputerach z systemem Windows 2000/NT, jak i Windows 9x? Konieczne jest stworzenie równoległych profilów dla obydwu środowisk. Profile użytkowników systemu Windows 9x mogą być zapisane w tym samym serwerze profilów, ale dobrym rozwiązaniem jest wykorzystanie oddzielnego katalogu.

• Czy użytkownicy zapisują w swoich profilach lokalnych tony plików? Konieczne jest przedsięwzięcie kroków, by kontrolować rozmiar profilu i ostrzegać użytkowników, jeśli profil jest zbyt duży. Można to zrobić poprzez nakładanie ograniczeń obszaru dysku dostępnego dla danego użytkownika (quota).

• Czy użytkownicy logują się na wielu komputerach jednocześnie? Administrator powinien być przygotowany na rozwiązywanie problemów związanych z plikami utraconymi lub zapisanymi jeden na drugim, chociaż system Windows 2000 radzi sobie lepiej z zarządzaniem wieloma profilami niż Windows NT 4.

• Czy serwer profilów stanowi wąskie gardło dla połączeń sieciowych i przechowywania plików? Przed zastosowaniem profilów mobilnych (roaming profiles) na dużą skalę trzeba zaplanować modernizację serwerów. Wyobraźmy sobie 100 użytkowników pobierających codziennie rano z serwera tysiące plików. Serwer musi być do tego przygotowany.

• Czy któryś z użytkowników loguje się wykorzystując usługi terminala (Terminal Services)? Należy zwracać uwagę na wiele sesji użytkowników, którzy rozłączyli się zamiast wylogowania. W tym przypadku profil nie jest kopiowany z powrotem do serwera profilów. Jeśli folder z profilami zostanie zablokowany, użytkownik po zalogowaniu się do kolejnego komputera lub otwaciu następnej sesji terminala (Terminal Session) otrzyma profil użytkownika domyślnego (Default User profile), który może zastąpić właściwy profil.

• Czy użytkownicy korzystają z połączenia telefonicznego i oczekują, że pojawi się ich najnowszy profil biurowy? Należy zmienić oczekiwania użytkowników.

Konfigurowanie serwera profilów mobilnych

Poniższa lista pomoże w wyborze i konfigurowaniu serwera profilów:

• Niezawodność. Serwer profilów powinien być tak niezawodny, jak to tylko możliwe. Można rozważyć wykorzystanie systemu Windows 2000 w wersji Advanced Server do zbudowania klastra. Można również zainstalować któreś z innych niezawodnych rozwiązań serwera, takich jak Vinca Standby Server lub Octopus Software, których właścicielem jest firma Legato Software, www.legato.com.

• Przechowywanie plików. W woluminie należy pozostawić sporo wolnego miejsca. Każdy wie, jak szybko użytkownicy zapełniają miejsce na dysku. Prawdopodobnie będzie niezbędne okresowe przeprowadzanie defragmentacji woluminu. Program do defragmentacji, aby efektywnie pracować, musi mieć 20-30% wolnego obszaru na dysku. Z tego samego powodu nie kompresuje się woluminu zawierającego katalog domowy (home directory). Ogranicza to skuteczność defragmentacji.

• Ograniczenia obszaru dysku dostępnego dla użytkownika (Quotas). Dla profilów powinien być przeznaczony cały wolumin. Ograniczenia obszaru dysku dostępnego dla użytkownika można wykorzystać do kontroli przechowywania danych. Założenie grupowe (group policy) o nazwie Ogranicz rozmiar profilu (Limit Profile Size) ostrzega użytkowników, jeśli ich profile lokalne przekraczają podane ograniczenia. Szczegóły opisano w dalszej części niniejszego rozdziału, w podrozdziale zatytułowanym „Przydzielanie założeń grupowych dla grup Użytkownicy i Komputery”.

• Woluminy NTFS. System NTFS jest potrzebny do kontrolowania bezpieczeństwa danych użytkownika. System NTFS jest również konieczny, jeśli stosuje się nakładnie ograniczeń obszaru dysku dostępnego dla danego użytkownika (quota).

• Katalogi domowe. Jeśli stosowane są zarówno katalogi domowe (home directories), jak i profile centralne, można je umieścić w tym samym serwerze profilów. Umieszczenie wszystkich informacji użytkowników w jednym miejscu upraszcza administrowanie. Katalogi domowe omówiono w dalszej części niniejszego rozdziału w podrozdziale zatytułowanym „Tworzenie katalogów domowych i zarządzanie nimi”.

Konfigurowanie profilu mobilnego

W tej części opisano tworzenie profilu mobilnego (roaming profile) dla użytkownika. Folder udostępniony, wykorzystywany w podanej poniżej procedurze konfigurowania, nosi nazwę Użytkownicy (Users) i jest udostępniony pod tą samą nazwą. Nazwa udziału nie jest ważna, ponieważ użytkownicy jej nie widzą. Jednak na wypadek, gdyby profile użytkowników poprzednich wersji systemu Windows, katalogi domowe i profile użytkowników systemu Windows 2000 miały być przechowywane w woluminie udostępnionym, konieczne jest ograniczenie jego nazwy do 8 znaków, by wszystkie wersje systemu Windows mogły mieć dostęp do tego udziału.

Przykładowa ścieżka profilu użytkownika jest następująca: \\nazwa-serwera\nazwa-udziału\%username%\%username%. Zmienna środowiskowa (environment variable) %username% odwzorowuje identyfikator logowania użytkownika. Na przykład, dla użytkownika, którego identyfikatorem logowania (logon ID) jest Jspringer, ścieżka zapisana w serwerze profilów to: \\phx—dc-01\users\jspringer\jspringer.

Można wykorzystać dwukrotnie zmienną %username%, tworząc dwa foldery identyfikowane przez identyfikator logowania (logon ID) użytkownika. Jeden z nich zostanie katalogiem domowym użytkownika i służy do zapisywania folderów przekierowanych. Drugi to podfolder zawierający profil użytkownika.

Procedura 16.7. Konfigurowanie profilu mobilnego

1. Uruchom konsolę AD Użytkownicy i komputery (AD Users and Computers).

2. Rozwiń drzewo do poziomu kontenera, w którym zapisane są obiekty użytkownika, lub korzystając z funkcji Znajdź (Find), zlokalizuj użytkownika, którego chcesz skonfigurować.

3. Prawym klawiszem myszy kliknij na obiekcie użytkownika i z menu wybierz pozycję Właściwości (Properties). Pojawi się okno Właściwości (Properties) danego użytkownika.

4. Wybierz zakładkę Profil (Profile), której używa się do tworzenia profilów, osobistych skryptów logowania i katalogów domowych.

5. W pozycji Profil użytkownika (User Profile) wpisz Ścieżkę profilu (Profile Path), odpowiadającą folderowi udostępnionemu w serwerze profilów. Przykład zamieszczono na rysunku 16.4. Ścieżka ma postać \\nazwa-serwera\nazwa-udziału\%username%\%username%

Rysunek 16.4. Okno Właściwości użytkownika (User Properties), prezentujące zakładkę Profil (Profile) ze ścieżką do głównego profilu użytkownika.

6. Zapisz zmiany, naciskając OK. Ścieżka zostanie utworzona w serwerze profilów przy następnym zalogowaniu się użytkownika.

Testowanie profilu mobilnego

Po skonfigurowaniu użytkownika, aby mógł korzystać z profilu mobilnego, należy zainicjalizować profil i zagwarantować, że będzie wędrował razem z użytkownikiem.

Możliwych rozwiązań jest kilka, zależnie od tego, czy użytkownik ma już profil lokalny.

• Jeśli użytkownik ma już profil lokalny i chce go zachować, powiedz użytkownikowi, aby zalogował się na komputerze lokalnym, skoro tylko konto zostanie skonfigurowane w ten sposób, by użytkownik mógł korzystać z profilu mobilnego. Kiedy użytkownik wylogowuje się, profil jest kopiowany do serwera profilów (profile server).

• Jeśli użytkownik nie ma profilu lokalnego, może zalogować się do dowolnej stacji roboczej systemu Windows 2000, otrzymując kopię profilu domyślnego użytkownika (Default User profile). Kiedy użytkownik wylogowuje się, nowy profil jest kopiowany do serwera profilów (profile server).

Poniżej opisano procedurę inicjalizacji profilu użytkownika. W przykładzie przyjęto, że użytkownik nie ma jeszcze utworzonego profilu.

Procedura 16.8. Inicjalizacja profilu mobilnego za pomocą profilu Nowy użytkownik

1. Powiedz użytkownikowi, aby zalogował się do domeny Windows 2000 (lub sam zaloguj się jako użytkownik).

2. Skonfiguruj profil domyślny, aby odpowiadał standardom w twojej firmie.

3. Wyloguj się. Profil lokalny jest kopiowany do foldera użytkownika w serwerze profilów (profile server). Zanim wylogowanie użytkownika zostanie zakończone, może upłynąć kilkanaście sekund, zależnie od ruchu w sieci, obciążenia serwera i rozmiarów profilu.

4. W serwerze profilów (profile server) sprawdź, czy profil użytkownika znajduje się w folderze udostępnionym. Jeśli wykorzystano dwukrotnie pozycję %username%, tworząc zarówno katalog domowy, jak i folder profilów, to wtedy katalog domowy dziedziczy prawa ACL foldera źródłowego (parent folder), a profil na liście ACL ma jedną pozycję użytkownika.

5. Zaloguj się w innym komputerze z systemem Windows 2000 korzystając z konta użytkownika mobilnego i sprawdź, czy środowisko pracy zostało skopiowane do tego komputera.

6. Uruchom Eksploratora i przejdź do folderu Documents and Settings, aby sprawdzić, czy profil główny został skopiowany do komputera lokalnego. Kiedy wylogujesz się, profil jest kopiowany z powrotem do serwera profilów.

Środki ostrożności przy korzystaniu z profilów mobilnych (roaming profiles)

Stosując profile mobilne (roaming profiles), należy unikać popełnienia poniższych błędów.

• Jednoczesne logowanie się do wielu komputerów. Jeśli użytkownik loguje się do wielu komputerów i wprowadza zmiany profilu w każdym komputerze, niektóre zmiany mogą zostać nadpisane, kiedy użytkownik wyloguje się i następuje kolizja profilów w serwerze profilów. Więcej informacji zawiera wskazówka pod tytułem „Kolizje profilów mobilnych (roaming profiles)”, zamieszczona w dalszej części niniejszego rozdziału.

• Profile są zapisywane w serwerze profilów przy wylogowywaniu, tylko jeśli są kopiowane do komputera lokalnego przy logowaniu się. Jeśli użytkownik nie połączył się z serwerem profilów przy logowaniu się, procedura Userinit wysyła komunikat o błędzie i loguje użytkownika wykorzystując profil lokalny z bufora podręcznego. Jeśli takiego profilu nie ma w buforze, nowy profil jest tworzony na podstawie profilu Użytkownik domyślny (Default User). Kiedy użytkownik wylogowuje się, kopia profilu lokalnego nie zostanie wykonana, nawet jeśli serwer profilów jest dostępny. Zapobiega to uszkodzeniom plików w serwerze. Przy kolejnym logowaniu serwer sprawdza znaczniki czasu (time stamps) plików lokalnych i nie nadpisuje ich. Działanie to różni się od zachowania systemu Windows NT. Więcej informacji zawiera wskazówka pod tytułem „Kolizje profilów mobilnych (roaming profiles)”, zamieszczona w dalszej części niniejszego rozdziału.

• Pliki zaszyfrowane w profilach mobilnych (roaming profiles). Pliki zaszyfrowane nie mogą być zapisane w profilu mobilnym użytkownika. Klucze szyfrowania i odszyfrowywania są zapisane w profilu użytkownika i potrzebne są systemowi do replikacji plików. Jeśli użytkownik zaszyfruje pliki w swoim profilu mobilnym, a następnie wyloguje się, procedura Userinit wyświetla komunikat o błędzie: „System Windows nie może skopiować Twojego profilu, ponieważ zawiera on pliki lub katalogi zaszyfrowane. Odszyfruj pliki i spróbuj ponownie”. („Windows --> cannot [Author:UP] copy your profile because it contains encrypted files or directories. Please decrypt the files and try again.”). Użytkownik musi zalogować się ponownie, odszyfrować pliki, wylogować się, a następnie kolejny raz zalogować i wylogować się, by pliki zostały odpowiednio skopiowane. Jeśli konieczne jest umieszczenie w serwerze plików zaszyfrowanych, należy użyć przekierowywania folderów (folder redirection). Więcej informacji na ten temat zawiera podrozdział „Zarządzanie przekierowywaniem folderów” w dalszej części niniejszego rozdziału. Również w rozdziale 15. „Zarządzanie zasobami udostępnionymi” opisuję, na co zwracać uwagę przy zapisywaniu plików zaszyfrowanych w serwerach.

• Nie wykonuje się replikacji zmian atrybutów plików, dopóki pliki nie ulegną zmianie. W przypadku zmiany atrybutów (tylko do odczytu, ukryty, systemowy, archiwalny), deskryptora bezpieczeństwa lub ustawień kompresji plików, ale bez zmiany danych zawartych w plikach, poprawki te nie są wprowadzane w pliku zapisanym w serwerze profilów (profile server).

• Profile usług terminalowych (Terminal Services). Użytkownicy mobilni otrzymują swoje profile mobilne (roaming profiles), kiedy logują się w konsoli Usługi terminalowe (Terminal Services), tak jakby logowali się do zwykłego komputera. Lokalna kopia profilu nie jest kopiowana do serwera profilów, dopóki użytkownik całkowicie nie zakończy sesji usług terminala i nie wyloguje się. Jeśli użytkownik tylko rozłączy się, profil pozostanie aktywny w serwerze usług terminalowych (Terminal Services server) i nie będzie skopiowany. Wskazówka pod tytułem „Kolizje profilów wędrujących”, zamieszczona w dalszej części niniejszego rozdziału, opisuje co stanie się, jeśli użytkownik zaloguje się kolejny raz z innego komputera lub ustanowi sesję usług terminalowych.

• Zmiana nazw plików. Jeśli użytkownik zmieni nazwę plików w profilu, plik źródłowy pozostanie w serwerze i będzie pobrany, kiedy użytkownik zaloguje się kolejny raz. Od tej chwili, jeśli użytkownik usunie ten plik, oznacza to usunięcie pliku z centralnego profilu podczas wylogowywania się. Problem ten usunięto w aktualizacji konserwacyjnej (maintenance update) systemu Windows 2000.

• Zgodność z systemem Windows NT. Profile systemu Windows 2000 są zgodne z profilami systemu Windows NT 4. Użytkownik mobilny może logować się do komputerów Windows 2000 i stacji roboczych Windows NT. Przy logowaniu się do systemu Windows NT wszystkie pozycje Rejestru właściwe dla systemu Windows 2000 są pomijane. Profile systemu Windows 2000 nie są zgodne z profilami Windows NT 3.51.

• Zmiany identyfikatora użytkownika (user ID). Po usunięciu konta użytkownika i ponownym utworzeniu konta, które ma tę samą nazwę, przypisywany jest inny identyfikator bezpieczeństwa SID. Ponieważ nowy identyfikator SID nie zgadza się z identyfikatorem SID, związanym z profilem mobilnym użytkownika, profil ten nie może być wykorzystany. Procedura Userinit wysyła ostrzeżenie o braku dostępu (access denied) i na podstawie profilu Domyślny użytkownik (Default User), tworzony jest nowy profil lokalny użytkownika. Problem ten ominąć można poprzez zmianę użytkownika danego profilu. Sposób ten opisano powyżej w podrozdziale zatytułowanym „Kopiowanie profilu pomiędzy użytkownikami”.

• Profile mogą osiągać bardzo duże rozmiary. Profile mogą osiągnąć bardzo duże rozmiary, ponieważ aplikacje zapisują swoje pliki i dane konfiguracyjne w folderze Moje dokumenty (My Documents). Może zaistnieć sytuacja, w której setki użytkowników mobilnych (roaming users), których profile zawierają megabajty plików, logują się i wylogowują w tym samym czasie. Zamiast umieszczania foldera Moje dokumenty (My Documents) w profilu standardowym, można zastosować przekierowanie folderów i umieścić folder Moje dokumenty (My Documents) w oddzielnym miejscu sieci. Założenia systemowe ostrzegają użytkowników, jeśli ich profile przekraczają nałożone ograniczenia. Więcej informacji znajduje się w podrozdziale „Szablony administracyjne” (Administrative Templates) w dalszej części niniejszego rozdziału.

• Wolne połączenia. Jeśli użytkownik loguje się wykorzystując połączenie RAS, przesłanie profilu poprzez linię modemową zajmuje sporo czasu, zwłaszcza kiedy profil zawiera folder Moje dokumenty (My Documents) i inne foldery o dużych rozmiarach. Aby zapobiec takim opóźnieniom, system wykrywa, że połączenie jest wolne (500 kbps) i logującemu się użytkownikowi przypisuje profil zapisany lokalnie w buforze podręcznym. Konfigurując laptopa do pracy w środowisku laboratoryjnym, koniecznie trzeba zalogować się przynajmniej raz jako użytkownik, by uzyskać kopię własnego profilu standardowego na dysku lokalnym.

• Profile lokalne pozostają na dysku. Użytkownicy mobilni (roaming users) logujący się w wielu komputerach pozostawiają kopie swoich profilów w każdym z komputerów. Może to stanowić problem z bezpieczeństwem, nawet jeśli dyski lokalne są sformatowane w systemie plików NTFS. Jeśli użytkownicy mają lokalne uprawnienia administracyjne, mogą przejąć kopię lokalną profilu mobilnego (roaming profile) i poprzez zmianę listy ACL uzyskać prawo dostępu. Pozycja Rejestru o nazwie HKLM|Software|Microsoft|Windows NT|CurrentVersion|WINLOGON|DeleteRoamingCache powoduje usunięcie kopii lokalnej po wylogowaniu się użytkownika. Wartość w tej pozycji można ustawić bezpośrednio w Rejestrze lub za pomocą założeń systemowych dotyczących grup (group policy). Założenia systemowe noszą nazwę Konfiguracja komputera|Szablony administracyjne|System|Logowanie|Usuń buforowane kopie profilów mobilnych (Computer Configuration|Administrative Templates|System|Logon|Delete Cached Copies of Roaming Profiles).

Kolizje profilów mobilnych

W systemie Windows NT 4 sposób obsługi replikacji plików w profilach mobilnych (roaming profiles) nie jest zbyt skomplikowany. W tym systemie profile są po prostu kopiowane do lokalnego komputera w trakcie logowania. Przy wylogowywaniu są kopiowane z powrotem do serwera. Każdy zmieniony plik zostanie nadpisany. Każdy z plików usuniętych z komputera lokalnego zostanie również usunięty z serwera bez pytania o potwierdzenie tej operacji.

Ta metoda replikacji jest dobra w przypadku pojedynczego logowania się, ale sprawia prawdziwe kłopoty użytkownikom mobilnym (roaming users), którzy logują się w tym samym czasie do wielu komputerów. Użytkownik może dodawać, modyfikować i usuwać pliki, znadujące się w różnych miejscach, a następnie wylogowywać się w kolejności innej, niż przebiegało logowanie. Efekt końcowy takich modyfikacji jest nieprzewidywalny, ale prawie zawsze powoduje kłopoty.

System Windows 2000 obsługuje replikację plików w sposób bardziej elegancki, poprzez łączenie plików (merging files), zamiast nadpisywania ich. Wykonuje to poprzez porównywanie znaczników czasu (time stamps) pliku źródłowego i pliku docelowego.

Kiedy loguje się użytkownik mobilny (roaming user), serwer profilów (profile server) zapisuje kopię znaczników czasu plików w profilu. Kiedy użytkownik wyloguje się i klient zaczyna replikację plików z powrotem do serwera, serwer porównuje znaczniki czasu dokumentów przychodzących z tymi, które przechowuje.

• Jeśli z porównania znaczników czasu (time stamps) wynika, że plik zmodyfikowany jest nowszy niż ten przechowywany w serwerze, plik serwerowy zostanie nadpisany.

• Jeśli znacznik czasu wskazuje, że plik zapisany w serwerze jest nowszy, sugerując, że został zmodyfikowany na innym komputerze, a następnie skopiowany do serwera, to wtedy plik serwerowy nie zostanie nadpisany.

• Jeśli w serwerze znajduje się plik, którego nie ma wśród plików skopiowanych z komputera lokalnego, a jego znacznik czasu (time stamp) jest nowszy niż pierwotny znacznik czasu plików, sugerując, że został on dodany na innym komputerze lokalnym, zostanie on zachowany.

• Jeśli w serwerze znajduje się plik, którego nie ma wśród plików skopiowanych z komputera lokalnego a jego znacznik czasu (time stamp) jest taki sam, jak znaczniki czasu tej sesji replikacji przechowywane w serwerze, zostanie on usunięty.

Zarządzanie środowiskiem pracy użytkownika za pomocą profilów obowiązujących (mandatory profiles)

Zamiast przydzielać każdemu użytkownikowi profil mobilny (roaming profile), można określić profil standardowy dla grupy użytkowników. Taki profil --> obowiązujący[Author:UP] (mandatory profile) nie może być konfigurowany przez użytkowników, więc zwykle uzyskanie odpowiedniego połączenia skrótów (shortcuts), pozycji menu Start, aplikacji i innych elementów, które zaspokoi oczekiwania wszystkich użytkowników, zajmuje trochę czasu.

Profil obowiązkowy (mandatory profile) nie jest niczym więcej, niż standardowym profilem zapisanym w serwerze z rozszerzeniem .man w folderze głównym. Rozszerzenie .man oznacza mandatory (obowiązkowy). Na przykład profil obowiązkowy (mandatory) dla grupy Sales tworzy się po prostu zmieniając nazwę najwyższego foldera na Sales.man. Można również uczynić profil obowiązkowym (mandatory) zmieniając nazwę Ntuser.dat na Ntuser.man, ale polecana jest zmiana nazwy całego foldera, ponieważ rodzaj profilu jest od razu widoczny.

Godny podkreślenia jest fakt, że użytkownicy nie mogą modyfikować zawartości profilu obowiązkowego (mandatory profile). Oznacza to, że nie mogą zapisywać plików w folderze Moje dokumenty (My Documents). Przed zastosowaniem profilu obowiązkowego (mandatory profile) trzeba przekierować folder Moje dokumenty (My Documents) do serwera. Szczegóły opisano poniżej w podrozdziale „Zarządzanie przekierowywaniem folderów”.

Oto procedura konfigurowania profilu obowiązkowego (mandatory profile) dla grupy użytkowników:

Procedura 16.9. Konfigurowanie i przypisywanie profilów obowiązkowych (mandatory profiles)

1. Utwórz konto użytkownika do testów.

2. Zaloguj się do komputera korzystając z konta tego użytkownika.

3. Skonfiguruj środowisko pracy zgodnie z Twoimi wymaganiami jako użytkownika.

4. Wyloguj się, aby zapisać profil lokalny w komputerze lokalnym.

5. Zaloguj się jako administrator.

6. Za pomocą procedury Kopiuj profil (Copy Profile), opisanej w podrozdziale „Kopiowanie profilów pomiędzy użytkownikami”, skopiuj profil do serwera profilów (profile server). Nie zapomnij zmienić praw dostępu, aby obejmowały grupę, której chcesz przypisać dany profil.

7. Zmień nazwę profilu, aby była zgodna z nazwą grupy. Nie jest to bezwzględnie konieczne, ale pomaga zidentyfikować profil. Nadaj nazwę z rozszerzeniem .man.

8. Skonfiguruj konto użytkownika w grupie Sales, wskazując na nowy profil.

9. Sprawdź działanie nowego profilu logując się jako członek grupy Sales.

Tworzenie katalogów domowych i zarządzanie nimi

Zapewne większość zgodzi się z opinią, że przeciętny użytkownik nie ma pojęcia, gdzie tak naprawdę przechowywane są jego dane. Każdy, kto instalował komputery, zna wyzwanie, jakim jest poszukiwanie plików danych, schowanych przez użytkowników. Jest to jak szukanie okruszyn w fabryce ciastek.

Takie rozproszenie plików nie zawsze jest winą użytkownika. W znacznej części jest to wina programistów. Większość aplikacji albo zapisuje swoje pliki w tym samym katalogu, co pliki wykonywalne, albo ma swoje własne metody konfiguracji lokalizacji domyślnej. Domyślna lokalizacja plików nie jest w żaden sposób ujednolicona. Firma Microsoft ma nadzieję zmienić taki stan rzeczy w systemie Windows 2000.

Standardowy profil użytkownika w systemie Windows 2000 zawiera typowe foldery dla danych aplikacji i plików konfiguracyjnych. Szczególne foldery to:

• %userprofile%\Moje dokumenty (%userprofile%\My Documents) dla danych.

• %userprofile%\Dane aplikacji (%userprofile%\Application Data) dla plików konfiguracyjnych aplikacji, które wędrują razem z użytkownikiem.

• %userprofile%\Ustawienia lokalne (%userprofile%\Local Settings) dla plików konfiguracyjnych aplikacji, które nie wędrują. Zawartość folderu Ustawienia lokalne (Local Settings) nie podlega replikacji do serwera profilów podczas zapisywania profilu mobilnego. Tworzone są w locie w profilu lokalnym na dysku.

Windows 2000 Platform SDK nakłania programistów, aby zapisywali dane w tych folderach. Stosowanie wyżej wymienionych folderów jest warunkiem uzyskania znaku Ready for Windows 2000. Po pojawieniu się aplikacji spełniających takie wymagania można oczekiwać, że lokalizacja wszystkich danych będzie przewidywalna.

Dotąd jednak dostawcom oprogramowania dużo czasu zajmuje dopasowanie swoich aplikacji do wymagań upoważniających do zamieszczenia logo Windows 2000, nie wspominając już o latach, które upłyną, zanim użytkownicy rzeczywiście kupią i zastosują takie aplikacje. A tymczasem nadal trzeba obsługiwać przechowywanie danych starszych wersji aplikacji. Dla tego celu nie ma nic lepszego nad katalog domowy (home directory). Szczegółowe informacje podano w następnym podrozdziale.

Elastyczna lokalizacja foldera

SDK ostrzega przed zaprogramowaniem aplikacji na sztywno, tak aby wykorzystywała standardową lokalizację folderów profilów. Zamiast tego, do znajdowania lokalizacji folderów profilów wymagane jest wykorzystywanie wywołań API. Pozwala to na stosowanie przekierowywania folderów (folder redirections) i umożliwia przyszłe zmiany konfiguracji, gdyby potrzebna była zmiana lokalizacji folderów profilów.

Omówienie funkcji katalogów domowych (home directories)

Katalog domowy (home directory) jest wygodnym miejscem do przechowywania danych w serwerze. „Zapisz to na dysku U”. Krótkie. Zwięzłe. Łatwe do pojęcia.

Przygotowanie katalogu domowego dla użytkownika przebiega w dwóch etapach.

• Przeznacz serwer z folderem udostępnionym do przechowywania katalogów.

• Skonfiguruj konto użytkownika, wskazując na katalog domowy.

Informacje dotyczące katalogu domowego są zapisane w obiekcie Użytkownik (User) w Active Directory, który ma dwa atrybuty: Katalog domowy (Home-Directory) i Dysk domowy (Home-Drive). Kiedy użytkownik systemu Windows 2000 lub Windows NT loguje się do domeny, litera Dysku domowego jest odwzorowaniem ścieżki w atrybucie Katalog domowy (Home-Directory). Więcej informacji na ten temat podaje podrozdział „Przydzielanie skryptów logowania użytkownikom wykorzystującym poprzednie wersje systemu Windows”.

Oto lista kontrolna (checklist) czynności przygotowawczych przy tworzeniu katalogów domowych użytkowników:

• Serwer katalogów domowych. Serwerem macierzystym katalogów domowych użytkowników może być dowolny serwer systemu Windows 2000 lub Windows NT. Nie musi to być kontroler domeny. W przypadku profilów mobilnych (roaming profiles) oczywistym wyborem jest wykorzystanie serwera profilów (profile server). Jeśli wybór padnie na inny serwer, konieczne jest przeznaczenie całego woluminu na katalogi domowe (home directories), aby wykorzystać zalety nakładania ograniczeń na obszar dysku dostępny dla użytkownika (quota).

• Utwórz i udostępnij folder katalogu domowego (home directory folder). Pojedynczy katalog domowy przyjmuje postać foldera o nazwie takiej, jak identyfikator logowania użytkownika. Dla ułatwienia konserwacji foldery te są zwykle przechowywane we wspólnym udziale.

• Najpierw utwórz konto użytkownika. Nie można przydzielić katalogu domowego za pomocą okna Nowy użytkownik (New User). Taka możliwość pojawi się w kolejnych aktualizacjach systemu Windows 2000. Zanim to nastąpi, najpierw musi być utworzone konto użytkownika, a potem można przydzielić mu katalog domowy (home directory).

• Wykorzystaj ścieżkę UNC zawierającą zmienną %username%. Podając ścieżkę do katalogu domowego użytkownika, wykorzystaj nazwę ścieżki UNC zakończonej zmienną środowiskową %username%. Zagwarantuje to poprawne wprowadzenie nazwy użytkownika, np. \\phx-dc-10.company.com\users\%username%.

• Uwzględnij klienty poprzednich wersji systemu Windows. Użytkownicy mogą logować się z komputerów z systemami Windows 9x lub Windows 3.1x/DOS. Jeśli mają mieć katalogi domowe, nazwa udziału musi być ograniczona do 8 znaków. Klienty poprzednich wersji systemu Windows mogą nie akceptować pełnej nazwy domeny w ścieżce dostępu, więc może zajść konieczność umieszczenia w ścieżce zwykłej nazwy. Potem trzeba wykonać procedurę gwarantującą klientom Windows 2000 znalezienie serwera. Klienty poprzednich wersji Windows nie mogą być przypisywane do podkatalogów, więc katalogi domowe koniecznie trzeba umieścić w woluminie NTFS, ponieważ dysk domowy (home drive) zawiera wszystkie katalogi użytkowników.

Katalogi domowe (home directories) można utworzyć na dwa sposoby: korzystając z graficznych narzędzi zarządzania konsoli AD Użytkownicy i komputery (AD Users and Computers) lub za pomocą wiersza poleceń. Pierwszy przykład dotyczy konsoli.

Przydzielanie katalogu domowego za pomocą konsoli AD Użytkownicy i komputery (AD Users and Computers)

Po przygotowaniu foldera udostępnionego, zawierającego katalogi domowe i utworzeniu kont użytkowników, katalogi domowe przydziela się do konta użytkownika w następujący sposób:

Procedura 16.10. Przydzielanie katalogu domowego użytkownikowi za pomocą konsoli AD Użytkownicy i komputery (AD Users and Computers)

1. Uruchom konsolę AD Użytkownicy i komputery (AD Users and Computers) i rozszerz drzewo do miejsca, w którym zapisane są obiekty użytkowników.

2. Kliknij dwukrotnie obiekt użytkownika, aby uruchomić okno Właściwości (Properties).

3. Wybierz zakładkę Profil (Profile). (Rys. 16.5).

Rys. 16.5 Zakładka Profil (Profile) w oknie Właściwości użytkownika (User Properties) konsoli AD użytkownicy i komputery (AD Users and Computers) przedstawiająca ustawienia dotyczące katalogu domowego.

4. W polu Folder domowy (Home Folder) wybierz pole opcji Połącz (Connect).

5. Wpisz symbol dysku, który ma być dyskiem domowym i ścieżkę UNC do katalogu domowego.

6. Naciśnij OK, aby zapisać wprowadzone zmiany i zamknąć okno Właściwości (Properties). System automatycznie stworzy katalog domowy w podanym katalogu udostępnionym. Listy ACL zostaną zmodyfikowane w ten sposób, by użytkownik i grupa Administrators mieli uprawnienia Full Control.

Tworzenie katalogów domowych za pomocą wiersza poleceń

Poniżej opisano ogólne zasady przydzielania użytkownikowi katalogu domowego z wykorzystaniem wiersza poleceń:

Procedura 16.11. Ogólne zasady przydzielania użytkownikom katalogów domowych za pomocą wiersza poleceń

1. Wyznacz serwer, który będzie serwerem macierzystym katalogów domowych.

2. Utwórz i udostępnij folder w woluminie NTFS.

3. Utwórz konta użytkowników.

4. Utwórz katalogi domowe.

5. Ustaw prawa dostępu do katalogów.

Większość narzędzi potrzebnych do wykonania powyższych zadań --> jest razem z systemem [Author:UP] Windows 2000. Kilka narzędzi znajduje się w Resource Kit.

Kolejna procedura prezentuje sposób wykorzystania wiersza poleceń do tworzenia kont, przydzielania katalogów domowych i ustawiania praw dostępu do katalogu, tak by tylko użytkownik miał do niegodostęp.

Procedura 16.12. Przydzielanie katalogu domowego z wykorzystaniem wiersza poleceń

1. Otwórz wiersz poleceń i wpisz następujące polecenie tworzące konto użytkownika:

net user rmanuel * /add /fullname:”Rita Manuel” /comment:”Help Desk Admin” /domain

Znak * powoduje, że program Net poprosi o podanie i potwierdzenie hasła.

Parametr /domain oznacza, że użytkownik będzie obsługiwany przez Active Directory. W przeciwnym razie, gdyby polecenie to było wprowadzone w serwerze członkowskim (member server) lub stacji roboczej (workstation), a nie w kontrolerze domeny (domain controller), polecenie net user /add utworzy konto w lokalnej bazie SAM.

2. Utwórz katalog domowy dla Rity. Można to zrobić z konsoli serwera lub poprzez sieć.

MD e:\users\rmanuel

Lub

MD \\phx-dc-01\users\rmanuel

3. Jeśli wybierzesz tworzenie oddzielnych udziałów dla katalogów domowych (home directories), na konsoli serwera utwórz udział wpisując polecenie Net Share w postaci:

net share rmanuel=c:\users\rmanuel

Do utworzenia udziału poprzez sieć użyj narzędzia z Resource Kit o nazwie Rmtshare. Składnia polecenia jest następująca:

rmtshare \\phx-dc-01\rmanuel=c:\users\rmanuel

4. Do parametrów konta Rity wpisz katalog domowy, korzystając z polecenia Net User. Domyślnym symbolem dysku domowego jest Z:. Nie ma żadnej opcji umożliwiającej zmianę symbolu napędu. Składnia jest następująca:

net user rmanuel /homedir:\\phx-dc-01\rmanuel

5. Po utworzeniu katalog domowy Rity dziedziczy prawa dostępu grupy domyślnej Everyone. Teraz należy zmienić listy ACL katalogu tak, aby prawo dostępu do niego miała tylko Rita. Do tego celu służy narzędzie do nadawania uprawnień NTFS, uruchamiane z wiersza poleceń, pod nazwą CACLS.EXE, które można wykorzystać lokalnie lub poprzez sieć. Oto postać polecenia, które daje Ricie uprawnienia Full Control i usuwa innych użytkowników z listy ACL:

cacls \\phx-dc-01\users\rmanuel /t /g rmanuel:f

Parametr /t powoduje zastosowanie zmian do danego katalogu i wszystkich katalogów i plików potomnych.

Parametr /g nadaje użytkownikowi wyszczególnione uprawnienia.

Parametr rmanuel:f nadaje prawo dostępu Full Control do konta Rity.

6. Kiedy wprowadzisz wyżej wymienione polecenie, program CACLS poprosi o potwierdzenie, a następnie zastosuje podane zmiany. Po zakończeniu pracy programu CACLS może pojawić się komunikat o błędzie „Brak dostępu” („Access Denied”), ponieważ od tej chwili Rita jest jedynym uprawnionym użytkownikiem.

7. Na zakończenie, jeśli mają być stosowane ograniczenia obszaru dysku dostępnego dla użytkownika (quota), właścicielem katalogu domowego Rity trzeba wyznaczyć Ritę. Nie można tego zrobić za pomocą narzędzi firmy Microsoft. Polecane jest zastosowanie narzędzia o nazwie chown firmy MKS Software, www.mks.com. Program ten jest również częścią zestawu demonstracyjnego usług Uniksowych Services for UNIX firmy Microsoft.

Mając do dyspozycji polecenia Net, można napisać skrypt automatyzujący dodawanie użytkowników. Poniższy przykład przedstawia prosty skrypt wsadowy, którego parametrami są identyfikator logowania użytkownika (login ID), pełna nazwa i komentarz.

md \\phx-dc-01\users\%1

net share %1=c:\users\%1 (lub rmtshare \\phx-dc-01\%1=c:\users\%1)

net user %1 * /add /domain /homedir:\\phx-dc-01\users\%1 /fullname:%2 /comment:%3

cacls \\phx-dc-01\users\%1 /t /g %1:f

chown -R rmanuel \\px-dc-01\users\rmanuel

Za pomocą narzędzi VBScript, Jscript i Perl można napisać bardziej skomplikowane skrypty do obsługi użytkowników. Osoba wykorzystująca skrypty musi mieć uprawnienia administracyjne wystarczające do tworzenia nowych kont użytkowników i modyfikowania list ACL. W Resource Kit jest narzędzie o nazwie Addusers, za pomocą którego można dodawać jednorazowo setki lub nawet tysiące użytkowników, wpisanych do pliku i oddzielonych przecinkami (coma-delimited file). Do tworzenia nowych kont i przesuwania istniejących można także wykorzystać LDIFE. Szczegóły opisano w rozdziale 9. „Zakładanie domen w systemie Windows 2000”.

Przypisywanie katalogów domowych klientom poprzednich wersji systemu Windows

Po przydzieleniu katalogu domowego użytkownikowi systemu Windows 2000 lub Windows NT, dysk domowy jest podłączany automatycznie podczas logowania.

W przypadku klientów Windows 3.1x czy Windows 9x, nie jest to prawdą. Klienty te wymagają podłączania dysku w skrypcie logowania. Najpowszechniejszym sposobem podłączania jest wykorzystanie polecenia Net Use z parametrem /home. Składnia tego polecenia jest następująca:

net use u: \\phx-dc-01\users /home

Jak to wyjaśniono poniżej, w części pod tytułem „Udostępnianie katalogów domowych”, klienty starszych wersji systemu Windows, włączając w to Windows NT, nie mogą podłączać się do katalogu w udziale (share). Polecenie Net Use w skrypcie logowania ma zawierać tylko udział, o ile nie jest to skrypt przygotowywany również dla klientów Windows 2000. Może okazać się, że opcje założeń grupowych (group policy) są lepszym sposobem rozpowszechniania skryptów Windows 2000. Więcej informacji na ten temat w podrozdziale „Korzystanie ze skryptów logowania” znajdującym się w dalszej części niniejszego rozdziału.

Jedynym sposobem ominięcia ograniczeń podłączania jest użycie w skrypcie logowania polecenia Subst zamiast polecenia Net Use. Zastępowanie symboli napędów za pomocą polecenia Subst nie jest ograniczone do udziałów (share points) i korzysta z nazw UNC. Na przykład w celu przydzielenia dysku domowego (home drive) można umieścić w skrypcie logowania polecenie Subst w następującej postaci:

subst h: \\phx-dc-01\users\%username%

Rozwiązanie to działa prawidłowo również dla klientów Windows 2000, więc można zastosować ten sam skrypt logowania dla wszystkich klientów.

Udostępnianie katalogów domowych

W systemie Windows NT występuje ograniczenie podłączania dysków (drive mapping) wyłącznie do udziałów (share point).

Na przykład, jeśli podłącza się dysk U: klienta starszej wersji systemu Windows do \\phx-dc-01\users\dletterman, podłączony zostaje udział (share) użytkownika, więc dysk U: zawiera wszystkie katalogi domowe, a nie tylko pliki użytkownika dletterman.

Był to problem administratorów Windows NT od lat. W małych sieciach można ominąć to ograniczenie, tworząc oddzielne udziały dla każdego katalogu domowego użytkownika, a następnie podłączając do nich dyski domowe (home drives). W przypadku dużej sieci nie jest to dobre rozwiązanie, ponieważ duża liczba udziałów obniża wydajność systemu i powoduje niestabilność systemu. Nie zaleca się przekraczania liczby 500 udziałów w jednym serwerze, chociaż niektórzy administratorzy umieścili 2000 udziałów w serwerze i nie zgłaszali żadnych problemów.

Można ukryć udziały przed usługą przeglądania dodając do nazwy zakończenie w postaci znaku dolara $. Na przykład jeśli fizyczny katalog zawierający katalogi domowe znajduje się w serwerze na dysku E: i ścieżka dostępu do niego to E:\Users\Dletterman to udział ma nazwę Dletterman$, a ścieżka UNC to \\phx-dc-01\dletterman$.

Znak dolara nie zapobiega przesyłaniu udziałów poprzez sieć, więc nie wolno wykorzystywać ich zamiast wykorzystywania zabezpieczeń NTFS dla katalogów domowych.

Usługi terminala i katalogi domowe

--> Niektóre zmiany w profilach użytkowników systemu Windows 2000 zostały wprowadzone w celu przystosowania usług terminala (Terminal Services), które obecnie częścią systemu.[Author:UP]

Użytkownicy usług terminalowych (Terminal Services) traktują serwer usług terminalowych (TS server) jak swoją prywatną stację roboczą. Niektóre starsze aplikacje, które zapisują informacje o konfiguracji we wspólnych folderach, nie są odpowiednie dla tego typu środowiska wielodostępnego (multiuser environment). Na przykład aplikacje Office97 zapisują szablony użytkowników w folderze C:\Program Files\Office97\Templates. Jeśli tak byłoby w środowisku Usług terminalowych (Terminal Services), to użytkownicy nadpisywaliby wzajemnie swoje szablony.

Obejściem tego problemu zalecanym przez firmę Microsoft jest zamiana domyślnych folderów wspólnych aplikacji na foldery unikatowe dla każdego użytkownika. Na przykład użytkownik JSpringer będzie zapisywał swoje szablony w folderze C:\JSpringer\Program Files\Office97\Templates zamiast w folderze C:\Program Files\Office97\Templates.

System Windows 2000 automatyzuje proces tworzenia indywidualnych folderów konfiguracji dla aplikacji. Robi to wykorzystując zestaw skryptów zapisanych w folderze \WINNT\Application Compatibility Scripts. Skrypty te pracują bez względu na to, czy użytkownik loguje się do konsoli Usług terminalowych (TS console), czy też do zwykłej konsoli.

Skrypt logowania Usług terminalowych (Terminal Services) wykorzystuje specjalną zmienną środowiska (environment variable) o nazwie %rootdrive%, która jest wstawiona na początku domyślnej lokalizacji danych. Jeśli konto użytkownika w Active Directory ma przydzielony katalog domowy, ścieżka ta jest zapisana w zmiennej %rootdrive%. Jeśli użytkownikowi nie przydzielono katalogu domowego, jeden ze skryptów logowania Usług terminalowych (Terminal Services) wykorzystuje polecenie Subst do przypisania symbolu dysku folderowi lokalnemu zamiast katalogowi domowemu.

Efekt końcowy tych działań jest taki, że dane, które są zwykle umieszczone we wspólnym katalogu, są zapisywane w katalogu domowym użytkownika.

Skrypty wykonujące opisane powyżej zadania pracują nawet wtedy,gdy serwer usług terminalowych (TS Server) nie jest używany, więc warto mieć przynajmniej ogólne pojęcie o ich działaniu. Administrator serwera usług terminalowych wykrywający usterki związane ze starszymi aplikacjami w środowisku pracy Usług terminalowych, powinien znać te skrypty szczegółowo. Dalej następuje ciąg zdarzeń, które mają miejsce, kiedy skrypty zgodności aplikacji działają w środowisku pracy Usług terminalowych (TS environment).

Skrypt Chkroot. cmd

Kiedy skrypt zgodności aplikacji jest wywoływany w trakcie wstępnego logowania, pierwszym uruchomionym skryptem jest Chkroot.cmd.

W pierwszej części skryptu zmiennym środowiska pracy nadawane są wartości, w wypadku jednoczesnego uruchomienia przez użytkownika większej liczby skryptów, a potem następuje zmiana katalogów na te, w których zapisane są skrypty zgodności.

Set _CHKROOT=PASS

cd "%SystemRoot%\Application Compatibility Scripts"

Skrypt Rootdrv.cmd sprawdza teraz, czy katalog domowy użytkownika już istnieje. Jeśli tak jest, to resztę pliku pomija się, a katalog zostanie zmieniony na %SystemRoot%\Application Compatibility Scripts\Install, by przygotować go dla kolejnych skryptów.

Call RootDrv.Cmd

If Not “A%ROOTDRIVE%A” == ”AA” Goto Cont2

W następnym podrozdziale opisano tworzenie skryptu o nazwie Rootdrv2.cmd, który nadaje symbol dysku zmiennej %rootdrive%. Skrypt ten jest wywoływany przy każdym logowaniu. Jeśli katalog domowy nie istnieje, użytkownik musi podać symbol dysku (drive letter), który będzie wartością zmiennej %rootdrive%. Skrypt zapisuje echo uwag do pliku, a następnie otwiera go za pomocą programu Notepad. Użytkownik podaje symbol dysku i zapisuje skrypt.

Echo REM > RootDrv2.Cmd

Echo REM Zanim uruchomisz ten skrypt zgodności aplikacji, musisz>> RootDrv2.Cmd

Echo REM podać symbol dysku, który jeszcze wykorzystywany>>RootDrv2.Cmd

Echo REM nie jest przez Terminal Server, aby zostać podłączonym >> RootDrv2.Cmd

Echo REM do każdego katalogu domowego użytkownika. Zaktualizuj >>RootDrv2.Cmd

Echo REM linię „Set RootDrive” na końcu tego pliku podając symbol >>RootDrv2.Cmd

Echo REM dysku. Jeśli nie masz preferencji wpisz W: Na przykład:>>RootDrv2.Cmd

Echo REM>>RootDrv2.Cmd

Echo REM Set RootDrive=W: >>RootDrv2.Cmd

Echo REM>>RootDrv2.Cmd

Echo REM Uwaga: Wpisz bez spacji po literze i dwukropku >>RootDrv2.Cmd

Echo REM>>RootDrv2.Cmd

Echo REM Po zakończeniu tego zadania, zapisz plik i zamknij >>RootDrv2.Cmd

Echo REM NotePad'a aby kontynuować działanie skryptu zgodności aplikacji>>RootDrv2.Cmd

Echo REM>>RootDrv2.Cmd

Echo. >>RootDrv2.Cmd

Echo Set RootDrive= >>RootDrv2.Cmd

Echo. >>RootDrv2.Cmd

Skrypt RootDrv2.cmd

Skrypt Chkroot.cmd otwiera plik Rootdrv2.cmd, utworzony wcześniej za pomocą programu Notepad.

NotePad RootDrv2.Cmd

Użytkownik powinien przeczytać uwagi i podać symbol dysku (drive letter). Bardziej prawdopodobne jest, że użytkownik przeczyta tekst i zadzwoni do działu pomocy technicznej. Domyślną wartością zmiennej %rotdrive% jest W:. Jeśli dysk W: jest już używany, należy zmodyfikować skrypt ChkRoot w serwerze Usług terminalowych (Terminal Services server), w ten sposób, by podpowiadał prawidłową literę. Ograniczy to liczbę wezwań pomocy.

Skrypt Rootdrv.cmd

Kiedy użytkownik zapisze plik ROOTDRV.CMD i zamknie Notepad-a, skrypt Chkroot.cmd wywołuje utworzony skrypt Rootdrv.cmd. Jeśli użytkownik zignoruje podanie symbolu --> dysku dla tego skryptu, zostanie wyświetlony odpowiedni komunikat i skrypt zakończy pracę.[Author:E]

Call RootDrv.Cmd

If Not “A%ROOTDRIVE%A” == “AA” Goto Cont1

Echo.

Echo Przed uruchomieniem tego skryptu zgodności aplikacji, musisz

Echo przypisać literę dysku do każdego katalogu domowego

Echo użytkownika

Echo.

Echo Script terminated.

Echo.

Pause

Set _CHKROOT=FAIL

Goto Cont2

Skrypt przechodzi bezpośrednio do poniższej etykiety, jeśli użytkownik ma katalog domowy (home directory) lub przydzielono mu jakiś katalog za pomocą skryptu Rootdrv2.cmd. W tej części skryptu tworzony jest plik o nazwie CHKROOT.KEY.

:Cont1

Echo HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server > chkroot.key

Echo RootDrive=REG_SZ %ROOTDRIVE%>> chkroot.key

Plik CHKROOT.KEY jest argumentem programu Regini przy tworzeniu w Rejestrze związanego z nim klucza:

regini chkroot.key > Nul:

Zawartość skryptu UsrLogon jest omówiona bardziej szczegółowo w dalszej części niniejszego rozdziału.

Call “%SystemRoot%\System32\UsrLogon.Cmd

Zakończenie (exit point) skryptu pozostawia użytkownika w katalogu zawierającym skrypty zgodności aplikacji (application compatibility scripts).

:Cont2

Cd “%SystemRoot%\Application Compatibility Scripts\Install”

Funkcja skryptu Usrlogon.cmd

Skrypt Usrlogon.cmd nadaje wartość zmiennej środowiskowej %rootdrive% przy każdym logowaniu. Plik znajduje się w katalogu \WINNT\System32 i jest uruchamiany automatycznie w trakcie logowania niezależnie od tego, czy użytkownik loguje się korzystając z Usług terminalowych (Terminal Services), czy w sposób standardowy.

Poniższa pozycja Rejestru dla WINLOGON powoduje uruchomienie skryptu Usrlogon:

Key: HKLM|Software|Microsoft|Windows NT|CurrentVersion|Winlogon

Value: AppSetup

Data: UsrLogon.Cmd (REG_SZ)

Skrypt UsrLogon.cmd wykonuje różnorodne zadania określenia środowiska pracy użytkownika za pomocą Usług terminalowych (Terminal Services). Poniżej opisano skrypt przykładowy.

@Echo Off

Skrypt Setpath zawiera szereg zmiennych środowiskowych (environment variables), obsługujących wielodostępny system Windows.

Call “%SystemRoot%\Application Compatibility Scripts\SetPaths.Cmd”

If “%_SETPATHS%” == “FAIL” Goto Done

W następnym fragmencie skryptu wywoływany jest skrypt o nazwie Usrlogn1.cmd. Skrypt ten nie jest tworzony domyślnie. Skrypty zgodności aplikacji (application compatibility scripts) tworzą ten plik, jeżeli potrzebne są specjalne procedury oprócz zmiennej %rootdrive%. Przykładem może być aplikacja Peach Tree, która do poprawnego działania musi załadować Btrieve, ale nie zapisuje danych w domyślnym katalogu danych.

If Not Exist “%SystemRoot%\System32\Usrlogn1.cmd' Goto cont0

Cd /d “%SystemRoot%\Application Compatibility Scripts\Logon”

Call “%SystemRoot%\System32\Usrlogn1.cmd”

Skrypt Rootdrv.cmd jedynie wywołuje skrypt Rootdrv2.cmd, który nadaje wartość zmiennej %rootdrive%.

:cont0

Cd /d %SystemRoot%\”Application Compatibility Scripts”

Call RootDrv.Cmd

If “A%RootDrive%A” == “AA” End.Cmd

Na tym etapie sprawdzono, czy użytkownik ma prawdziwy symbol dysku (drive letter), na którym jest katalog domowy, a nie zastępczy symbol dysku przydzielony przez skrypt Rootdrv2.cmd. Kilka kolejnych linii skryptu powoduje usunięcie wszystkich dotychczasowych zastosowań tej litery dysku (drive letter), a następnie przydziela go korzystając z polecenia Subst, zamiast Net Use. W ten sposób system widzi go jako dysk lokalny.

Net Use %RootDrive% /D >NUL: 2>&1

Subst %RootDrive% “%HomeDrive%%HomePath%”

If ERRORLEVEL 0 goto AfterSubst

Subst %RootDrive% /d >NUL: 2>&1

Subst %RootDrive% “%HomeDrive%%HomePath”

Niektóre skrypty zgodności aplikacji (application compatibility scripts) po utworzeniu %rootdrive% muszą mieć podane dodatkowe parametry, co zapisano w skrypcie Usrlogn2.cmd. Jeśli ten skrypt istnieje, zostaje w tym punkcie uruchomiony.

:AfterSubst

If Not Exist %SystemRoot%\System32\Usrlogn2.Cmd Goto Cont1

Cd Logon

Call %SystemRoot%System32\UsrLogn2.Cmd

W zakończeniu skryptu (exit point) nie ma dodatkowego przetwarzania.

:Cont1

:Done

Skrypt Setpath.cmd

Skrypt Setpath.cmd wywoływany przez Userlogon.cmd nadaje wartości szeregowi zmiennych środowiskowych, wskazujących nową lokalizację foldera. W tym celu wykorzystuje skrypt dający się zmieniać, Getpath.cmd tworzony przy logowaniu się na podstawie pozycji Rejestru. Poniżej zamieszczono przykładowy skrypt Getpath.cmd użytkownika logującego się jako phxadmin:

SET COMMON_START_MENU=C:\Documents and Settings\All Users\Start Menu

SET COMMON_START_UP=C:\Documents and Settings\All Users\Start Menu\Programs\Startup

SET COMMON_PROGRAMS=C:\Documents and Settings\All Users\Start Menu\Programs

SET USER_START_MENU=C:\Documents and Settings\phxadmin\Start Menu

SET USER_STARTUP=C:\Documents and Settings\phxadmin\Start Menu\Programs\Startup

SET USER_PROGRAMS=C:\Documents and Settings\phxadmin\Start Menu\Programs

SET MY_DOCUMENTS=My Documents

SET TEMPLATES=Templates

SET APP_DATA=Application Data

Skrypty te uruchamiane są w każdym komputerze z systemem Windows 2000, nie tylko w przypadku logowania się do Usług terminalowych (Terminal Services). Nie mają wpływu na użytkowników nie korzystających z Usług terminalowych (Terminal Services), ale należy o nich pamiętać do celów wykrywania usterek.

Teraz, kiedy profile użytkowników i katalogi domowe są już skonfigurowane, przyszła pora na omówienie w jaki sposób je kontrolować jak najmniejszym nakładem pracy. Ponieważ profile zawierają pozycje Rejestru i pliki INI umieszczone w oddzielnych folderach, metody kontrolowania muszą uwzględniać sposoby modyfikowania wszystkich tych elementów. Jest to zadanie dla założeń systemowych dotyczących grup (group policies).

Zarządzanie środowiskami pracy użytkowników za pomocą założeń grupowych (group policies)

Idea wykorzystania założeń systemowych do zarządzania środowiskiem pracy została wprowadzona w systemie Windows 95 i od tego czasu jest stemplem probierczym (hallmark) zarządzania środowiskiem pracy Eksploratora.

Systemy Windows 9x i Windows NT do wykonywania podstawowych zmian konfiguracji komputera wykorzystują znane już założenia systemowe (system policies). Założenia te mają kilka ograniczeń.

• Pliki założeń systemowych są zapisane w postaci binarnej, są dość duże i dokonują niepotrzebnych zmian, co bardzo ogranicza zakres dostępnych założeń.

• Niektóre z założeń systemowych mają nieprzyjemny zwyczaj pozostawania w serwerze po usunięciu z niego założeń. Firma Microsoft określa to zjawisko jako „tatuowanie Rejestru” (tattooing the Registry). Każdy z administratorów, który dokonał nieodwracalnych zmian konfiguracji systemu dla 5000 użytkowników nieumiejętnie obchodząc się z Edytorem Rejestru, wie jak trudne jest usunięcie „tatuażu”.

• Założenia systemowe (System Policies) aktualizują tylko Rejestr. Jeśli jakaś zmiana środowiska pracy wykracza poza dokonanie zmian w Rejestrze, administrator musi w tym celu napisać specjalny skrypt.

• Założenia systemowe (system policies) mogą być rozpowszechniane tylko w jednym pliku. Przeszkadza to administratorom w tworzeniu założeń dostosowanych do konkretnych zespołów użytkowników. Założenia systemowe (system policies) mogą być przeznaczone dla grup, ale wtedy tworzone są bardzo duże pliki CONFIG.POL lub NTCONFIG.POL, trudne do konserwacji.

W systemie Windows 2000 usunięto te niedostatki wprowadzając nową metodę dystrybucji założeń o nazwie założenia grupowe (group policies). Założenia grupowe (group policies) dotyczą również pozycji Rejestru, ale zmieniają się tylko ustawienia Rejestru w pamięci, a nie dokonuje się trwałych zmian w plikach Rejestru innych niż do buforowania założeń (policies). Po usunięciu założenia grupowego przywracane są pierwotne pozycje Rejestru.

Zestaw funkcji założeń grupowych (group policies) daje dużo więcej możliwości niż proste modyfikacje pozycji Rejestru. Założenia grupowe (group policies) dzielą się na kilka kategorii, zależnie od elementów konfiguracji, na które mają wpływ. Kategorie te są następujące:

• Założenia nakładania ograniczeń obszaru dysku dostępnego dla poszczególnych użytkowników (Disk Quota policies)

• Założenia odzyskiwania szyfrowania systemu plików (Encrypting File System Recovery policies)

• Założenia bezpieczeństwa

• Założenia dotyczące użytkowników i komputerów (modyfikacje Rejestru)

• Założenia przekierowywania folderów (Folder Redirection)

• Skrypty logowania/wylogowywania

• Instalowanie oprogramowania

Pierwsze trzy kategorie opisano w poprzednich rozdziałach. Instalowanie oprogramowania wykracza poza zakres niniejszej książki. Założenia dotyczące użytkowników i komputerów opisano w bieżącym podrozdziale. Przekierowywanie folderów (Folder Redirection) i skrypty logowania/wylogowywania omówiono w dalszej części niniejszego rozdziału.

Porównanie założeń systemowych (system policies) i założeń grupowych (group policies)

Obsługa założeń systemowych poprzednich wersji systemu Windows w systemie Windows 2000

System Windows 2000 nadal obsługuje klienty, korzystające z założeń zapisanych w pliku CONFIG.POL (Windows 9x) lub pliku NTCONFIG.POL (Windows NT 4).

• Kontrolery domen w systemach Windows 9x i Windows NT zapisują pliki założeń w katalogu \WINNT\System32\Repl\Import\Scripts, który jest udostępniony jako NETLOGON.

• Kontrolery domen w systemie Windows 2000 również wykorzystują udział NETLOGON, ale odpowiadającym mu folderem jest \WINNT\Sysvol\Sysvol\<nazwa_domeny>\Scripts.

Klasycznym narzędziem tworzenia założeń systemowych jest Edytor założeń systemowych (System Policy Editor), Poledit. Narzędzie to wykorzystuje zestaw plików szablonów ADM, zawierających modyfikacje Rejestru dla poszczególnych założeń. System Windows 2000 zawiera kopię edytora Poledit i pełny zestaw szablonów, wykorzystywanych do zarządzania klientami poprzednich wersji systemu Windows.

Opis funkcji założeń grupowych dotyczących użytkowników i komputerów (User and Computer Group Policies)

Założenia grupowe dotyczące użytkowników i komputerów składają się z aktualizacji Rejestru rozsyłanych do klientów domeny przy logowaniu. Modyfikacje te zapisane są w specjalnych plikach REGISTRY.POL. Każde z założeń zawiera dwa pliki REGISTRY.POL: w jednym zapisane są ustawienia konfiguracji Użytkownika, w drugim ustawienia konfiguracji Komputera.

Modyfikacje Rejestru zapisane w plikach REGISTRY.POL są pobierane przez klienty i stosowane do pozycji Rejestru w pamięci. Nie dokonuje się trwałych zmian Rejestrów lokalnych innych do buforowania ustawień. Po usunięciu założenia grupowego przywracane są pierwotne ustawienia Rejestru.

Zwróćmy uwagę na rysunek 16.6. Założenia grupowe (group policies) są zapisane w kontrolerach domen w folderze \WINNT\Sysvol<domena>. Zawartość tego foldera podlega replikacji w całej domenie. Komputery lokalne również mają założenia wpływające na ustawienia lokalnego Rejestru, zapisane w folderze \WINNT\System32\GroupPolicy.

Każde z założeń grupowych (group policy) w folderze \WINNT\Sysvol składa się z zestawu folderów zapisanych w folderze o nazwie dopasowanej do identyfikatora unikatowego globalnie (Globally Unique Identifier — GUID) tego założenia. Jest to Obiekt założenia grupowe (Group Policy Object — GPO).

Kontener Założenia grupowe (Group Policy container — GPC) reprezentuje w Active Directory każdy z obiektów założeń grupowych (Group Policy Object) foldera \WINNT\Sysvol. Kontenery założeń grupowych są następnie łączone z kontenerami Active Directory. Kiedy założenie grupowe jest połączone z kontenerem, składniki założenia (policy) — modyfikacje Rejestru, skrypty logowania/wylogowywania, przekierowywanie folderów (folder redirection) itd. — są pobierane przez użytkowników i komputery, które są przedstawione za pomocą obiektów w tym kontenerze.

--> Group Policy Object — Obiekt założenia grupowe

Group Policy Container — Kontener Założenia grupowe

Site — Lokacja

Domain — Domena

Local Policies — Założenia lokalne

Organizational Unit — Jednostka organizacyjna

Rysunek 16.6. Schemat relacji pomiędzy Obiektami Założenia grupowe, Kontenerami Założenia grupowe i Kontenerami Active Directory.[Author:E]

Jeśli użytkownik w jednostce organizacyjnej (Organizational Unit — OU) loguje się do domeny, pobierane są założenia grupowe (group policies) z Siedziby (Site), Domeny i lokalnych jednostek organizacyjnych. Modyfikacje Rejestru zapisane w plikach REGISTRY.POL tych założeń są łączone z tymi w lokalnych założeniach i zastosowane do ustawień Rejestru w kluczu HKEY_Current_User, które są zapisane w pamięci. Hierarchia określająca pierwszeństwo modyfikacji jest opisana w podrozdziale „Hierarchia Założeń grupowych” w dalszej części niniejszego rozdziału.

Założenia grupowe (group policies) są konfigurowane i zarządzane za pomocą konsoli Założenia grupowe (Group Console). Przykład okna konsoli przedstawiono na rys.16.7.

Rysunek 16.7. Konsola Założenia grupowe (Group Policy), przedstawiająca założenia grupowe oddziałujące na użytkowników.

Inaczej, niż w przypadku innych narzędzi administracyjnych Windows 2000, wśród Narzędzi Administracyjnych (Administrative Tools) nie ma konsoli Założenia grupowe (Group Policy) ogólnego przeznaczenia. Dostępna jest konsola Założenia lokalnego bezpieczeństwa (Local Security Policy), ale wykorzystuje podzbiór założeń systemowych, dobranych specjalnie pod kątem bezpieczeństwa. Szczegółowe informacje podano w rozdziale 6. „Bezpieczeństwo dostępu do sieci i protokół Kerberos”.

Poprzez okno Właściwości (Properties) kontenera Active Directory, połączone z założeniami, można uruchomić wtyczkę (snap-in) założeń grupowych. Dostęp do założeń lokacji (Sit policies) jest poprzez konsolę AD Lokacje i usługi (AD Sites and Services). Założenia domeny i jednostki organizacyjnej są dostępne poprzez konsolę AD Użytkownicy i komputery (AD Users and Computers). Założenia lokalne są dostępne za pomocą konsoli Edytora założeń grupowych (Group Policy Editor — GPE), Gpedit.msc, wywoływanej z okna Uruchom (Run) lub z wiersza poleceń. Konsola ta nie znalazła się w menu Narzędzia administracyjne (Administrative Tools) z tych samych powodów, dla których nie podano dwóch Edytorów Rejestru (Registry Editor). Jeśli dostaną się w niepowołane ręce, mogą sprawiać kłopoty.

Edytor założeń grupowych (Group Policy Editor) przy tworzeniu zawartości pliku REGISTRY.POL, związanej z każdym założeniem, polega na szablonach (templates). Szablony te są podobne do klasycznych szablonów Założeń systemowych (System policy), ale zawierają więcej opcji. Szablony są zapisane w plikach ADM w katalogu \WINNT\INF. (W tym przypadku \WINNT jest to %systemroot%.)

Kiedy klienty pobierają założenia, poszczególne pozycje w plikach założeń są stosowane do lokalnych plików konfiguracji przy użyciu rozszerzeń zakresu funkcji klienta (client-side extensions). Przyjmują one postać bibliotek DLL. Na przykład program rozszerzający klienta, obsługujący modyfikacje Rejestru na podstawie założeń grupowych (group policies) to USERENV.DLL.

Na zakończenie w szeregu kluczy lokalnego Rejestru zapisuje się informacje do zarządzania założeniami grupowymi i bufor lokalny aktualizacji założeń, używany jeśli domena jest niedostępna.

Jako podsumowanie przedstawiono składniki założeń grupowych dotyczących użytkowników i komputerów:

• --> Foldery \WINNT\Sysvol podlegające [Author:E] replikacji pomiędzy kontrolerami domeny

• Obiekty Założeń grupowych (Group Policy Objects) w folderze Sysvol zawierające pliki założeń

• Obiekty Kontener założeń grupowych (Group Policy Container) w Active Directory, wskazujące na obiekty założeń grupowych

• Kontenery Jednostek organizacyjnych, domen i siedziby (site), które mają założenia systemowe połączone z nimi

• Pliki REGISTRY.POL, zawierające aktualizacje Rejestru, które odnoszą się do pozycji lokalnego Rejestru w pamięci klientów

• Wtyczka (snap-in) Założenia grupowe (Group Policy snap-in) do konfigurowania i zarządzania założeniami grupowymi

• Szablony administracyjne (pliki ADM) zawierające pozycje REGISTRY.POL odnoszące się do każdego z założeń (policy)

• Rozszerzenia zbioru funkcji klienta (client-side extensions) przetwarzające założenia (policies) lokalnie i stosujące je do odpowiednich plików konfiguracji

• Lokalne pliki Rejestru, zawierające parametry kontrolujące sposób wykorzystywania i zapisywania założeń grupowych (group policies).

W pozostałych podrozdziałach omówiono szczegóły dotyczące powyższych elementów i ich wzajemnego oddziaływania.

Ostrożnie z modyfikowaniem założeń w działających systemach

Eksperymentując z założeniami grupowymi (group policies) w działających systemach trzeba mieć świadomość, że zmiany dokonane za pomocą Edytora założeń grupowych (Group Policy Editor) wpisywane są do plików REGISTRY.POL bezpośrednio po naciśnięciu przycisku OK. W odróżnieniu od Edytora założeń (Policy Editor), nie ma opcji „zapisz ustawienia” („save settings”). Po wprowadzeniu zmiany klient może otrzymać jej kopię w trakcie okresowego odświeżania kilka sekund później.

Budowa foldera Sysvol

Kontrolery domeny zapisują obiekty założeń grupowych w folderze \WINNT\Sysvol. Budowę tego foldera przedstawiono na rysunku 16.8.

Rysunek 16.8. Budowa katalogu i plików w katalogu \WINNT\Sysvol.

Na replikację założeń grupowych i pobieranie klientów mają wpływ następujące składniki:

• Folder \WINNT nie musi być tym samym, co %systemroot%. Administrator w trakcie awansowania komputera na kontrolera domeny wybiera lokalizację Sysvol. Folder musi znajdować się w woluminie NTFS5.

• Folder \WINNT\Sysvol\Domain podlega replikacji pomiędzy wszystkie kontrolery domeny w danej domenie.

• Dwa foldery Company.com w rzeczywistości nie są folderami. Są to dynamiczne wskaźniki lokalizacji danych (reparse points), które dołączają się z powrotem (mount back) do folderów w \WINNT\Sysvol\Domain. \WINNT\Sysvol\Sysvol\Company.com dołącza się do \WINNT\Sysvol\Domain. \WINNT\Sysvol\Staging Areas\Company.com dołącza się do \WINNT\Sysvol\Staging\Domain.

Wskaźniki te są przyczyną, dla której folder \WINNT\Sysvol musi znajdować się w woluminie NTFS5.

• Katalog \WINNT\Sysvol\Sysvol jest udostępniony jako SYSVOL. Klienty Windows 2000 uzyskują dostęp do folderów założeń grupowych poprzez ten udział (share).

• Klienty mają dostęp do udziału SYSVOL w serwerze, który dokonuje identyfikacji. Z tej przyczyny musi być wykonana replikacja folderów do wszystkich kontrolerów domeny.

• Każdy z obiektów założeń grupowych ma przydzielony oddzielny folder o nazwie zgodnej z identyfikatorem GUID założeń. Budowa tego obiektu GPO jest opisana w kolejnym podrozdziale.

Budowa obiektu założeń grupowych (Group Policy Object)

Rysunek 16.9 przedstawia budowę folderu przykładowego obiektu założeń grupowych (group policy object). System śledzi lokalizację obiektów założeń grupowych (GPO) na podstawie identyfikatora GUID najwyższego foldera, więc nie należy zmieniać jego nazwy.

Rysunek 16.9. Budowa foldera dla założeń grupowych (group policy) zapisanych w \WINNT\Sysvol\Domain

Większość folderów założeń nie ma tak szeroko rozgałęzionych podfolderów, jak ten z rysunku 16.9. Jeśli jest tylko kilka założeń (policies) przydzielonych lokalnym użytkownikom, a żadnego dla komputerów, folder założeń zawiera jeden aktywny element, plik REGISTRY.POL z aktualizacją Rejestru użytkownika.

Każdy z folderów założeń grupowych (group policy) zawiera następujące trzy elementy:

• Plik REGISTRY.POL. Plik ten zawiera aktualizacje Rejestru pobierane przez klienta i stosowane do pozycji lokalnego Rejestru zapisanego w pamięci. Jeśli założenia są przydzielone użytkownikom i komputerom (Users and Computers), każdy z zestawów założeń jest zapisany w swoim własnym pliku REGISTRY.POL.

• Folder ADM. Folder ten zawiera kopię szablonów administracyjnych (plik ADM) wykorzystywanych do generowania pozycji plików REGISTRY.POL. Szablony te są kopiowane z głównych szablonów z foldera \WINNT\INF kontrolera domeny, w którym dokonuje się aktualizacji założeń.

• Folder użytkownika. Folder ten zawiera założenia wprowadzane do pozycji Rejestru HKEY_Current_User podczas logowania się użytkownika.

• Folder komputera. Folder ten zwiera założenia wprowadzane do pozycji Rejestru HKEY_Local_Machine podczas logowania się komputera.

Budowa kontenera założeń grupowych (Group Policy Container)

Active Directory przechowuje lokalizację i informacje o konfiguracji obiektów założeń grupowych w szeregu obiektów pod nazwą Kontener założeń grupowych (Group Policy Container — GPC) pod nazwą cn=Policies, cn=System, cn=Configuration, dc=domain, dc=root.

Każdy z obiektów GPC reprezentuje jakieś założenie. Nazwa ogólna (common name — CN) obiektu GPC jest identyfikatorem GUID zgodnym z identyfikatorem GUID związanego z nim obiektu założeń grupowych z foldera \WINNT\SYSVOL\Domain. Rysunek 16.10 przedstawia lokalizacje kontenerów GPC w Active Directory.

Rysunek 16.10 Konsola AD Użytkownicy i komputery (AD Users and Computers), przedstawiająca lokalizacje obiektów założeń.

Obiekt GPC zawiera cztery atrybuty wykorzystywane do obsługi założeń. Można je obejrzeć za pomocą edytora ADSI z Resource Kit. Tymi atrybutami są:

• GPC-File-Sys-Path. Atrybut ten zawiera ścieżkę UNC założeń wykorzystujących domenę jako część główną ścieżki, która jest określana jako ścieżka odporna na błędy (fault-tolerant path). Na przykład ścieżka odporna na błędy (fault-tolerant path) do założeń w domenie Company.com jest następująca:

\\company.com\sysvol\company.com\policies\{policy-GUID}

• GPCFunctionalityVersion. Atrybut ten zawiera liczbę całkowitą, reprezentującą wersję Edytora założeń grupowych (Group Policy Editor), za pomocą którego utworzono założenia.

• GPC-Machine-Extension-Names i GPC-User-Extension-Names. Te dwa atrybuty zawierają identyfikatory GUID rozszerzeń zakresu funkcji klienta (client-side extensions) obsługujących założenia dotyczące użytkowników i komputerów. Szczegóły zawarto w podrozdziale „Rozszerzenia zakresu funkcji klienta” („Client-side extensions”).

Połączenia jednostek organizacyjnych, domen i lokacji (site)

Obiekty GPC reprezentują połowę połączenia pomiędzy kontenerami Jednostka organizacyjna (OU), Domena i Lokacja (Site) do obiektów GPO na dysku. Drugą połową jest atrybut GPLink w obiektach Jednostka organizacyjna (OU), Domena i Lokacja (Site). Atrybut GPLink zawiera nazwę wyróżnioną (distinguished name) obiektu GPC połączonego z kontenerem Active Directory. Nazwa ogólna (common name — CN), która jest składnikiem nazwy wyróżnionej (distinguished name), jest identyfikatorem GUID założeń (policy).

Obiekt GPC może być połączony z wieloma kontenerami. Na przykład mogą istnieć założenia systemowe o nazwie Użytkownik standardowy (Standard User), wybierane przez wielu administratorów do łączenia z ich Jednostkami organizacyjnymi (OU).

Na tej samej zasadzie kontener Active Directory może być połączony do wielu obiektów GPC. Na przykład mogą istnieć założenia oddzielnie dla przekierowywania folderów (folder redirections), skryptów logowania/wylogowywania, konfiguracji Użytkowników i komputerów i ustawień bezpieczeństwa.

Replikacja założeń (policy replication)

Zanim wyliczanie elementów założeń grupowych (group policy) będzie kontynuowane, nastąpi przerwa na omówienie replikacji założeń.

Agent replikacji katalogu (Directory Replication Agent — DRA) wykonuje replikację obiektów GPC w Active Directory pomiędzy kontrolerami domeny. Usługa replikacji plików (File Replication Service — FRS) wykonuje replikację foldera \WINNT\Sysvol\Domain pomiędzy kontrolerami domeny.

Usługa replikacji plików FRS nie współpracuje z agentem replikacji katalogu (DRA), więc przez pewien czas może wystąpić stan, w którym obiekty GPC i GPO nie będą zsynchronizowane, szczególnie jeśli nastąpiła replikacja pomiędzy lokacjami (sites). W trakcie aktualizacji założeń, jeśli przez dłuższy czas obiekty GPC i GPO są niedostępne, można wykorzystać Monitor replikacji (Replication Monitor) i wymusić replikację. Szczegóły zamieszczono w rozdziale 11. „Zarządzanie replikacją Active Directory i konserwacją katalogu”.

Przyczyną problemów może być jeszcze jedna różnica w wykonywaniu replikacji pomiędzy agentem replikacji katalogu DRA a usługą replikacji plików FRS. Agent replikacji katalogu DRA może wykorzystać protokół SMTP (Simple Mail Transport Protocol) do wysyłania aktualizacji Active Directory do oddalonych lokacji (sites) poprzez łącza asynchroniczne (linie telefoniczne lub ISDN). Usługa replikacji plików FRS nie obsługuje replikacji za pomocą protokołu SMTP. Jeśli istnieją oddalone lokacje (sites), połączone poprzez linię telefoniczną (dial-up lines), wykorzystujące protokół SMTP do aktualizacji Active Directory, to kontroler domeny w tej lokacji (site) nie otrzyma kopii założeń grupowych (group policies) z innych kontrolerów domen. Gdyby w tym miejscu miały być zastosowane założenia grupowe (group policies), trzeba utworzyć założenia (policy) w tym kontrolerze domeny (można to zrobić poprzez sieć), a następnie połączyć te założenia do lokacji (site).

Jeśli replikacja nie powiedzie się, w dzienniku zdarzeń replikacji plików (File Replication Log) znajdzie się wpis dotyczący problemów, które wystąpiły w trakcie replikacji oraz możliwe przyczyny. Wpisy te mogą być trochę niejasne, ale przynajmniej mogą służyć jako punkt startowy do wykrywania usterek.

Pliki REGISTRY.POL

W tym podrozdziale nastąpi powrót do omawiania elementów założeń. Założenia Użytkowników i komputerów składają się z aktualizacji Rejestru rozprowadzanych w postaci plików REGISTRY.POL. Każdy obiekt GPO ma dwa pliki REGISTRY.POL: jeden dla ustawień konfiguracji użytkownika (User Configuration Settings), a drugi dla ustawień konfiguracji komputera (Computer Configuration Settings). Pliki REGISTRY.POL są umieszczone w odpowiednich folderach Sysvol.

Każdy z wyborów założeń użytkowników i komputerów dokonywanych za pomocą Edytora założeń grupowych (Group Policy Editor) wpływa na przynajmniej jedną pozycję Rejestru. Na przykład założenie (policy) Uaktywnij powłokę standardową (Enable Classic Shell) modyfikuje wartość pozycji HKCU|Software|Microsoft|Windows|CurrentVersion|Policies|Explorer|ClassicShell.

Przy wybieraniu założenia Edytor założeń grupowych (Group Policy Editor) podaje następujące opcje:

• Uaktywniony (Enabled). Opcja ta oznacza, że wartość związana z założeniem (policy) jest stosowana do zmiany ustawienia Rejestru. Jeśli założenie (policy) Uaktywnij powłokę standardową (Enable Classic Shell) ma wartość Uaktywniona (Enabled), to odpowiednia pozycja pliku REGISTRY.POL ustawia HKCU|Software|Microsoft|Windows|CurrentVersion|Policies|Explorer|ClassicShell na 1. Użytkownik ma tylko dostęp do powłoki standardowej bez możliwości wyboru powłoki internetowej.

• Zablokowany (Disabled). Opcja ta oznacza, że wartość związana z założeniem (policy) jest usuwana z Rejestru. Jeśli założenie (policy) Uaktywnij powłokę standardową (Enable Classic Shell) ma wartość Zablokowany (Disabled), to zależnie od zdefiniowanego w szablonie działania odpowiednia pozycja pliku REGISTRY.POL ustawia HKCU|Software|Microsoft|Windows|CurrentVersion|Policies|Explorer|ClassicShell na 0 lub całkowicie usuwa daną pozycję. Tak czy inaczej brak blokady jest zezwoleniem, więc zostanie przywrócona użytkownikowi możliwość wyboru pulpitu w postaci strony internetowej (Web-enabled desktop).

• Nie skonfigurowano (Not configured). Nie stosuje się żadnych zewnętrznych założeń (policy). Jeśli założenie (policy) Uaktywnij powłokę standardową (Enable Classic Shell) ma wartość Nie skonfigurowano (Not Configured), to plik REGISTRY.POL nie zawiera pozycji dotyczących wartości HKCU|Software|Microsoft|Windows|CurrentVersion|Policies|Explorer|ClassicShell.

Budowa pliku REGISTRY.POL

Plik REGISTRY.POL jest plikiem tekstowym w standardzie Unicode, mającym nagłówek i tekst podstawowy.

• Nagłówek zawiera sygnaturę pliku Rejestru i numer wersji Edytora założeń grupowych (Group Policy Editor), za pomocą którego został utworzony.

• Tekst podstawowy zawiera szereg pozycji oddzielonych średnikami, które zawierają aktualizacje Rejestru w postaci: [Key; Value; Type; Size; Data].

Taki sposób zapisywania aktualizacji Rejestru upakowuje wiele pozycji w małym pliku. Stanowi to również o elastyczności systemu w zakresie stosowania aktualizacji, ponieważ pozycje pliku REGISTRY.POL mogą być z różnych źródeł łatwo łączone.

Aktualizacje Rejestru zawarte w plikach REGISTRY.POL nakładają się na istniejące pozycje Rejestru. Nie zamazują ich na dobre. Na przykład weźmy pod uwagę pozycję Rejestru HKCU|Software|Microsoft|Windows|CurrentVersion|Explorer|Policies|NoDesktop, która steruje wyświetlaniem użytkownikowi ikon na Pulpicie (Desktop). Założenie grupowe (group policy) o nazwie Ukryj wszystkie ikony na Pulpicie (Hide All Icons On Desktop) wpisuje wartość do wyżej wymienionej pozycji Rejestru. Oto fragment pliku REGISTRY.POL uaktywniający funkcję NoDesktop:

PReg

[Software\Microsoft\Windows\CurrentVersion\Policies\Explorer ; NoDesktop; 4 ; 4 ; 1]

Kiedy plik REGISTRY.POL zawierający taką pozycję zostanie pobrany , specjalny proces o nazwie Userenv aktualizuje klucze Rejestru w pamięci, ale nie nadpisuje gałęzi Rejestru zapisanych na dysku.

Jeśli założenie (policy) Ukryj wszystkie ikony na Pulpicie (Hide All Icons On Desktop) zostanie później zmienione, aby zablokować funkcję NoDesktop, odpowiednia pozycja pliku REGISTRY.POL wygląda następująco:

PReg

[Software\Microsoft\Windows\CurrentVersion\Policies\Explorer ; **del NoDesktop; 1 ; 4 ; 20 ]

<<Znaki ** to znacznik działania (action flag). Działania, oprócz innych, obejmują **DeleteKeys i **SecureKey.>>

W większości przypadków znajomość budowy plików REGISTRY.POL nie jest konieczna. Zmian można dokonywać za pośrednictwem Edytora założeń grupowych (Group Policy Editor), ufając, że cokolwiek zostanie wybrane, na lepsze czy na gorsze, zostanie przesłane do wybranych klientów sieci.

Po zmodyfikowaniu szablonu lub utworzeniu nowego szablonu, aby zastosować założenie nie będące częścią standardowej listy, dobrym pomysłem jest sprawdzenie efektów pracy analizując zawartość pliku REGISTRY.POL, który wysyłają nowo utworzone założenia. Jest to ostateczne sprawdzenie, czy zostanie zrobione to, co miało być zrobione. Więcej informacji zamieszczono w podrozdziale „Modyfikowanie szablonów ADM” w dalszej części niniejszego rozdziału.

Hierarchia założeń grupowych (group policy)

Założenia (policies) mogą być łączone do różnych kontenerów, oddziałujących na te same klienty. Klient pobierając zestaw założeń z różnych źródeł, scala pliki REGISTRY.POL z każdego rodzaju założeń (Użytkownik i komputer) w jeden plik POL dla tego typu.

• Pliki REGISTRY.POL ustawień Użytkownika są łączone w plik NTUSER.POL zapisany w katalogu głównym profilu użytkownika w folderze Documents and Settings.

• Pliki REGISTRY.POL ustawień Komputera są łączone w plik REGISTRY.POL zapisany razem z ustawieniami lokalnych założeń w folderze \WINNT\System32\GroupPolicy\Machine.

Aktualizacje Rejestru zapisane w wyżej wymienionych plikach REGISTRY.POL dadzą się łączyć, dopóki nie pojawi się kolizja. Inaczej mówiąc, jeśli klient pobiera kilka założeń (policies) zawierających aktualizacje odnoszące się do różnych pozycji Rejestru, to dokonuje się wszystkich aktualizacji. Jeśli kilka plików REGISTRY.POL zawiera aktualizacje odnoszące się do tej samej pozycji Rejestru, system określa pierwszeństwo założeń (policy) na podstawie hierarchii.

Założenia (policies) pobierane przez użytkownika lub komputer z wielu źródeł, są porządkowane na podstawie hierarchii i stosowane kolejno. Poniżej przedstawiono źródła aktualizacji Rejestru dokonywanych na podstawie założeń i ich hierarchię.

• Klasyczne założenia systemowe Windows NT. Dla zapewnienia zgodności z wcześniejszymi wersjami systemu Windows, klienty Windows 2000 szukają pliku NTCONFIG.POL w udziale NETLOGON w kontrolerze domeny. Te założenia systemowe tatuują lokalny Rejestr, więc takie przeszukiwanie można zablokować wykorzystując założenie (policy) Administrative Templates|System|Group Policy|Disable System Policy.

• Lokalne. Komputer lokalny z systemem Windows 2000 może mieć jeden zestaw lokalnych założeń (policies) użytkownika i komputera.

• Lokacja (Site). Granice lokacji (site) są określone przez topologię sieci WAN, a nie topologię domeny, więc łączenie założeń grupowych (group policy) z daną lokacją może być trudne, ponieważ istnieje prawdopodobieństwo przekroczenia granic administracyjnych. Najlepsze wykorzystanie założeń lokacji (Site) to rozdzielanie konfiguracji sieciowych, które są wyjątkowe dla sieci lokalnej, takich jak założenia usługi RAS.

• Domena. Założenie domeny (domain policy) stosuje się do każdego komputera i użytkownika w domenie, bez względu na lokalizację lokacji (site). W przedsiębiorstwach z silnym, centralnym działem IT korzysta się z założeń domeny, ale w przedsiębiorstwach mających bardziej rozproszoną strukturę zarządzania raczej omija się je na rzecz założeń jednostki organizacyjnej (OU policies).

• Jednostka organizacyjna (OU). Założenia grupowe związane z jednostkami organizacyjnymi (Organizational Units) są najważniejsze. Umożliwiają lokalnym administratorom kontrolę nad komputerami lokalnymi. Na przykład załóżmy, że administratorzy domeny Company.com zastosują zasadę (policy) usuwającą polecenie Uruchom (Run) z menu START. Administratorzy jednostki organizacyjnej Phoenix odbierają narzekania od tych swoich użytkowników, którzy lubią polecenie Uruchom (Run) i mogą ustawić założenia jednostki organizacyjnej (OU policy) specjalnie uaktywniające to polecenie. Te założenia mają pierwszeństwo i przywracają użytkownikom wyżej wymienionej jednostki organizacyjnej polecenie Uruchom (Run).

Oprócz hierarchii źródeł założeń, założenia grupowe (group policies) mogą być stosowane wybiórczo do poszczególnych grup bezpieczeństwa (security groups). Na przykład firma telemarketingowa może mieć trzy założenia (policies).

• Bardzo restrykcyjne założenia skonfigurowane dla grupy Outbound_Sales.

• Trochę mniej restrykcyjne założenie(policy) skonfigurowane dla grupy Customer Sales.

• Najmniej restrykcyjne założenie (policy) skonfigurowane dla Sales_Manager.

W przeciwnym wypadku można umieścić obiekty użytkownika w trzech oddzielnych jednostkach organizacyjnych (OU) i połączyć założenia z tymi jednostkami organizacyjnymi (OUs). Jeśli nie ma innych powodów administracyjnych do dzielenia użytkowników według jednostek organizacyjnych (OU), łatwiej jest zarządzać użytkownikami w jednym kontenerze i stosować założenia do grup. Nie ma żadnych różnic pod względem architektury i wydajności.

Blokowanie dziedziczenia założeń (policy)

Administratorzy lokalni danej jednostki organizacyjnej (OU) mogą zablokować założenia odziedziczone po jednostkach organizacyjnych znajdujących się wyżej w Active Directory lub mniej ważnych. Dotyczy to również założeń lokacji (Site) i domen, i tych odziedziczonych po macierzystej jednostce organizacyjnej (parent OU).

Odziedziczone założenia grupowe (group policies) są blokowane za pomocą opcji Blokuj dziedziczenie założeń (Block Policy Inheritance), ustawianych poprzez konsolę MMC. Rysunek 16.11 przedstawia okno Właściwości (Properties) dla jednostki organizacyjnej (OU), w którym wybrano opcję Blokuj dziedziczenie założeń (Block Policy Inheritance).

Założenia użytkownika standardowego (Standard User) przedstawione na rysunku 16.11 są stosowane na poziomie jednostek organizacyjnych (OU), a zablokowanie założeń zapobiega zastępowaniu założeń Domen i Lokacji (Site) przez założenia odziedziczone.

Wybranie opcji Nie zastępuj (No override) w założeniach domeny lub Lokacjach (site) zapobiega zastąpieniu innych obiektów założeń grupowych (Group Policy Objects) przez dane założenia. Rysunek 16.12 przedstawia okno Założenia grupowe Opcje, w którym opcja Nie zastępuj (No Override) jest ustawiona w Opcjach połączenia (Link Options).

Rysunek 16.11. Okno Właściwości (Properties) jednostki organizacyjnej (OU) przedstawiające zakładkę Założenia grupowe (Group Policy) i listę połączeń założeń grupowych.

Rysunek 16.12. Okno Opcje (Options) założeń grupowych (group policy) przedstawiające wybraną opcję Nie zastępuj (No Override).

Taki sposób obsługi dziedziczenia założeń jest podobny do sposobu przydzielania praw administracyjnych w Active Directory. Administratorom lokalnym jednostek organizacyjnych (OU) nie dano praw administracyjnych na poziomie domeny. Administratorom działów w potomnej jednostce organizacyjnej (child OU) nie dano praw administracyjnych na poziomie siedziby (Site). Zastosowanie opcji Nie zastępuj (No override) może nie okazać się dobrym pomysłem w przypadku dużej domeny z wieloma jednostkami organizacyjnymi (OUs).

Mechanizm pobierania założeń

Gdy klient Windows 2000 loguje się do domeny, szuka w domenie, siedzibie (site) i obiektach jednostek organizacyjnych połączeń do obiektów GPC. Następnie wykorzystuje informacje ścieżki dostępu odpornej na zakłócenia obiektów GPC do znajdowania folderów założeń w udziale SYSVOL. Ostatecznie pobiera pliki założeń i stosuje do obrazów lokalnego Rejestru w pamięci.

Po zakończeniu logowania się, klient wysyła co 90 minut zapytania do kontrolera domeny w celu aktualizacji założeń grupowych (group policies). Okres odświeżania założeń grupowych może być zmieniony za pomocą założeń grupowych (group policies). Dokładniejszy opis znajduje się w podrozdziale „Zarządzanie założeniami założeń grupowych” (Managing Group Policy Policies) zamieszczonym w dalszym ciągu niniejszego rozdziału.

Klient wylogowując się sprawdza jeszcze raz aktualizacje założeń grupowych (group policy), ponieważ przyjęto, że założenie (policy) może być zmienione przez zdarzenie wylogowywania (logoff event).

Aby system uwzględniał wprowadzone założenia (policies), w wielu przypadkach konieczne jest ponowne uruchomienie komputera. Dobrym sposobem postępowania jest rozprowadzanie założeń w ciągu dnia roboczego, a zalogowanie się użytkownika następnego dnia uaktywni je.

W trakcie normalnej pracy systemu, odświeżanie klientów wykonuje się ręcznie korzystając z programu Secedit. Składnia polecenia jest następująca:

secedit /refreshpolicy machine_policy (lub user_policy)

Program Secedit ma inne funkcje przeznaczone dla założeń grupowych (group policy) związanych z bezpieczeństwem. Szczegóły zawarto w rozdziale 6.

Szablony administracyjne

Pozycje pliku REGISTRY.POL określające założenia Użytkowników i komputerów (User and Computer policies), pochodzą z szablonów administracyjnych. Szablony te mają taką samą postać, jak ich odpowiedniki dla założeń systemowych (System Policies).

System Windows 2000 zawiera zestaw szablonów administracyjnych, zapisany w katalogu \WINNT\INF. Oto ich lista:

• Winnt.adm. Założenia systemowe interfejsu użytkownika dla Windows NT 4.

• Windows.adm. Założenia systemowe interfejsu użytkownika dla Windows 9x.

• Common.adm. Założenia systemowe interfejsu użytkownika dla obydwu platform.

• Shell.adm. Zbiór ograniczeń dotyczących powłoki Eksploratora (Explorer Shell), wykorzystywanych do kontrolowania Active Desktop.

• Inetres.adm (ładowany domyślnie). Założenia dla programu Internet Explorer, wpływające na takie składniki systemu Windows jak Internet Explorer, Panel sterowania (Cotrol Panel), strony w trybie offline (Offline Pages), menu usług przeglądania (Browser Menus), Persistence Behavior i Administrator Approved Controls.

• System.adm (ładowany domyślnie). Zestaw ograniczeń systemowych, zawierających ustawienia menu Start i paska zadań, ustawienia Pulpitu (Desktop Settings), ustawienia Panelu sterowania (Control Panel Settings), ustawienia sieciowe (Network settings), ustawienia systemowe (System settings),takie jak: ustawienia logowania/wylogowywania i ustawienia założeń grupowych (group policy) oraz założenia dla składników systemu Windows jak: Eksplorator (Explorer), MMC, Zadania Zaplanowane (Task Scheduler) i program instalacyjny systemu Windows.

• Inetset.adm. Dodatkowe ustawienia programu Internet Explorer, obejmujące AutoComplete, domyślne przyciski Paska narzędzi (Toolbar), ustawienia wyświetlania (Display settings), ustawienia zakładki Zaawansowane (Advanced Tab) i szyfrowanie adresów URL.

• Inetcorp.adm. Specjalizowane obiekty sterujące (controls), dotyczące języków Internet Explorera, ograniczeń połączenia telefonicznego (dialup) i buforowania (caching).

• Conf.adm. Założenia (policies) programu NetMeeting.

• Wmp.adm. Założenia (policies) programu Windows Media Player, obejmujące ustawienia pozwalające przystosowywać pasek nawigacji (navigation bar) WMP i ustawienia sieciowe do własnych potrzeb.

Pierwsze cztery pliki ADM służą do zachowania zgodności z systemem Windows NT 4. System Windows 2000 zawiera kopię Edytora założeń systemowych (System Policy Editor) Poledit, służącego do budowania plików NTCONFIG.POL do zarządzania klientami poprzednich wersji systemu Windows.

Rozszerzenia zakresu funkcji klienta (Client-side Extensions)

Wtyczka (snap-in) Założenia grupowe (GroupPolicy) zawiera kilka funkcji rozszerzających jej zestaw funkcji. W przypadku założeń Użytkownika i komputera wtyczki (snap-ins) mają postać szablonów administracyjnych, wymienionych w poprzednim podrozdziale. Inne rozszerzenia zakresu funkcji założeń (policy extensions) dotyczą bezpieczeństwa, przekierowywania folderów (folder redirections), skryptów i instalowania oprogramowania.

Każde z rozszerzeń zakresu funkcji w serwerze ma swój odpowiednik po stronie klienta, który tłumaczy i wprowadza w życie założenia. Programy rozszerzające działające po stronie klienta mają postać bibliotek DLL. W tabeli 16.1 zamieszczono listę programów rozszerzających i odpowiadające im biblioteki DLL.

Tabela 16.1. Rozszerzenia zakresu funkcji założeń grupowych i odpowiadające im biblioteki DLL po stronie klienta

Program rozszerzający w serwerze	Biblioteka DLL
Registry Administrative Templates (Computers and Users)	USERENV.DLL
Folder Redirection Editor	FDEPLOY.DLL
Scripts (Computers and Users)	GPTEXT.DLL
Security Settings	SCECLI.DLL
Software Installation (Computers and Users)	APPMGMTS.DLL
Disk Quota	DSKQUOTA.DLL
Encrypting File System Recovery	SCECLI.DLL
Internet Explorer Branding	IEDKCS32.DLL
--> IP Security (IPSEC)[Author:E]	GPTEXT.DLL

Poniżej opisano działanie wymienionych powyżej rozszerzeń zakresu funkcji:

• Userenv.dll odpowiada za obsługę właściwości zapisanych w Rejestrze. Obsługuje również ładowanie pliku NTUSER.DAT do Rejestru, gdy użytkownik loguje się. Od czasu do czasu w Dzienniku zdarzeń (Event Log) pojawiają się wpisy dotyczące USERENV.DLL, jeśli są problemy z obsługą założeń (policies) lub rozmiary Rejestru będą zbyt duże. W dalszej części niniejszego rozdziału w części zatytułowanej „Wykrywanie usterek założeń grupowych (Group Policy)” opisano wykrywanie usterek związanych z biblioteką Userenv.dll

• GPTEXT.DLL Fronton (front-end) programu Windows Scripting Host (WSH). Obsługuje również pliki wsadowe. Więcej informacji na ten temat zawiera podrozdział „Stosowanie skryptów logowania” znajdujący się w dalszej części niniejszego rozdziału.

• FDEPLOY.DLL jest wykorzystywany do zarządzania replikacją plików pomiędzy klientem a centralną składnicą (repository) plików. Więcej informacji znajduje się w podrozdziale „Zarządzanie przekierowywaniem folderów” zamieszczonym w dalszym ciągu niniejszego rozdziału.

• DSKQUOTA.DLL opisano w rozdziale 13. „Zarządzanie systemami plików”.

• SCECLI.DLL opisano w rozdziale 15.

• Adaptacja Internet Explorera (Internet Explorer branding) i dystrybucja oprogramowania wykraczają poza zakres niniejszej książki.

Wskazówka dotycząca Rejestru: Lista rozszerzeń zestawu funkcji klienta (client-side extensions)

--> Listę rozszerzeń zestawu funkcji klienta (client-side extensions) można znaleźć [Author:UP] w HKLM|Software|Microsoft|Windows NT |CurrentVersion|WINLOGON|GPExtensions.

Obsługa szablonów ADM

Edytor założeń grupowych (Group Policy Editor) wykorzystuje dwa szablony ADM jako szablony domyślne. Są to System.adm i Inetres.adm. Inne szablony można dodać klikając prawym klawiszem myszy ikonę Szablony administracyjne (Administrative Templates) i wybierając opcję DODAJ/USUŃ SZABLONY (ADD/REMOVE TEMPLATES). Rysunek 16.13 przedstawia wykaz dostępnych szablonów.

Rysunek 16.13. Wykaz szablonów administracyjnych dostępnych dla Edytora założeń grupowych (Group Policy Editor).

Edytor założeń grupowych (Group Policy Editor) ładując, kopiuje wybrany szablon z foldera \WINNT\INF do przydzielonego mu foldera założeń (policy), Adm. Rozszerzenia założeń po stronie serwera wykorzystują ten szablon, kiedy tworzą pozycje pliku REGISTRY.POL w odpowiedzi na opcje wybrane za pomocą Edytora założeń grupowych (Group Policy Editor).

Kiedy tworzy się założenia (policy), nie należy zmieniać szablonu. Pozycje szablonu są kopiowane do pliku REGISTRY.POL dla założeń (policy).

Domyślnie instalowane są dwie grupy założeń:

1. Domyślne założenia domeny (domain policy) połączone z kontenerem Domeny.

2. Domyślne założenia kontrolera domeny (Domain Controller Policy) połączone z jednostką organizacyjną kontrolera domeny.

Odpowiednie opcje założeń można uaktywniać albo blokować, lub utworzyć nowe założenia, wybierając inne opcje.

Szablony ADM można modyfikować na własne potrzeby, ale jest tu pewien haczyk. Za każdym razem Edytor założeń grupowych (Group Policy Editor) otwierając założenia (policy) odświeża lokalne kopie szablonów ADM zastępując je szablonami nadrzędnymi z foldera \WINNT\INF. Po zmianie lokalnego szablonu założeń, zmiany te mogą zostać utracone. System sprawdza znaczniki czasu (time stamps), więc lokalne szablony ADM nie są zastępowane natychmiast, ale jeśli ktoś zaktualizował szablon nadrzędny w folderze \WINNT\INF, wszystkie lokalne zmiany zostaną nadpisane przy najbliższym uruchomieniu Edytora założeń grupowych (Group Policy Editor). System nie wysyła żadnych ostrzeżeń. W następnym podrozdziale opisano sposób modyfikowania szablonów ADM.

Parametry Rejestru kontrolujące założenia grupowe (group policies)

Klucze i wartości Rejestru kontrolujące realizację założeń grupowych zapisane są w HKLM|Software|Microsoft|Windows|CurrentVersion|Group Policy. Rysunek 16.14 przedstawia rozmieszczenie podkluczy.

Rysunek 16.14 Edytor Rejestru prezentujący hierarchię kluczy założeń grupowych.

Poniższe podklucze są szczególnie ważne dla kontrolowania sposobu, w jaki założenia (policies) są stosowane w danym komputerze.

• History. Klucz ten zawiera identyfikator GUID każdego rozszerzającego programu użytkownika wywoływanego przez założenia grupowe (group policy). Przykładem programu rozszerzającego założeń jest USERENV.DLL obsługujący pozycje pliku REGISTRY.POL. Poniżej każdego z programów rozszerzających (extensions) znajduje się lista ponumerowanych kolejno kluczy, zawierających szczegóły dla każdego założenia, które robi użytek z danego programu rozszerzającego. Klucze są przydzielane w takiej kolejności, w jakiej przydzielane są założenia. Większość wartości przypisanych do założeń (policy) jest zrozumiałych samo przez się. GPOLink zaczyna się od 0 przy braku połączenia, 1=Komputer lokalny, 2=Lokacja (Site), 3=Domena i 4=Jednostka organizacyjna (OU).

• SIDs. Jest to szereg kluczy reprezentujących użytkowników, którzy zalogowali się do danego komputera. Klucz GroupMembership wymienia kolejno przynależność użytkowników do grup według identyfikatorów SID. Każdy, kto kiedykolwiek zastanawiał się, który identyfikator SID stanowi znacznik dostępu (access token) użytkownika, znajdzie odpowiedź w tym kluczu.

• Shadow. Klucz ten wymienia kolejno założenia bezpieczeństwa (security policies), które pozostają w mocy w danym komputerze i kolejność ich stosowania. Jest wykorzystywany przez program rozszerzający, dotyczący bezpieczeństwa SCECLI.DLL, co zostało opisane w rozdziale 6.

Modyfikowanie szablonów ADM

Teraz nastąpi przerwa w rozważaniach dotyczących składników założeń grupowych (group policy). Czasem może wystąpić konieczność zastosowania założenia (policy), które nie ma odpowiedniej pozycji w żadnym z przygotowanych szablonów. W takim przypadku trzeba zmodyfikować istniejący szablon lub utworzyć nowy.

Szablony ADM są plikami tekstowymi w kodzie ASCII, które mogą być modyfikowane za pomocą edytora tekstów lub Notatnika (Notepad). Poniżej znajduje się fragment pliku Inetres.adm, zawierający przykłady wszystkich niezbędnych składników:

; shell.adm

CLASS USER

CATEGORY !!Shell

KEYNAME Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

POLICY !!Shell

EXPLAIN !!ClassicShellExplain

PART !!ClassicShell CHECKBOX

VALUENAME ClassicShell

END PART

END POLICY

END CATEGORY

[strings]

ClassicShell="Enable Classic Shell"

ClassicShellExplain="Changes from Web-based shell to standard Explorer shell."

Shell="Shell"

A oto opis poszczególnych elementów:

• CLASS. Podaje systemowi, który z podkluczy Rejestru ma zostać zmieniony. Dla klasy USER modyfikuje się HKCU, dla klasy MACHINE modyfikuje się HKLM.

• CATEGORY. Definiuje nagłówek w Edytorze założeń grupowych(Group Policy Editor). Nie ma wpływu na zawartość Rejestru.

• KEYNAME. Określa klucz Rejestru, modyfikowany przez te założenia (policy).

• POLICY/END POLICY. Określa wpis, który ma być dokonany do klucza Rejestru.

• PART/END PART. Określa kilka typów interfejsów Edytora założeń grupowych (Group Policy Editor), które mogą być wykorzystane do zbierania informacji, wpisywanych do odpowiednich pozycji Rejestru.

• [strings]. Ta część określa tekst do wykorzystania zamiast łańcuchów znaków w części głównej szablonu. Podwójny wykrzyknik (!!) oznacza, że system ma szukać łańcucha znaków. Można także wpisać tekst bezpośrednio w odpowiednim wierszu, ujmując go w cudzysłów, ale dla łatwości konserwacji lepiej stosować łańcuchy znaków.

Rysunek 16.15. Przykładowe okno założeń przedstawiające interfejs typu NUMERIC podany w części PART szablonu ADM.

Nieobowiązkowy fragment PART szablonu jest wykorzystywany do tworzenia w Edytorze założeń grupowych (GPE) okna, za pomocą którego użytkownik wprowadza dane. Jeśli brak jest części PART, Edytor założeń grupowych (GPE) wyświetla okna standardowe. Wpisując fragment PART, trzeba także podać PART TYPE. Rysunek 16.15 przedstawia ekran Edytora założeń grupowych (GPE) typu NUMERIC. Poniżej zamieszczono opis wartości PART TYPE i ich funkcji:

• EDITTEXT. Wyświetla pole do wprowadzania tekstu.

• NUMERIC. Wyświetla pole do wprowadzania wartości liczbowych. Pasek przewijania do wyboru.

• CHECKBOX. Powoduje wyświetlenie pola wyboru (check box). Po zaznaczeniu pola wyboru wartość założenia jest ustawiana na 1. Wyczyszczenie pola wyboru powoduje nadanie założeniu wartości 0.

• COMBOBOX. Powoduje wyświetlenie listy złożonej (combo box).

• DROPDOWNLIST. Wyświetla listę złożoną (combo box) z listą rozwijalną. Wykorzystuje się w przypadku podawania zestawu opcji.

• LISTBOX. Wyświetla listę rozwijaną (list box) z przyciskami Dodaj (Add) i Usuń (Remove). Wykorzystuje się do nadawania wielu wartości jednemu kluczowi.

• TEXT. Wyświetla tekst etykiety.

Po zmodyfikowaniu lub utworzeniu nowego pliku ADM, konieczne jest uruchomienie Edytora założeń grupowych (Group Policy Editor) i załadowanie tego szablonu. Wymusi to na Edytorze założeń grupowych (Group Policy Editor) wykonanie sprawdzenia poprawności pliku ADM. Najczęściej spotykanym błędem jest brak odpowiednich pozycji w części [strings].

Jeśli Edytor założeń grupowych (Group Policy Editor) odrzuci którąkolwiek z pozycji, nie załaduje szablonu. Modyfikując szablon główny z foldera \WINNT\INF, trzeba upewnić się, czy wprowadzone zmiany przejdą kontrolę pomyślnie, ponieważ nadpisują lokalne pliki ADM i mogą sprowadzić niekończące się żale, gdyby były nieprawidłowe.

Tworzenie i dystrybucja Założeń grupowych Użytkownika i komputera (User and Computer Group Policies)

Jak większość czarnej roboty administratora, w przypadku zarządzania założeniami grupowymi (group policies) skomplikowane jest określenie, co dokładnie jest do zrobienia. Mając plan, można utworzyć i rozesłać założenia w kilka minut.

Poniżej opisano kolejne kroki tworzenia nowego obiektu założeń grupowych (Group Policy Object) i ustanowienia założeń (policy) z jego pomocą. W przykładzie utworzono założenia (policy) połączone z jednostką organizacyjną (OU) o nazwie Phoenix.

Procedura 16.13. Tworzenie i konfigurowanie obiektu Założenia grupowe (Group Policy Object)

1. Uruchom konsolę AD Użytkownicy i komputery (AD Users and Computers).

2. Kliknij prawym klawiszem myszy jednostkę organizacyjną (OU) zawierającą obiekty użytkowników, którymi chcesz zarządzać i z menu wybierz pozycję Właściwości (Properties). Pojawi się okno Właściwości (Properties) tego kontenera. Rysunek 16.16 przedstawia okno Właściwości (Properties) po utworzeniu nowych założeń (policy).

Rysunek 16.16. Okno Właściwości (Properties) jednostki organizacyjnej (OU) Phoenix po utworzeniu nowych założeń.

3. Naciśnij Nowy (New). Na liście Połączenia obiektów założeń grupowych (GroupPolicy Object Links) pojawi się nowe założenie (policy).

4. Nadaj nowo utworzonym założeniom (policy) krótką nazwę opisującą ich funkcję i połączenia, taką jak Standardowy użytkownik Phoenix (Standard Phoenix User). Nazwę można zmienić w dowolnym momencie. Rzeczywista zawartość założeń grupowych (group policy) jest określona przez identyfikator GUID, który się nie zmienia. Folder założeń zostanie utworzony w folderze \WINNT\Sysvol\Sysvol\<nazwa_domeny>.

5. Naciśnij Opcje (Options). Pojawi się okno Opcje (Options). Istnieją dwie opcje połączenia (Link Options).

Bez zastępowania (No Override) — Opcja ta zabezpiecza pozycje Rejestru odziedziczone po założeniach (policies), znajdujących się na wyższym poziomie Active Directory, przed modyfikacjami dokonywanymi przez dane założenia (policy).

Zablokuj (Disabled) — Opcja ta wstrzymuje dystrybucję danych założeń. Nie przywraca pierwotnych ustawień Rejestru.

6. Powróć do okna Właściwości (Properties) naciskając Anuluj (Cancel).

7. W celu modyfikacji zawartości założeń grupowych (grupo policy) naciśnij Edycja (Edit). Pojawi się przystawka (snap-in) Założenia grupowe z nazwą nowych założeń grupowych na szczycie drzewa katalogów.

8. Przejdź do gałęzi KONFIGURACJA UŻYTKOWNIKA|SZABLONY ADMINISTRACYJNE|PULPIT (USER CONFIGURATION|ADMINISTRATIVE TEMPLATES|DESKTOP). Rysunek 16.17 przedstawia listę opcji założeń Pulpitu (Desktop).

Rysunek 16.17. Wtyczka (snap-in) Założenia grupowe (Group Policy) przedstawiająca opcje założeń Pulpitu (Desktop).

9. Kliknij dwukrotnie pozycję Ukryj wszystkie ikony Pulpitu (Hide All Icons On Desktop). Pojawi się okno Właściwości (Properties) tej opcji.

10. Kliknij Aktywny (Enabled), a następnie naciśnij OK, by zapisać zmiany i powrócić do głównej konsoli Założenia grupowe (Group Policy). Pozycja Ustawienia (Setting) opcji pokazuje Aktywny (Enabled). Plik REGISTRY.POL w folderze USER, związanym z danymi założeniami, jest aktualizowany gdy tylko naciśniesz OK.

11. Zamknij konsolę Założenia grupowe (Group Policy) i powróć do okna Właściwości (properties) jednostki organizacyjnej (OU).

12. Zamknij okno Właściwości (Properties) by powrócić do konsoli AD Użytkownicy i komputery (AD Users and Computers).

13. Zamknij konsolę.

Teraz koniecznie trzeba sprawdzić działanie założeń (policy) logując się do komputera na konto znajdujące się w jednostce organizacyjnej (OU) połączonej z nowo utworzonymi założeniami grupowymi (group policy). Na pulpicie użytkownika nie będzie żadnych ikon.

Lokalizacja pozycji Rejestru w szablonach ADM

Jednym z wyzwań przy próbach zmiany poszczególnych ustawień Rejestru za pomocą założeń grupowych (group policy) jest obliczenie, w którym szablonie zapisane są pozycje kontrolujące dane ustawienia Rejestru.

Edytor założeń grupowych (Group Policy Editor) ma wykaz łańcuchów znaków, które powinny opisywać funkcje Założeń (policy), ale trudno mieć pewność, którą z pozycji Rejestru modyfikują dane założenia (policy).

Nie ma żadnej funkcji przeszukiwania poszczególnych pozycji Rejestru. To musi robić administrator.

Najpierw należy określić pozycję Rejestru, która ma być zmieniona. Wskazówek można szukać w Rejestrze lub skorzystać z Microsoft KnowledgeBase, ale można także zrobić to w następujący sposób. Wiedząc, co wywołuje zmiany poszczególnych pozycji Rejestru, za pomocą narzędzia Ntregmon pobranego ze strony www.sysinternals.com, można określić, które klucze Rejestru są aktualizowane po wywołaniu zmian.

Gdy znane jest ustawienie Rejestru, które trzeba zmienić, należy za pomocą narzędzia Znajdź (Search) z menu START poszukać kluczy lub wartości Rejestru w plikach ADM w katalogu \WINNT\INF.

Jeśli w istniejącym szablonie ADM nie można znaleźć pozycji Rejestru, która ma być zmieniona, można zmodyfikować ten szablon lub utworzyć nowy szablon zawierający zmiany.

Stosowanie założeń do grup

Zakres stosowania założeń (policy) można zawęzić tak, by obejmowały tylko konkretną grupę lub grupy wybrane z jednostki organizacyjnej (OU), domeny lub lokacji (Site), z którymi założenia są połączone. Korzystając z tego można dostosować zestaw założeń (policies) do wymagań wybranych zespołów użytkowników. Wybór założeń dla grup dokonuje się za pomocą ustawień Bezpieczeństwo (Security) założeń (policy) w następujący sposób:

Procedura 16.14 Stosowanie założeń grupowych (group policies) dla poszczególnych grup

1. Uruchom konsolę MMC zawierającą obiekt, którym chcesz zarządzać. W niniejszym przykładzie jest to konsola AD Użytkownicy i komputery (Users and Computers).

2. Kliknij prawym klawiszem myszy ikonę Domena lub Jednostkę organizacyjną i z menu wybierz pozycję Właściwości (Properties). Pojawi się okno Właściwości (Properties).

3. Kliknij dwukrotnie istniejące założenia. Pojawi się okno Założenia grupowe (Group Policy).

4. Kliknij prawym klawiszem myszy ikonę Założenia (Policy) w górnej części drzewa i z menu wybierz pozycję Właściwości (Properties). Pojawi się okno Właściwości (Properties).

Rysunek 16.18. Przykładowe okno Założenia grupowe Właściwości (Group Policy Properties) przedstawiające opcje zakładki Bezpieczeństwo (Security).

5. Wybierz zakładkę Bezpieczeństwo (Security) (rys. 16.18). Opcja Zastosuj Założenia grupowe (Apply Group Policy) w polu Uprawnienia (Permissions) określa, czy dane założenia stosuje się do grupy wybranej w polu Nazwa (Name). W niniejszym przykładzie założenia odnoszą się do grupy Authenticated Users.

6. Po naciśnięciu OK okno Właściwości (Properties) zostanie zamknięte i nastąpi powrót do konsoli AD Użytkownicy i komputery (AD Users and Computers).

7. Zamknij konsolę.

Zastosowanie tych założeń dla grupy Authenticated Users oznacza, że aktualizacje Rejestru są pobierane i stosowane przez każdego z użytkowników zalogowanych w domenie, reprezentowanych w Active Directory przez obiekt Użytkownik (User) w połączonej jednostce organizacyjnej (OU). W razie konieczności stosowania bardziej zróżnicowanych założeń, można tworzyć inne grupy.

Można również zabronić dostępu do pewnych grup, jeśli jest to bardziej wydajne. Na przykład można ustanowić założenia (policy), mające wpływ na użytkowników w jednej z dużych grup (niech to będzie grupa Authenticated Users), a następnie zabronić dostępu do pewnego podzbioru tej grupy, takiego jak IT_Admins.

Grupa Group Policy Creator Owners

System Windows 2000 zawiera kilka wstępnie zdefiniowanych grup wykorzystywanych do delegowania (delegation). Jedną z takich grup jest Group Policy Creator Owners. Grupa ta znajduje się na liście ACL kontenera (Container) cn=Policies, cn=System, dc=domain, dc=root z uprawnieniami Create All Child Objects.

Wykrywanie usterek założeń grupowych

Jeśli założenia grupowe nie działają prawidłowo, należy sprawdzić następujące punkty.

• Podgląd zdarzeń (Event Viewer). Usługa Userenv dokonuje wpisów do dziennika zdarzeń aplikacji (Application log). Ostrzeżenia wpisane przez tę usługę są pierwszym wskaźnikiem , że z pobieraniem założeń grupowych (group policy) stało się coś złego.

• Prawa dostępu. Powszechnie spotykanym problemem z założeniami grupowymi jest gwarancja praw dostępu. Zawsze konieczne jest upewnienie się, czy użytkownik ma prawo dostępu do założeń, które mają być zastosowane. Najłatwiejszym sposobem sprawdzenia tego jest wykorzystanie odpowiedniej konsoli Active Directory, otwarcie właściwości założeń grupowych (group policy) połączonego kontenera (container) i wybranie zakładki Bezpieczeństwo (Security). Dany użytkownik powinien być członkiem grupy z uprawnieniami Zezwolenie (Allow).

• Nieprawidłowe połączenia założeń. Innym często spotykanym problemem, występującym przy konfigurowaniu założeń grupowych (group policies) jest „utrata mapy” („losing the map”), jak to nazywane jest na szkoleniu pilotów myśliwców. Założenia mogły zostać połączone z danym kontenerem (container), ale do testowania używane jest konto użytkownika z innego kontenera (container). Albo ktoś mógł umieścić inne założenia (policy) wyżej w hierarchii założeń niż dane założenia (policy) i albo wymazano poprzednie założenia, albo zostały całkowicie zablokowane. Jest to szczególnie frustrujący problem w systemie Windows 2000, ponieważ nie ma odpowiedniego narzędzia do śledzenia wszystkich założeń, które mogą być lub powinny być zastosowane dla poszczególnych użytkowników. Firma Microsoft obiecuje takie narzędzie w kolejnej wersji maintenance systemu Windows 2000.

• Usuwanie błędów biblioteki Userenv. Ostatnia deska ratunku przy poszukiwaniu, w czym tkwi problem, to uruchomienie wpisów do dziennika zdarzeń założeń grupowych (group policy logging). W systemie Windows NT 4 wymaga to zainstalowania wersji tzw. checked build biblioteki USERENV.DLL, programu rozszerzającego po stronie klienta, odpowiedzialnego za aktualizacje Rejestru. Umożliwia to uzyskanie dostępu do plików zawierających informacje konieczne przy wykrywaniu błędów (debug symbols). W systemie Windows 2000 pliki te są zawarte w wersji free build biblioteki USERENV.DLL. Do klucza WINLOGON musi zostać dodana wartość Rejestru zezwalająca na logowanie.

--> Key: HKLM|Software|Microsoft|Windows NT|CurrentVersion|Winlogon

Value: UserEnvDebugLevel

Data: 0x10002 (Hex) of type Reg_Dword[Author:E]

Po dodaniu tej wartości należy ponownie uruchomić komputer. Plik dziennika zdarzeń mieści się w katalogu \WINNT\Debug\Userenv.log. Trzeba przygotować sobie filiżankę kawy i uzbroić się w cierpliwość. Plik ten zawiera wiele informacji.

Tworzenie niestandardowej konsoli Edytora założeń grupowych (Group Policy Editor)

Zamiast korzystać z konsoli Active Directory do otwierania założeń grupowych, można utworzyć własne konsole MMC, uruchamiające wtyczki założeń grupowych (Group Policy snap-in). Ładowanie konsoli z jedną wtyczką (single snap-in console) zajmuje mniej czasu. Można także odpowiednio przystosować konsolę za pomocą różnych rozszerzeń wtyczek (snap­-in extensions). Na przykład można utworzyć konsolę Obsługa (Operations), która ładuje rozszerzenie Użytkownik i komputer — Założenia (User and Computer Policies), oraz drugą konsolę Bezpieczeństwo sieci LAN (LAN Security), która ładuje rozszerzenia Bezpieczeństwo (Security). Niestandardowe konsole założeń grupowych tworzy się i konfiguruje w następujący sposób:

Procedura 16.15. Tworzenie niestandardowej konsoli Edytora założeń grupowych (Group Policy Editor)

1. Otwórz okno Uruchom (Run) za pomocą menu START|URUCHOM (START|RUN), wpisz MMC i naciśnij OK. Otworzy się pusta konsola MMC.

2. Z menu konsoli wybierz KONSOLA|DODAJ/USUŃ PRZYSTAWKĘ (CONSOLE|ADD/REMOVE SNAP-IN). Pojawi się okno Dodaj/Usuń przystawkę (Add/Remove snap-in).

3. Naciśnij Dodaj (Add). Pojawi się okno Dodaj przystawkę autonomiczną (Add Standalone Snap-in).

4. Kliknij dwukrotnie Założenia grupowe (Group Policy). Pojawi się okno Wybierz obiekt założeń grupowych (Select Group Policy Object).

5. Sprawdź, czy na liście Obiekt założeń grupowych (Group Policy Object) znajduje się pozycja Komputer lokalny (Local Computer).

6. Naciśnij Zakończ (Finish) aby dodać obiekt założeń grupowych (GPO) do listy przystawek autonomicznych (standalone snap-ins) i powrócić do okna Dodaj przystawkę autonomiczną (Add Standalone Snap-in).

7. Naciśnij Zamknij (Close), aby powrócić do okna Dodaj/Usuń przystawkę (Add/Remove Snap-in).

8. Wybierz zakładkę Rozszerzenia (Extensions). Zauważ, że opcja Dodaj wszystkie rozszerzenia (Add All Extensions) jest wybrana domyślnie. Można to zmienić i wybrać rozszerzenia odpowiednio do danego zadania.

9. Naciśnij OK, aby zapisać konfigurację i powrócić do konsoli MMC.

10. Z menu konsoli wybierz pozycję KONSOLA|ZAPISZ JAKO (CONSOLE|SAVE AS). Pojawi się okno Zapisz jako (Save as).

11. Nadaj konsoli nazwę. Konsola zostanie zapisana w folderze Moje dokumenty (My Documents), o ile nie wybierzesz inaczej.

12. Jeśli konfigurujesz konsolę dla innych administratorów, tryb użytkownika Autor musi być zmieniony. Z menu konsoli wybierz KONSOLA|OPCJE (CONSOLE|OPTIONS). Pojawi się okno Opcje (Options).

13. Z listy Tryby pracy konsoli (Console Mode) wybierz Tryb użytkownika — Pełny dostęp (User Mode — Full Access).

14. Naciśnij OK, aby zapisać zmiany i powrócić do głównego okna konsoli.

Wykorzystanie założeń grupowych (group policies) do zarządzania założeniami grupowymi (group policies)

Założenia (policies) zarządzające założeniami grupowymi (group policies) są zarządzane, jak wszyscy pewnie się już domyślają, poprzez założenia grupowe (group policies). Te „założenia założeń” umieszczone są w Edytorze założeń grupowych (Group Policy Editor) w folderze Konfiguracja komputera (Konfiguracja użytkownika)|Szablony Administracyjne|System|Założenia grupowe (Computer Configuration (User Configuration)|Administrative Templates|System|Group Policies). Poniżej opisano założenia założeń grupowych i podano, gdzie można je stosować:

• Zablokuj założenia systemowe (Disable System Policy). Założenia te powodują odrzucenie przez komputery z systemem Windows 2000 założeń systemu Windows NT, zapisanych w pliku NTCONFIG.POL. Stosuje się je aby uniknąć trwałych aktualizacji Rejestru, narzuconych przez założenia systemowe (system policies).

• Założenia grupowe — wykrywanie wolnych połączeń (Group Policy Slow Link Detection). Dla systemu wartością graniczną, pozwalającą zaliczyć połączenie do kategorii połączeń wolnych lub szybkich, jest 500 kbps. Wykorzystując niniejsze założenie można zmienić tę granicę. Założenie modyfikuje klucz Rejestru HKLM|Software|Policies|Microsoft|Windows|System|GroupPolicyMinTransferRate.

Pomiar prędkości łącza

Inaczej niż w przypadku Windows NT, system Windows 2000 rzeczywiście dokonuje pomiarów prędkości transmisji połączenia, aby określić, czy jest ono wolne czy szybkie. Procedura jest następująca:

• Za pomocą programu ping wysyła do serwera blok danych o rozmiarze 0 bajtów i mierzy czas. Jeśli czas jest krótszy niż 10 ms, połączenie jest zaliczone do szybkich.

• Za pomocą programu ping wysyła do tego samego serwera blok danych o rozmiarze 4 kB i mierzy czas.

• Oblicza się różnicę czasów uzyskanych w opisanych powyżej próbach. W wyniku otrzymuje się czas transmisji 4 kB danych.

• Próby takie wykonuje się trzykrotnie, aby uzyskać średni czas przesyłania 4 kB danych.

• Otrzymany wynik przelicza się na bity na sekundę i porównuje z wartością graniczną. Domyślną wartością jest 500 kB.

• Przetwarzanie założeń. Założenia te kontrolują sposób obsługi przez rozszerzenia zakresu funkcji klienta (client-side extensions) przetwarzania w tle dla ich rodzaju założeń. Założenia z opcjami przetwarzania to Założenia Rejestru (Registry policies), założenia dotyczące ograniczeń obszaru dysku dla użytkownika (Disk Quota), założenia skryptów (Scripts policies) i założenia IPSec. Większość założeń składa się z trzech części:

• Opcja Nie stosuj podczas okresowego przetwarzania w tle (Do Not Apply During Periodic Background Processing) zapobiega aktualizacji założeń podczas sprawdzania aktualizacji, dokonywanego co 90 minut.

• Opcja Nie stosuj w przypadku łącza wolnego (Do Not Apply Over Slow Link) blokuje okresowe aktualizacje, jeśli łącze użytkownika jest wolniejsze niż założona wartość graniczna.

• Opcja Przetwarzaj, nawet jeśli obiekty założeń grupowych nie zmieniły się (Process Even If the Group Policy Objects Have not Changed) powoduje ponowne zastosowanie założeń, nawet jeśli zostały zaktualizowane. Jest to opcja zwiększająca natężenie ruchu w sieci.

• Zablokuj odświeżanie w tle (Disable Background Refresh). W normalnych warunkach użytkownik i komputery-klienty najpierw szukają założeń grupowych podczas logowania, a potem powtarzają to co 90 minut. Niniejszą opcję można wykorzystać do zablokowania okresowego odświeżania, ale wykorzystanie tej opcji może być przyczyną problemów w rozsyłaniu aktualizacji założeń do użytkowników, którzy nigdy się nie wylogowują.

• Okres odświeżania założeń grupowych komputerów (użytkowników) (Group Policy Refresh Interval for Computers (Users)). Założenie to ustawia dwa klucze Rejestru w gałęzi HKLM|Software|Policies|Microsoft Windows|System, określające okres odświeżania. Pierwszy z kluczy, GroupPolicyRefreshTime, zawiera wartość okresu. Domyślnie jest to 90 minut. Drugi klucz, GroupPolicyOffsetTime, powoduje losowe odświeżanie założeń.

• Zastosuj założenia grupowe dla komputerów jednocześnie podczas uruchamiania i Zastosuj założenia grupowe dla użytkowników podczas uruchamiania. W normalnych warunkach założenia muszą być pobrane i zastosowane zanim WINLOGON wyświetli okienko logowania (logon prompt). Może to opóźnić pojawienie się tego okienka i sprawiać wrażenie, że komputer się zawiesił. Po wybraniu opcji jednoczesnego stosowania założeń WINLOGON wyświetla okienko logowania zanim zakończy się pobieranie założeń. Uspokoi to nerwowych użytkowników, ale nie przyspiesza całego procesu logowania.

• Uruchom skrypty logowania jednocześnie. Założenie to zezwala na inicjalizację powłoki (shell) Eksploratora jednocześnie z działającym skryptem. Nie wolno wybierać tej opcji jeśli skrypty logowania modyfikują powłokę.

• Uruchom skrypty logowania w sposób jawny. W większości sytuacji nie trzeba denerwować użytkowników dziwnymi komunikatami pojawiającymi się w trakcie logowania. Użytkownicy i tak widzą wystarczająco wiele niezrozumiałych dla nich komunikatów. Domyślnie skrypty logowania pracują w tle. Założenie to można uaktywnić do wyświetlania skryptów przy wykrywaniu błędów.

• Wyłącz katalogi z profilów mobilnych (roaming profiles). Niekontrolowany wzrost --> profilów[Author:UP] wędrujących powoduje bóle głowy administratorów odpowiedzialnych za obsługę serwerów profilów (profile server). Nadmiarowe dane zapełniają kosztowne pamięci dyskowe (spinning storage) i powodują dodatkowy ruch w sieci podczas porannego logowania się i wieczornego wylogowywania się. Założenie to zezwala na wyłączenie folderów, takich jak Temp, Temporary Internet Files itd. Można również wyłączyć foldery Moje dokumenty (My Documents) i Ulubione (Favorites), ale lepiej jest przekierować te foldery zamiast stwarzać możliwość utraty danych.

• Ograniczenie rozmiaru profilu (dostępne w folderze System|Logon\Logoff). Jest to jeszcze jedno założenie pomocne w kontrolowaniu przechowywania danych i ruchu w sieci związanych z profilami. Ponieważ użytkownicy mogą w swoich profilach umieścić prawie wszystko, foldery profilów osiągają wielkie rozmiary. Próby kontrolowania nadymania profilów za pomocą ograniczeń obszaru dysku dostępnego dla użytkownika (quota) mogą doprowadzić do sytuacji, w której profile lokalne przekroczą te nałożone ograniczenia. Jeśli są nałożone takie ograniczenia, które nie mogą być przekroczone, podczas wylogowywania się użytkownika profile podlegają replikacji tylko częściowo. Opcja Ogranicz rozmiar profilu (Limit Profile Size) wykorzystuje program narzędziowy Proquota.exe do monitorowania rozmiarów profilów i ostrzegania użytkowników o przekroczeniu dozwolonej granicy. Ograniczenie rozmiarów profilów powinno mieć wartość nieco niższą od ograniczenia nałożonego na obszar dysku dostępny dla użytkownika (quota) w serwerze profilów (profile server).

• Wybór kontrolera domeny założeń grupowych. Zwykle klienty pobierają założenia grupowe z kontrolera domeny dokonującego identyfikacji danego użytkownika. Za pomocą tego założenia można określić specjalny kontroler domeny, z którego uzyskuje się założenia (policies). Na przykład można mieć wiele kontrolerów domen, ale tylko jeden lub dwa o mocy obliczeniowej wystarczającej do obsłużenia setek lub tysięcy pobrań założeń (policy downloads).

• Założenia grupowe (group policy) uzytkownika — tryb przetwarzania: pętla zwrotna (loopback). Ponieważ użytkownicy logują się po zalogowaniu się ich komputerów, założenia (policies) użytkownika są stosowane na końcu i mają pierwszeństwo. Można jednak znaleźć przypadki, w których pierwszeństwo mają mieć założenia (policies) komputera, na przykład komputer laboratoryjny, terminal informacyjny (kiosk computer) albo po prostu komputer, który nie chce uwzględniać ustawień użytkowników. Przetwarzanie w pętli zwrotnej (loopback processing) ma dwie opcje: Scal (Merge) i Zamień (Replace). Opcja Scal (Merge) powoduje, że stosuje się założenia użytkownika, a następnie ponownie stosuje się ustawienia komputera. Opcja Zamień (Replace) powoduje ignorowanie ustawień użytkownika.

Wykorzystanie skryptów logowania

Nie zawsze zmiany środowiska pracy pociągają za sobą aktualizacje Rejestru. Czasami wykorzystuje się do tego celu zwykłe skrypty logowania.

Firma Microsoft z ociąganiem przyznaje, że skrypty logowania są konieczne i użyteczne w zarządzaniu użytkownikami. Windows NT ma tak słabą obsługę skryptów, że wiele firm zewnętrznych stworzyło narzędzia do tego celu. Windows 2000 Resource Kit zawiera niektóre z tych narzędzi.

Tak jak dawny prześladowca staje się gorliwym zwolennikiem, firma Microsoft zmieniła radykalnie swoje podejście do obsługi skryptów. System Windows 2000 zawiera tyle opcji obsługi skryptów, że podjęcie decyzji o wyborze jednego z nich staje się problemem. Obsługiwane są wszystkie powszechnie znane języki skryptowe, ale gwiazdą, przynajmniej z punktu widzenia firmy Microsoft, jest program Windows Script Host, będący częścią systemu Windows 2000.

Windows Script Host pojawił się w NT 4 Option Pack jako Windows Scripting Host, ale po opracowaniu przez firmę Microsoft programu do obsługi skryptów o nazwie Windows Script konieczna była zmiana nazwy. Windows Script Host jest językiem proceduralnym, ze wszystkimi wodotryskami, jakich można oczekiwać. Platforma SDK, dostępna pod adresem www.microsoft.com, zawiera pełny zestaw poleceń dla VBSript, Jscript i Windows Script.

Jedną z zalet Windows Script jest zdolność obsługi funkcji VBScript i Jscript, a także rozszerzeń dla innych języków skryptowych, takich jak Perl, Rexx, Kix itd.

Niezależnie od wybranego rodzaju skryptu, jego obsługa przez system Windows 2000 jest jednakowa. Tworzy się skrypt i umieszcza w kontrolerze domeny w folderze \WINNT\Sysvol\Domain\Scripts. Z tego foldera dokonuje się replikacji do wszystkich pozostałych kontrolerów domeny.

Skrypt nie musi być umieszczony w folderze założeń (policy). Założenia grupowe (group policy) kontrolujące skrypty logowania/wylogowywania się mogą wskazywać na dowolną lokalizację w katalogu \WINNT\Sysvol\Domain. Przypomnijmy, że foldery w udziale (share) SYSVOL w rzeczywistości są dynamicznymi wskaźnikami lokalizacji danych (reparse points), które są dołączone z powrotem do foldera \WINNT\Sysvol\Domain. Po umieszczeniu w folderze \WINNT\Sysvol\Domain\Scripts, skrypt pojawia się automatycznie w udziale SYSVOL.

Oprócz tego są jeszcze dwie zalety zapisywania skryptów w folderze \WINNT\Sysvol\Domain\Scripts:

• Nazwy udziałów odpornych na błędy (fault-tolerant share). Ponieważ każdy kontroler domeny ma udział SYSVOL, można umieścić udział w ścieżce UNC z nazwą domeny zamiast nazwy serwera. Firma Microsoft określa to jako nazwę udziału odpornego na błędy (fault-tolerant share). Podając ścieżkę UNC wpisuje się zamiast nazwy serwera pełną nazwę domeny (FQDN). Na przykład, w domenie Company.com odporna na błędy (fault-tolerant UNC path) ścieżka UNC do udziału SYSVOL to \\company.com\SYSVOL\Scripts\<nazwa_skryptu>.

• Obsługa klientów poprzednich wersji systemu Windows (downlevel clients) za pomocą skryptów. Klienty poprzednich wersji systemu Windows nie pobierają założeń grupowych. Muszą być tak skonfigurowane, by wykorzystywały specjalny skrypt, umieszczony w udziale NETLOGON. System Windows 2000 umożliwia obsługę takich klientów udostępniając folder \WINNT\Sysvol\Domain\Scripts jako NETLOGON. Więcej na ten temat w części pod tytułem „Replikacja skryptów logowania poprzednich wersji systemu Windows”.

Replikacja skryptów logowania poprzednich wersji systemu Windows

Poprzednie wersje systemu Windows mają zaprogramowane na stałe szukanie skryptu logowania w udziale (share) serwera uwierzytelniającego (authenticating server).

Udział (share) NETLOGON w kontrolerze domeny systemu Windows NT wskazuje na katalog \WINNT\System32\Repl\Import\Scripts, gdzie Repl oznacza Replication. Katalog dopełniający, \WINNT\System32\Repl\Export\Scripts, jest punktem pośrednim dla replikacji skryptów.

Podstawowy kontroler domeny (Primary Domain Controller — PDC) systemu Windows NT musi być skonfigurowany w ten sposób, by wykonywał replikację zawartości katalogu Export do katalogu Import i odwrotnie, oraz replikację obydwu katalogów do wszystkich zapasowych kontrolerów domeny (Backup Domain Controllers). Gwarantuje to, że klienty logujące się do dowolnego kontrolera domeny będą korzystały ze skryptu logowania zapisanego w udziale (share) NETLOGON.

Replikacja w systemie Windows NT wykorzystuje usługę o nazwie Lmrepl lub LanManReplicator. Replikacja skryptów za pomocą tej usługi jest trochę niewygodna.

Usługa Lmrepl nie jest obsługiwana przez system Windows 2000. Jeśli skrypty logowania dla klientów poprzednich wersji systemu Windows mają być nadal wykorzystywane, i wciąż istnieją w sieci klasyczne zapasowe kontrolery domeny (BDCs), to należy skonfigurować program Zadania zaplanowane (Task Scheduler), aby plik wsadowy za pomocą programu XCOPY kopiował skrypt do katalogu \Export\Scripts w zapasowym kontrolerze domeny (BDC). Następnie trzeba skonfigurować replikację z danego zapasowego serwera domeny (BDC) do pozostałych zapasowych serwerów domeny (BDCs). Firma Microsoft określa to jako uzupełnienie luki po usłudze Lmrepl (Lmrepl bridge).

Przydzielanie skryptów logowania/wylogowania się klientom Windows 2000

W poniższym przykładzie użytkownikom z jednostki organizacyjnej Phoenix domeny Company.com przydzielany jest niewielki skrypt logowania. Skrypt logowania, Logon.vbs, jest krótkim skryptem VB, wyświetlającym tylko komunikat: „Cześć, administratorze. Witamy w domenie Company.com”. Skrypt ten wygląda następująco:

Set localnet=Wscript.CreateObject(“Wscript.Network”)

Wscript.Echo “Hello, “& localnet.Username & “. Welcome to the “ & localnet.UserDomain & “domain.”

Poniżej opisano ładowanie skryptu i konfigurowanie założeń grupowych, rozsyłających ten skrypt:

Procedura 16.16. Przydzielanie skryptów logowania/wylogowania klientom Windows 2000

1. Skopiuj skrypt do foldera \WINNT\Sysvol\Domain\Scripts, skąd automatycznie zostanie skopiowany do pozostałych kontrolerów domeny.

2. Otwórz konsolę Założenia grupowe (Group Policy) założeń, które chcesz połączyć z danym skryptem. Na przykład jeśli chcesz przydzielić specjalny skrypt logowania użytkownikom z jednostki organizacyjnej Phoenix, to musisz poprawić założenia grupowe tej jednostki organizacyjnej.

3. Rozszerz drzewo do gałęzi Konfiguracja użytkownika|Ustawienia systemu Windows|Skrypty (Logowanie/Wylogowywanie) (User Configuration|Windows Settings|Scripts (Logon/Logoff)). W prawej części okna pojawią się dwie ikony: Logowanie (Logon) i Wylogowywanie (Logoff).

4. Kliknij dwukrotnie ikonę Logowanie (Logon). Pojawi się okno Właściwości (Properties). Rysunek 16.19 przedstawia przykład z załadowanym już skryptem.

Rysunek 16.19. Okno Logowanie Właściwości (Logon Properties) przedstawiające istniejący skrypt logowania.

5. Naciśnij Dodaj (Add). Pojawi się okno Dodaj skrypt (Add a Script). Przykład przedstawiono na rysunku 16.20.

Rysunek 16.20. Okno Dodaj skrypt (Add a Script) przedstawiające odporną na błędy ścieżkę UNC do danego skryptu.

6. Za pomocą przycisku Przeglądaj (Browse) przejdź do foldera \WINNT\Sysvol\Sysvol\<nazwa_domeny>\Scripts. Nie przechodź dalej, ponieważ znajdziesz się poza obszarem wskaźników na dysku lokalnym.

7. Wybierz skrypt i naciśnij Otwórz (Open), aby nazwa skryptu i ścieżka dostępu znalazła się w polu Nazwa skryptu (Script Name) okna Dodaj skrypt (Add A Script). Upewnij się, czy ścieżka UNC ma składnię odporną na błędy (fault-tolerant syntax).

8. Naciśnij OK, aby dodać skrypt do listy w oknie Logowanie Właściwości (Logon Properties).

9. Naciśnij OK, aby zapisać zmiany i zamknąć okno Właściwości (Properties).

W celu sprawdzenia działania skryptu zaloguj się na konto w jednostce organizacyjnej lub domenie połączonej z założeniami grupowymi (Group Policy), zawierającymi dany skrypt.

Przydzielanie skryptów logowania klientom poprzednich wersji systemu Windows

Użytkownicy klientów poprzednich wersji systemu Windows muszą mieć przydzielony skrypt logowania w odpowiednich obiektach użytkowników w Active Directory. Klienty poprzednich wersji systemu Windows mają zaprogramowane na stałe poszukiwanie skryptów logowania w udziale NETLOGON (NETLOGON share) w uwierzytelniającym kontrolerze domeny (authenticating domain controller). Więcej informacji na ten temat znajduje się w części pod tytułem „Replikacja skryptów logowania poprzednich wersji systemu Windows” zamieszczonej wcześniej w niniejszym rozdziale.

Przydzielanie skryptów logowania klientom poprzednich wersji systemu Windows odbywa się w następujący sposób:

Procedura 16.17. Przydzielanie skryptów logowania klientom poprzednich wersji systemu Windows

1. Otwórz konsolę AD Użytkownicy i grupy (AD Users and Groups).

2. Rozszerz drzewo, aby przedstawić obiekt użytkownika, który chcesz skonfigurować.

3. Kliknij dwukrotnie wybrany obiekt. Pojawi się okno Właściwości (Properties).

4. Wybierz zakładkę Profil (Profile). Rysunek 16.21 przedstawia przykładowe dane skryptu logowania. Podaj nazwę skryptu, a nie ścieżkę dostępu. Skrypt musi być zapisany w udziale (share) NETLOGON \WINNT\Sysvol\Domain\Scripts.

Rysunek 16.21 Okno Użytkownik Właściwości (User Properties) przedstawiające zakładkę Profil (Profile) i dane dotyczące skryptu logowania.

5. Naciśnij OK, aby zapisać ustawienia i zamknąć okno.

6. Zamknij konsolę.

7. Przetestuj skrypt logując się jako klient poprzedniej wersji systemu Windows. Skrypty w tych wersjach systemu pracują poprawnie w systemie Windows 2000, ale nie są wyświetlane domyślnie.

Pliki wsadowe i użyteczne zmienne środowiska pracy

Jeśli pisanie skryptów logowania w jakimś trudnym języku wygląda jak strzelanie z armaty do wróbli, można wykorzystać pliki wsadowe (batch files). Za pomocą interpretatora poleceń (command interpreter) CMD tworzy się całkiem wymyślne pliki wsadowe. Niektórzy znawcy potrafiliby chyba stworzyć kompletny system operacyjny posługując się wyłącznie plikiem wsadowym. W pliku wsadowym nie można stosować wyszukanych pętli programowych i programowania strukturalnego, ale do nadawania wartości zmiennym środowiska pracy lub mapowania kilku dysków plik taki nadaje się znacznie lepiej niż skrypt VB.

Uruchamianie starszych skryptów w systemie Windows 2000

System Windows 2000 automatycznie uruchamia w tle w komputerze-kliencie skrypty z rozszerzeniami BAT i CMD. Jest to prawdą nawet jeśli w skrypcie umieszczone są tylko przerwania (break), aby zatrzymać go podczas wyświetlania na ekranie.

Jeśli plik wsadowy lub plik poleceń (command file) ma być wyświetlany na ekranie, należy aktywować następujące założenia grupowe (group policy):

User Configuration|Administrative Templates|System|Logon/Logoff|Run Logon Scripts Visible

Kilka zmiennych środowiskowych może być przydatnych do pisania skryptów zarządzających kontami użytkowników. Oto ich lista:

• USERPROFILE. Ścieżka dostępu do lokalnego profilu użytkownika, typowo jest to C:\Documents and Settings\<nazwa_użytkownika>.

• ALLUSERSPROFILE. Ścieżka dostępu do profilu All Users. Typowo jest to C:\Documents and Settings\All Users.

• COMPUTERNAME. Nazwa NetBIOS komputera, do którego zalogował się użytkownik.

• HOMEDRIVE. Symbol (litera) dysku wykorzystywana do mapowania do katalogu domowego.

• HOMEPATH. Pełna ścieżka UNC do katalogu domowego.

• LOGONSERVER. Nazwa NetBIOS serwera identyfikującego użytkowników.

• OS. System operacyjny zainstalowany w komputerze użytkownika.

• USERDOMAIN. Domena identyfikująca użytkownika.

• USERNAME. Nazwa NetBIOS użytkownika.

Poniżej znajduje się plik wsadowy wykorzystujący te zmienne:

@echo off

echo Hello, %USERNAME%. Welcome to the %USERDOMAIN% domain.

Echo You have logged on to %LOGONSERVER% z %COMPUTERNAME%.

Echo You are running %OS% from the %SYSTEMROOT% directory.

Echo Your home directory is on %homedrive%%homepath%.

Echo The path to this directory is %homeshare%%homepath%

Echo Your local settings are located in %USERPROFILE%.

Echo Additional settings are located in %ALLUSERSPROFILE%.

Wynik wykonania powyższego pliku może wyglądać następująco:

Hello, Rmanuel. Welcome to the Company.com domain.

You have logged on to PHX-DC-01 from PHX-W2KP-032.

You are running Windows_NT from the \WINNT directory.

Your home directory is Z:\RMANUEL.

The path to this directory is \\phx-dc-01\usres.

Your local settings are stored in C:\Documents and Settings\Administrator [PHX-W2KP-001].

Additional settings are located in C:\Documents and Settings\All Users.

Zarządzanie przekierowywaniem folderów

Od aplikacji spełniających standardy systemu Windows 2000 wymaga się, by zapisywały wszystkie dane użytkownika i pliki konfiguracyjne w profilu użytkownika. Wyświetlając okno zachęty do zapisania pliku, programiści aplikacji albo wykorzystują zmienną %userprofile%, wskazującą na katalog Moje dokumenty (My Documents) systemu Windows 2000, albo raczej korzystają z wywołań funkcji SHGetFolderPath, zwracającej informacje o lokalizacji wszystkich folderów profilu. W związku z tym, że na rynku pojawia się coraz większa liczba aplikacji oznaczonych logo Windows 2000, rozpraszanie danych związane z obsługą komputera powinno stopniowo zanikać. Jednakże jeden problem nie został rozwiązany za pomocą zapisywania danych użytkownika w folderze Moje dokumenty (My Documents). Domyślną lokalizacją foldera jest lokalny dysk twardy. Sytuacja taka prowadzi do dialogów podobnych do opisanego poniżej:

Użytkownik: Trzeba coś szybko zrobić. Mój komputer zazgrzytał, a kiedy go włączyłem, zobaczyłem komunikat: „Unable to load command interpreter. System halted.”

Administrator: Wyślemy kogoś w ciągu godziny, by wymienił dysk twardy.

Użytkownik: A co z listą płac?

Administrator: Jak to co z listą płac?

Użytkownik: Dzisiaj jest czwartek. Potrzebne mi są arkusze kalkulacyjne do obliczenia listy płac.

Administrator: W którym serwerze są przechowywane?

Użytkownik: Nie jestem pewien. Sądzę, że jest to serwer Moje dokumenty (My Documents).

Ciąg dalszy tej rozmowy można sobie wyobrazić. W systemie Windows 2000 rozwiązaniem tego problemu jest przekierowywanie folderów (Folder Redirection). Jest to zestaw założeń (policies) zezwalających na zastąpienie przechowywania krytycznych folderów profilu w serwerze. Foldery profilów, które mogą być przekierowywane to:

• Dane aplikacji (Application Data)

• Pulpit (Desktop)

• Moje dokumenty ( Moje obrazy) (My Documents and My Pictures)

• Menu START

Przekierowanie folderów Dane aplikacji (Application Data) i Moje dokumenty (My Documents) jest ważne dla zabezpieczenia danych użytkownika. Przekierowanie Pulpitu (Desktop) i menu START jest mniej ważne, ale może być pomocne w tworzeniu wspólnego interfejsu użytkownika, wskazując na wszystkich użytkowników w tym samym miejscu. Zamiast stosowania profilów obowiązkowych łatwiej jest stworzyć wspólne środowisko pracy, wykorzystując przekierowanie folderów (folder redirections). Podążając tą drogą należy być ostrożnym i zablokować uprawnienia dotyczące plików głównych (central files).

Ustawienia przekierowywania folderów (folder redirection) są zapisane w pliku INI pod nazwą FDEPLOY.INI umieszczonym w folderze profilu użytkownika. Poniżej przedstawiono przykładowy plik FDEPLOY.INI, w którym zapisano ustawienia dotyczące przekierowania folderu Moje dokumenty (My Documents):

[FolderStatus]

My Documents=11

My Pictures=2

[My Documents]

s-1-1-0=\\phx-dc-01\users\%username%\My Documents

[My Pictures]

Do przechowywania przekierowanych folderów profilów, profilów mobilnych (roaming profiles) i katalogów domowych (home directories) użytkowników może służyć ten sam wolumin serwera (server volume). Upraszcza to zarządzanie, ale jednocześnie serwer staje się bardzo cenny. Jeśli serwer ulegnie awarii lub będzie niedostępny z jakiegokolwiek innego powodu, użytkownicy utracą dostęp do danych i mogą nie być w stanie uruchomić aplikacji, ponieważ pliki konfiguracyjne są również zapisane w serwerze.

Poniżej opisano przekierowanie foldera (folder redirection) Moje dokumenty (My Documents), które umieszcza go w serwerze głównym. Procedura przekierowywania innych folderów jest identyczna.

Procedura 16.18. Konfigurowanie przekierowania foldera Moje Dokumenty

1. Otwórz konsolę Active Directory, zawierającą kontener Lokacja (Site), domena lub jednostka organizacyjna (OU) związany z założeniami (policy), które chcesz zmodyfikować.

2. Przejdź do kontenera, kliknij prawym klawiszem myszy i z menu wybierz pozycję Właściwości (Properties).

3. Wybierz zakładkę Grupa — Właściwości (Group Properties).

4. Wybierz istniejące założenia (policy) i naciśnij Edytuj (Edit). Jeśli chcesz utworzyć nowe założenia (policy), naciśnij Nowy (New). Pojawi się konsola Założenia grupowe (Group Policy).

5. Rozszerz drzewo do gałęzi Konfiguracja użytkownika|Ustawienia systemu Windows|Przekierowanie foldera (User Configuration|Windows Settings|Folder Redirection).

6. Prawym klawiszem myszy kliknij Moje dokumenty (My Documents) i z menu wybierz opcję Właściwości (Properties). Pojawi się okno Moje dokumenty Właściwości (My Documents Properties) z wybraną zakładką Cel (Target).

Rysunek 16.22. Okno Moje dokumenty Właściwości (My Documents Properties) prezentujące ustawienia Podstawowe (Basic) lokalizacji profilu.

Istnieją dwie opcje przekierowywania foldera:

Podstawowe (Basic): Opcja ta określa jedną lokalizację dla wszystkich użytkowników związanych z danymi założeniami (policy). Przedstawiono ją na rysunku 16.22. Do utworzenia oddzielnych lokalizacji plików można wykorzystać zmienną %username%. Na przykład w polu Docelowa lokalizacja pliku (Target File Location) można wpisać \\nazwa_serwera\nazwa_udziału\folder lokalizacji\%username% (\\server_name\share_name\location_folder\%username%).

Zaawansowane (Advanced). Opcję tę przedstawiono na rysunku 16.23. Wykorzystując opcję Zaawansowane (Advanced) można określić różne lokalizacje dla użytkowników, na podstawie ich przynależności do grup (group membership). Również można określić oddzielne foldery w danej lokalizacji wykorzystując zmienną %username%.

7. Wybierz zakładkę Ustawienia (Settings), która zawiera opcje obsługi plików w folderze Moje dokumenty (My Documents). Przykład przedstawiono na rysunku 16.23.

Rysunek 16.23. Okno Moje dokumenty Właściwości (My Documents Properties) przedstawiające zakładkę Ustawienia (Settings) z wybranymi opcjami.

Opcje obsługi przekierowania folderów (folder redirection)

Zakładka Ustawienia (Settings) przedstawiona na rysunku 16.23 ma kilka opcji określających, kto ma dostęp do foldera w serwerze, jeśli folder zostanie przeniesiony lub skopiowany do serwera, i gdzie umieścić folder, jeśli założenia (policy) zostaną anulowane.

--> Nadanie użytkownikowi wyłącznych praw do foldera Moje dokumenty (My Documents)[Author:E] umieszcza listę ACL w zdalnym folderze Moje dokumenty (My documents), co powoduje, że tylko dany użytkownik ma prawo dostępu Full Control. W podobny sposób obsługiwane są profile mobilne (roaming profiles). Nie wolno korzystać z tej opcji konfigurując wspólną składnicę plików (file repository) dla grup użytkowników.

--> Przeniesienie zawartośći foldera Moje dokumenty (My Documents) do nowego miejsca[Author:E] polega na jego usunięciu z lokalnego dysku twardego i umieszczeniu go w serwerze foldera. Użytkownikowi, który może nawet nie zdawać sobie sprawy, że jego pliki znajdują się teraz w serwerze, daje to ciągłość usług. Użytkownik nie musi zapisywać kopii swoich plików w dwóch miejscach. Jednakże przekierowywanie folderów może również sprawiać kłopoty administratorom, którzy nie mają zaufania do poleceń Przenieś (Move). Jeśli użytkownik nie ma kopii zapasowych lokalnych dokumentów, lepsze będzie ręczne skopiowanie plików.

Dwie opcje Usuwanie założeń (Removal Policy) określają, w jaki sposób system użytkownika reaguje, kiedy założenia zostaną anulowane.

Przekieruj folder z powrotem (Redirect the Folder Back) przydatna jest w sytuacjach, w których użytkownikowi potrzebny jest natychmiastowy dostęp do plików.

Pozostaw folder (Leave the Folder) jest przydatna jeśli założenia (policy) mają być anulowane, ale ma być zachowana kontrola dokumentów przez serwer.

Opcje Moje obrazy (My Pictures) pozostają wygaszone, dopóki ten folder nie zostanie wybrany. Czasami zachodzi konieczność zablokowania możliwości przechowywania w serwerze dużych map bitowych.

8. Wybierz ponownie zakładkę Docelowy (Target).

9. W polu Ustawienia (Settings) wybierz opcję Zaawansowane (Advanced). W oknie pojawi się pole Członkostwo grupy bezpieczeństwa (Security Group Membership), jak to przedstawiono na rysunku 16.24.

Rys. 16.24. Okno Moje dokumenty Właściwości (My Documents Properties) przedstawiające opcje Zaawansowane (Advanced) lokalizacji profilu i pole Członkostwo grupy bezpieczeństwa (Security Group Membership).

10. Naciśnij Dodaj (Add). Pojawi się okno Określ grupę i lokalizację (Specify Group and Location) (rysunek 16.25).

Rysunek 16.25. Okno Określ grupę i lokalizację (Specify Group i Location) przedstawiające członkostwo grupy i docelową lokalizację foldera.

11. W polu Członkostwo grupy bezpieczeństwa (Security Group Membership) naciśnij Przeglądaj (Browse). Pojawi się okno Wybierz grupę (Select Group). Wybierz odpowiednią grupę i naciśnij OK, aby powrócić do okna Określ grupę i lokalizację (Specify Group and Location).

12. W polu Docelowa lokalizacja foldera (Target Folder Location) wpisz ścieżkę dostępu do miejsca, w którym mają być zapisane dane grupy. Lokalizację docelową można znaleźć korzystając z funkcji Przeglądanie (Browse). Jeśli każdy z użytkowników ma mieć oddzielny folder, na końcu ścieżki dodaj %username%.

13. Naciśnij OK, aby zapisać zmiany i powrócić do okna Moje dokumenty Właściwości (My Documents Properties).

14. Naciśnij OK, aby zapisać założenia przekierowywania folderów i zamknąć okno.

15. Zaloguj się w stacji roboczej korzystając z konta użytkownika danej grupy. Sprawdź, czy folder Moje dokumenty (My Documents) wskazuje nową lokalizację.

16. Jeśli użytkownik ma pliki w istniejącym folderze Moje dokumenty (My Documents), na dysku lokalnym lub w profilu mobilnym (roaming profile), i nie zostały wybrane do przeniesienia do nowej lokalizacji, trzeba je teraz skopiować ręcznie. Nie zapomnij o usunięciu starych wersji plików, by użytkownik przypadkowo nie zapisał zmian w złym pliku.

Laptopy a przekierowywanie folderów (folder redirections)

Laptopy stanowią problem dla założeń przekierowywania folderów (folder redirection policy). Scentralizowane zapisywanie folderów danych powoduje, że są one niedostępne dla podróżujących użytkowników.

Istnieją dwa rozwiązania tego problemu. Można nie przekierowywać folderów użytkowników laptopów, ale jest to rozwiązanie niezbyt eleganckie, ponieważ trzeba z góry wiedzieć kto używa laptopa.

W następnym podrozdziale opisano uruchamianie starych, XX-wiecznych aplikacji w systemie Windows 2000. Może to być ostatnia wersja systemu Windows, w której można uruchomić całą gamę starych aplikacji. Firma Microsoft nie deklaruje, że aplikacje 16-bitowe będą obsługiwane w 64-bitowych wersjach Windows, a projekt Millenium polega na zaprojektowaniu wersji Systemu Windows 98 wolnej od dziedzicznych obciążeń. Może nareszcie uda się przekonać zarząd, aby zaktualizował aplikacje księgowe Clippera '87.

Stosowanie aplikacji systemu DOS i 16-bitowych aplikacji systemu Windows oraz zarządzanie nimi

System Windows 2000 obsługuje starsze aplikacje w sposób, który nie różni się bardzo od systemu Windows NT. Dla aplikacji systemu DOS i 16-bitowych aplikacji Windows tworzy się specjalne środowisko pracy, wykorzystując właściwość architektury X86 pod nazwą Wirtualny komputer DOS-owy (Virtual DOS Machine — VDM).

VDM emuluje wywołania funkcji DOS-a, interfejs BIOS i architekturę pamięci, na którą oczekują aplikacje systemu DOS. Ponieważ 16-bitowa wersja systemu Windows jest po prostu rozszerzeniem DOS-a, starsze aplikacje systemu Windows również pracują w środowisku VDM.

Zadanie obsługi trybu Wirtualnego komputera DOS-owego spada na specjalny 32-bitowy proces NTVDM.EXE. Proces ten jest uruchamiany jednocześnie z uruchamianiem aplikacji DOS-owych lub 16-bitowych aplikacji systemu Windows. Można to sprawdzić uruchamiając 16-bitową aplikację, na przykład Edit.exe, a następnie sprawdzając listę procesów Menedżera zadań (Task Manager). Na liście znajdzie się Ntvdm, a nie Edit.exe.

Uruchamianie 16-bitowych aplikacji systemu Windows w Windows 2000 stanowi oddzielne zagadnienie. Po pierwsze 16-bitowe aplikacje systemu Windows są w rzeczywistości tylko rozszerzeniem systemu DOS uzupełnionym o worek wywołań API i kilka sztuczek, umożliwiających działanie aplikacji w trybie chronionym (protected mode). Jeśli chodzi o pamięć i operacje wejścia/wyjścia, to trzeba się nieźle nagimnastykować. System Windows 2000 musi poradzić sobie z tymi sztuczkami i przetworzyć je na standardowe wywołania Win32 API. Po drugie, stare aplikacje Windows są zaprogramowane w ten sposób, by korzystać z powłoki Menedżera programów (Program Manager) i plików INI. System Windows 2000 musi przekonać aplikację, by zechciała pracować korzystając z powłoki Eksploratora (Explorer shell) i zapisać jakoś informacje o stanie aplikacji w Rejestrze.

Kilka podstawowych funkcji systemu Windows jest obsługiwanych przez NTVDM, w taki sposób jak DOS obsługuje je w normalnym systemie Windows. Obsługa 16-bitowych wywołań API i sztuczek z pamięcią jest wykonywana przez specjalny proces pod nazwą Windows-on-Windows subsystem, WOW. Nazwa odpowiedniego sterownika to Wowexec.exe.

Win.com a Windows 2000

Wowexec imituje 16-bitową wersję systemu Windows do momentu załadowania tej wersji systemu za pomocą Win.com. W tym celu folder \WINNT\System32 zawiera kopię programu Win.com.

Działanie programu Win.com można sprawdzić za pomocą wiersza poleceń. Otwórz Menedżera zadań (Task Manager) i w linii poleceń wpisz win wowexec. Powróć do linii poleceń. Sprawdź zakładkę Proces (Process) Menedżera zadań (Task Manager). Zauważ, że uruchomiony jest Ntvdm z Wowexec jako podzadaniem (subtask).

Niektóre starsze programy poszukują katalogu Windows szukając pliku Win.com. Programy te mogą umieścić pliki współużytkowane w nieprawidłowym podkatalogu, ponieważ Win.com jest zapisany w katalogu \WINNT\System32, a nie w katalogu głównym \Windows. Nie ma na to sposobu.

Wskazówki dotyczące Rejestru: Parametry WOW

Parametry WOW zapisane są w dwóch kluczach Rejestru:

• HKLM|Software|Microsoft|Windows NT|Current Version|WOW. Jest to zestaw parametrów definiujący sterowniki klawiatury, myszy, grafiki, sieci, dźwięku, portu szeregowego i powłoki (shell) razem z obszerną listą opcji zgodności dla starszych programów.

• HKLM|System|CurrentControlSet|Control|WOW. Jest to zestaw parametrów określających ograniczenia środowiska pracy VDM, takie jak: parametry pamięci, wartość przekroczenia czasu, czy domyślnie wykorzystywać oddzielne obszary pamięci i inne.

Omówienie starszych aplikacji, które nie są obsługiwane w systemie Windows 2000

Inaczej niż w przypadku systemu Windows 9x, który usuwa się w cień i pozwala na przejęcie komputera we władanie przez 16-bitowe aplikacje Windows i DOS-owe, systemy Windows 2000 i Windows NT nigdy nie zapewniają prawdziwego 16-bitowego środowiska pracy. Jeśli aplikacja odmawia pracy w środowisku VDM, nie będzie działać w systemie Windows 2000. System Windows 2000 nie zawiera Trybu MS-DOS.

Większość aplikacji DOS-owych i 16-bitowych pracuje poprawnie w systemach Windows 2000 i Windows NT. Aplikacje, które nie działają w tych systemach należą do poniższych kategorii:

• Aplikacje odwołujące się bezpośrednio do sprzętu. --> NTVDM pracuje ciężko, aby oszukać aplikacje DOS-owe, aby myślały, że mają komputer dla siebie, ale [Author:UP] jeśli aplikacja chce koniecznie odwołać się bezpośrednio do sprzętu, zostanie zakończona. Kontaktowanie się ze sprzętem jest wyłączną domeną trybu jądra (Kernel), której strzeże tak pilnie, jak członek komitetu strajkowego swoich kontaktów z pracodawcą.

Powszechnie spotykane aplikacje nieobsługiwane w systemie Windows 2000

• Gry i inne programy rozrywkowe, umieszczające informacje bezpośrednio w buforze zamiast wykorzystywania OpenGL lub wywołań DirectX API.

• Stare aplikacje komunikacyjne, próbujące bezpośrednio oddziaływać na port RS232.

• Urządzenia podłączane do portu równoległego, takie jak zabezpieczenia sprzętowe programów (security dongle) i tzw. CD-ROM boxcars.

• Programy do obsługi dysku, odwołujące się bezpośrednio do dysku zamiast korzystania z wywołań BIOS-a.

• Przestarzałe klienty Btrieve, które mogą pracować bardzo niestabilnie w środowisku VDM.

• Starsze wersje programów do emulacji terminala, stosujące własne wywołania sieciowe, które nie wykorzystują obsługiwanych interfejsów.

• Programy rezydentne (TSR). Aplikacje DOS-owe zwykle nie współużytkują tego samego obszaru pamięci. Trzeba skonfigurować plik wsadowy (batch file), który będzie ładować programy rezydentne korzystające z tego samego środowiska VDM. Uruchomi się zadziwiająco wiele programów rezydentnych (TSR) z lat 80., o ile pliki konfiguracyjne są poprawne. Informacje na ten temat znajdują się w podrozdziale „Config.nt i Autoexec.nt”, zamieszczonym w dalszym ciągu niniejszego rozdziału.

• Aplikacje systemu Windows wykorzystujące VxDx. Są to sterowniki pracujące w trybie chronionym, które same zarządzają pamięcią i rejestrem. Systemy Windows 2000 i Windows NT nie obsługują VxDx. Aplikacje korzystające z VxDx nie mogą mieć oznaczeń „Ready for Windows NT” i Ready for Windows 2000”.

• Aplikacje wykorzystujące wywołania Win16 API w sposób nieprawidłowy. Można znaleźć stare aplikacje systemu Windows, które albo stosują sztuczki związane z Win16 API, albo pomijają je całkowicie, stosując bezpośrednie wywołania funkcji DOS-owych. Nie musi to powodować problemów, ponieważ firma Microsoft była jednym z najgorszych winowajców, a niemal wszystkie starsze programy Microsoftu pracują w środowisku WOW. Jeśli aplikacja systemu Windows zostanie załadowana, zainicjowana i natychmiast zakończy działanie w sposób nieprawidłowy (blow up), może okazać się, że problemu nie można ominąć.

• Aplikacje wykorzystujące nieobsługiwane operacje na pamięci. Zarządzanie pamięcią rozszerzoną XMS/EMS (extended/expanded) w środowisku NTVDM obsługuje niemal wszystkie odmiany pamięci rozszerzonej EMS i XMS oraz standardowy tryb DMA. Nie obsługuje VCPI, ponieważ wymaga to bezpośredniego dostępu do rejestrów CPU. Aplikacje napisane w asemblerze, wykorzystujące operacje bezpośrednio na pamięci, nie będą działać.

• Aplikacje które nadmiernie zużywają zasoby. Aplikacje te nie są zazwyczaj problemem dla systemu Windows 2000, takim jak dla usług terminalowych (Terminal Services). Aplikacja, która odpytuje klawiaturę 60 razy na sekundę lub wysyła polecenia w pętlach nieskończonych (critical loops) lub nie chce działać w środowisku z współużytkowaniem pamięci, może spowodować niestabilną pracę usług terminalowych (Terminal Services). Nie ma żadnych wyraźnych reguł obsługi takich aplikacji. Najlepiej jest zajrzeć do Microsoft KnowledgeBase i współpracować z autorem aplikacji.

Po wyeliminowaniu nieobsługiwanych aplikacji, konfigurowanie i uruchamianie pozostałych aplikacji wymaga nakładu pracy w trzech obszarach:

• Wykorzystanie interpretatorów poleceń Windows 2000 Cmd.exe i Command.com

• Konfigurowanie i zarządzanie interfejsem konsoli, czasem określanej błędnie jako DOS Box, do obsługiwania aplikacji znakowych (character-based applications), takich jak programy rezydentne (TSR) i aplikacje sieciowe.

• Konfigurowanie podsystemu WOW do pracy z 16-bitowymi aplikacjami systemu Windows, włączając w to obsługę pamięci expanded/extended i dostęp do sieci Win16.

Konfigurowanie interpretatorów poleceń

Nieważne, jak funkcjonalny i wygodny wydaje się graficzny interfejs użytkownika systemu Windows 2000. Nieuchronnie nadejdzie czas, kiedy okaże się, że do wykonania rzeczywistej pracy potrzebny jest wiersz poleceń. W systemie Windows NT są dwa okna konsoli: 32-bitowej konsoli wykorzystującej CMD.EXE jako interpretator poleceń i konsoli 16-bitowej wykorzystującej COMMAND.COM jako interpretator. Konsola COMMAND.COM zapewnia środowisko pracy z poleceniami DOS 5.0 umożliwiającymi uruchamianie plików wykonywalnych i programów rezydentnych (TSR), które wymagają prawdziwego środowiska DOS.

Konsole alternatywne

System Windows 2000 zawiera dwie rzadko używane konsole. Jedną dla standardu POSIX, drugą dla systemu OS/2. Obsługa standardu POSIX w systemie Windows NT spełnia wymagania rządowe, ale programy spoza systemu Windows, takie jak MKS Toolkit lub Reflections, zapewniają zazwyczaj bardziej wszechstronną obsługę Uniksa. Konsola systemu OS/2 obsługuje tylko aplikacje tekstowe wersji 1.1 i przez to jest straszliwie przestarzała. Obsługa systemu OS/2 przez Windows 2000 jest jak stara fotografia ślubna poniewierająca się w albumie długo po rozwodzie. Firma Microsoft nie chce pozbyć się jej, chociaż służy tylko do przywoływania przykrych wspomnień.

Konsole CMD i COMMAND nie umożliwiają pracy w środowisku DOS w takim sensie, jak występuje to w systemie OS/2 w postaci procesu o nazwie „DOS box”. Konsola CMD jest programem 32-bitowym i tworzy prawdziwe 32-bitowe środowisko pracy. Konsola COMMAND.COM pracuje w środowisku wirtualnego komputera DOS-owego (VDM), ale w razie potrzeby bezkolizyjnie przechodzi do 32-bitowego interpretatora poleceń CMD. Uruchomienie z konsoli COMMAND na przykład polecenia DIR, spowoduje wyświetlenie na ekranie długich nazw plików (long filenames), a nie krótkich.

Uruchamianie wiersza poleceń za pomocą pozycji menu START|PROGRAMY|WIERSZ POLECEŃ (START|PROGRAMS|COMMAND PROMPT) w rzeczywistości powoduje uruchomienie 32-bitowej konsoli CMD. Można to sprawdzić otwierając Menedżera zadań (Task Manager) i wybierając zakładkę Procesy (Processes). CMD.EXE znajduje się na liście uruchomionych zadań. Jeśli w komputerze zainstalowano Resource Kit, można sprawdzić listę uruchomionych procesów za pomocą programu TLIST /t. Kiedy uruchamia się aplikację 16-bitową, system Windows 2000 najpierw uruchamia NTVDM.EXE, a następnie ładuje aplikację do środowiska wirtualnego komputera DOS-owego (VDM). Jeśli aplikacja 16-bitowa jest uruchamiana z konsoli CMD, NTVDM.EXE jest wątkiem (thread) CMD.

Możliwość uruchamiania w tle konsoli CMD przez konsolę COMMAND, umożliwia również uruchamianie 32-bitowych aplikacji graficznych. Na przykład otwórz konsolę COMMAND, uruchom SOL, a następnie sprawdź listę procesów uruchomionych za pomocą polecenia TLIST -t. Oto próbka:

Explorer.exe (130)

ntvdm.exe (179) C:\command.com

cmd.exe (168)

sol.exe (177) Solitaire

Należy zwrócić uwagę, że w 32-bitowym środowisku wirtualnego komputera Dosowego (NTVDM) pracuje 16-bitowa sesja interpretatora COMMAND, która uruchamia interpretator CMD, zawierający z kolei wątek (thread) Solitaire. Chociaż program TLIST pokazuje te procesy i procesy potomne, jeśli proces NTVDM zostanie usunięty (kill), to konsola CMD i jej wątek (thread) SOL zostaną.

Użytkownicy systemu Windows 9x, którzy przywykli do uruchamiania konsoli COMMAND za pomocą okna Uruchom (Run), powinni zamiast niej uruchomić CMD. Interpretator COMMAND.COM jest bardzo wolny w porównaniu z CMD. Nie powinno się uruchamiać konsoli COMMAND, o ile nie jest konieczny prawdziwy emulator DOS-a.

Nieobsługiwane wersje DOS-owe interpretatora poleceń COMMAND.COM

W przypadku komputera z systemem operacyjnym wybieranym przy starcie (dual-boot machine), przy uruchamianiu konsoli COMMAND.COM może pojawić się błąd. Dzieje się tak, ponieważ w ścieżce przeszukiwania znajduje się starsza wersja COMMAND.COM. Należy usunąć lub zmienić nazwę starej wersji.

Rozszerzony został zbiór poleceń interpretatora CMD w stosunku do systemu DOS 6.2 i DOS-a w systemie Windows 9x. Interpretator CMD obsługuje język plików wsadowych (batch language) podobny do języka plików wsadowych (batch language) systemu DOS, ale bogatszy i mający możliwości wywoływania aplikacji 32-bitowych. Tworząc pliki wsadowe (batch files) w systemie Windows 2000, należy nadać im rozszerzenie CMD, aby zagwarantować, że zostaną uruchomione w środowisku 32-bitowym.

Wskazówka dotycząca Rejestru: Priorytet przeszukiwania

Priorytet przeszukiwania w przypadku uruchamiania aplikacji, dla których nie podano rozszerzenia, jest następujący: EXE, COM, BAT, PIF, CMD. W razie potrzeby można zmienić ten porządek za pomocą klucza Rejestru:

Key: HKCU|Software|Microsoft|Windows NT|CurrentVersion|Windows

CMD rozpoznaje rozszerzenia z listy rozszerzeń nazw plików, więc wystarczy wpisać tylko nazwę pliku danych z odpowiednim rozszerzeniem, aby uruchomić związaną z nim aplikację. Na przykład zarejestrowanym rozszerzeniem konsoli MMC jest .msc. Po wpisaniu dnsmgmt.msc interpretator poleceń uruchomi konsolę DNS Zarządzanie (DNS Management). Takie samo działanie jest także w przypadku uruchamiania skryptów Windows Script Host i innych języków skryptowych, takich jak Perl. Rexx czy Kix.

Interpretator CMD może być również podany w skrótach (shortcuts) uruchamiających aplikacje w trybie znakowym. Pozwala to wykorzystać zalety parametrów (switches) polecenia CMD, modyfikujących przebieg sesji. Oto lista parametrów (switches):

/C. Parametr ten zamyka okno sesji po zakończeniu działania aplikacji. Można na przykład użyć polecenia CMD /C do uruchomienia zdalnego klienta poczty (mail client), kiedy okno ma być zamknięte po zebraniu poczty i zakończeniu działania klienta.

/K. Parametr ten pozostawia okno sesji otwarte po zamknięciu aplikacji. Można na przykład użyć polecenia CMD /K w programie Zadania zaplanowane (Scheduler) aby uruchomić plik wsadowy wieczorem, a następnego dnia przeczytać komunikaty o błędach.

/D. Parametr ten blokuje funkcję AutoRun procesora CMD. Funkcja AutoRun umożliwia uruchamianie programu lub pliku wsadowego przy każdym otwarciu sesji konsoli. Funkcja ta nie jest normalnie aktywna. Można ją aktywować za pomocą następujących wartości w Rejestrze: HKLM|Software|Microsoft|Command Processor|AutoRun lub HKCU|Software|Microsoft|Command Processor|AutoRun.

/V:ON. Parametr ten umożliwia opóźnione rozwinięcie (delayed expansion) zmiennej środowiska. W normalych warunkach zmienne środowiska są rozwijane (expanded), gdy tylko zostaną przetłumaczone (interpreted). W przypadku opóźnionego rozwinięcia (delayed expansion) zmiennej środowiska, zmienna ta nie jest rozwijana (expanded), dopóki polecenie nie zostanie wykonane. Zwykłe zmienne środowiska oznaczone są znakami %....%. Opóźnione rozwinięcie (delayed expansion) zmiennej środowiska oznaczone jest wykrzyknikami !...!. Oto krótki przykład sposobu działania opóźnionego rozwinięcia (delayed expansion). Weźmy pod uwagę skrypt pod nazwą TEST.CMD, o następującej zawartości:

echo %username%

echo !username!

A oto przebieg wykonywania skryptu:

C:\>test

C:\>echo admin

admin

C:\>echo !username!

admin

Rozwinięcie zmiennych środowiska (variable expansion) domyślnie jest zablokowane. Dodając poniższą wartość Rejestru, która ma typ danych Reg_Dword do procesora poleceń (Command Processor), można aktywować rozwinięcie zmiennych środowiska (variable expansion) dla wszystkich sesji CMD:

Key: HKLM|Software|Microsoft|Command Processor

Value: DelayedExpansion

Data: 1 (typ Reg_Dword)

/Q. Ten parametr wyłącza echo danej aplikacji.

/A lub /U. Parametry te przekształcają strumień bajtów przesyłany do potoku (pipe) lub plików przekierowywanych (file redirection) na standard ANSI (/A) lub Unicode (/U). Domyślną wartością jest /U.

/T:fg. Parametr ten ustawia kolory tła i tekstu dla sesji.

/F:OFF. Parametr ten blokuje automatyczne uzupełnianie nazw plików i katalogów (name completion). Automatyczne uzupełnianie nazw oszczędza wpisywania w linii poleceń, automatycznie dopełniając podaną wartość na podstawie kilku pierwszych znaków. Działa to jak stary znak zachęty (prompt) Dbase po zażyciu sterydów.

Automatyczne uzupełnianie ścieżki

System Windows 2000 i Windows NT można skonfigurować w ten sposób, by rozpoznawały znaki specjalne w wierszu poleceń i uzupełniały ścieżkę lub nazwę pliku. Domyślnie znakiem specjalnym jest kombinacja klawiszy Ctrl+I. Zamiast wpisywania CD \Dokumenty i ustawienia można wpisać CD Dok, a potem nacisnąć Ctrl+I, uzupełniając ścieżkę.

Jeśli wiele plików lub podkatalogów zaczyna się na te same litery, należy kilkakrotnie naciskać Ctrl+I, przechodząc do kolejnych nazw.

Uzupełnianie nazw kontrolowane jest przez wartość Rejestru HKLM|Software|Microsoft|Command Processor|CompletionChar, którą domyślnie jest 0x9h (Ctrl+I).

Wpisując polecenie CMD /F:ON znak uzupełniania nazw katalogów zmienia się na Ctrl+D (0x4h), a znak uzupełniania nazw plików na Ctrl+F(0x6h). Wtedy naciskanie Ctrl+D powoduje wyłącznie przechodzenie do kolejnych nazw katalogów, podczas gdy Ctrl+I rozpoznaje zarówno nazwy plików, jak i nazwy katalogów.

Domyślna wartość Rejestru CompletionChar może być zmieniona.

• /Y. CMD zawiera wiele rozszerzeń standardowych poleceń wewnętrznych. Niektóre mogą zakłócać działanie starszych plików wsadowych. Za pomocą parametru /Y można wyłączyć działanie rozszerzeń podczas całej sesji lub w pliku wsadowym przed wpisaniem polecenia, które sprawia kłopoty. Zamiast tego parametru do wyłączenia działania rozszerzeń dla wszystkich sesji można wykorzystać następującą pozycję Rejestru:

Key: HKCU|Software|Microsoft|Command Processor

Value: EnableExtensions

Data: 0

• /X. Parametr ten aktywuje rozszerzenia CMD po ich zablokowaniu.

• &&. Interpretator CMD umożliwia wprowadzanie wielu poleceń w jednym wierszu oddzielonych znakami &&. Na przykład, aby ćwiczyć koordynację ręki i oka, która ma podstawowe znaczenie dla dobrego administrowania systemem, można jednocześnie uruchomić Sapera, Pinball i Solitaire w następujący sposób:

winmine && sol && pinball

• /S. Parametr ten umożliwia specjalną obsługę znaków cudzysłowu “ (quote). W normalnych warunkach, jeśli interpretator zauważy ten znak na początku łańcucha znaków, usuwa również końcowy cudzysłów, jeśli taki jest, a następnie uruchamia odpowiedni program. Na przykład wprowadź w wierszu poleceń dwuwyrazową nazwę pliku mapy bitowej c:\>prairie wind.bmp. CMD wyświetli komunikat o błędzie `prairie' is not a recognized command. Jeśli zostanie wpisany łańcuch znaków w postaci c:\>”prairie wind.bmp”, CMD potraktuje to jako jeden łańcuch, uruchomi Paintbrusha i załaduje mapę bitową. Łańcuch znaków w postaci c:\>”prairie wind.bmp (bez końcowego cudzysłowu) zostanie potraktowany również jako jeden ciąg znaków. Zastosowanie parametru /S powoduje, że wymagana jest prawidłowa składnia. Wpisanie c:\>”prairie wind.bmp /s spowoduje wyświetlenie komunikatu o błędzie. Parametr /S może być wykorzystany w pliku wsadowym do sprawdzania poprawności danych wprowadzanych przez użytkownika.

Rozszerzenia poleceń wewnętrznych CMD

CMD posiada zestaw poleceń wewnętrznych systemu DOS, ale kilka z nich jest zmodyfikowanych lub rozszerzonych, aby uprościć pracę z wierszem poleceń i poprawić działanie plików wsadowych. Poniżej znajduje się lista najczęściej wykorzystywanych rozszerzeń poleceń CMD:

• DEL. W systemie DOS polecenie DEL /S usuwa plik ze wszystkich miejsc, w których pojawia się na dysku, ale podaje, gdzie szuka tego pliku. Wersja polecenia DEL /S dla konsoli CMD podaje tylko komunikat o miejscu znalezienia pliku i jego usunięciu.

• CD. CD /D umożliwia przejście z danego katalogu bezpośrednio na inny dysk, włączając w to dyski sieciowe. Na przykład jeśli bieżąca sesja dotyczy dysku C:\ to wprowadzając polecenie w postaci cd /d e:\anydir można przenieść się bezpośrednio do katalogu \anydir na dysku E:. Polecenie ma jeszcze jedno, mniej widoczne rozszerzenie. Analizator syntaktyczny (parser) przyjmuje, że spacje są częścią ścieżki dostępu do katalogu, więc można wprowadzić polecenie w postaci cd c:\Daily Sales Totals.

• SET. Można poszukiwać zmiennych środowiskowych, korzystając z polecenia SET, po którym następuje kilka początkowych liter nazwy zmiennej. Aby znaleźć na przykład wszystkie zmienne zaczynające się na literę S, należy użyć polecenia w postaci SET S. Bardziej znaczącym rozszerzeniem jest możliwość wykorzystywania operatorów arytmetycznych i logicznych w przypadku polecenia SET z parametrem /A. Przykładem może być wprowadzenie nowej zmiennej środowiskowej VAR3, która ma być sumą dwóch zmiennych środowiskowych VAR1 i VAR2. Można to zrobić za pomocą polecenia SET w postaci:

Set /A var3=var1+var2

Należy zwrócić uwagę, że wykorzystując parametr /A nie trzeba wpisywać zmiennych środowiskowych w postaci %VAR1% i %VAR2%.

• IF. Funkcja IF w systemie DOS jest zwykle wykorzystywana do obsługi błędów, np. IF errorlevel 1 GOTO error_label lub sprawdzania, czy dany plik istnieje, np. IF EXIST file_name GOTO action_label. Mając funkcję IF z parametrem /I można wykorzystywać relacje logiczne, np IF /I %var1% LSS %var2% GOTO action_label.

• CALL. Rozszerzenia funkcji CALL w systemie Windows 2000 są spełnieniem marzeń szalonego programisty. Umożliwiają stosowanie etykiet jako argumentów polecenia CALL np. call :label_argument. Wykorzystując tę właściwość trzeba pamiętać, że polecenie CALL wywołuje inną sesję CMD i w związku z tym tracone są wszystkie wartości nadane zmiennym środowiskowym w pierwszej sesji. Po zakończeniu działania sesja wywołana poleceniem CALL, powraca do pliku wywołującego do linii znajdującej się bezpośrednio pod linią zawierającą polecenie CALL.

• SHIFT. Funkcja ta przesuwa listę argumentów o jeden. Parametr /N umożliwia określenie pozycji, od której zacznie się przesuwanie. Na przykład jeśli dla 4 argumentów użyte zostanie polecenie SHIFT w postaci: shift /3, to końcowy porządek zmiennych będzie następujący: %1, %2, %4.

• GOTO. Rozszerzenie rozpoznaje specjalną etykietę: EOF, która powoduje przejście na koniec pliku (End of File) niezależnie od tego, w której części programu się znajduje. Jest to szybki sposób wyjścia z pliku wsadowego bez konieczności definiowania etykiety końca pliku EOF.

• MD lub MKDIR. Rozszerzenia te mogą być wykorzystywane do zbudowania od razu całej struktury katalogów. Na przykład polecenie MD \MiddleEarth\Shire\Hobbiton\BagEnd powoduje utworzenie wszystkich katalogów ścieżki. Taką sztuczkę można wykonać dla innego dysku. Pracując na przykład na dysku C: można wprowadzić polecenie C:\>MD E:\Elves\Men\Halflings tworząc katalogi na dysku E:.

Jeśli w ścieżce dostępu znajdą się spacje pomiędzy nazwami katalogów, to rozszerzenia MD zinterpretują to jako nazwy oddzielnych katalogów. Na przykład polecenie md C:\First Quater Results powoduje utworzenie trzech katalogów w katalogu głównym na dysku C:

C:\First

C:\Quater

C:\Results

• FOR /D. Polecenie FOR służy do tworzenia pętli programowych. Podstawowa składnia tego polecenia to: FOR batch_variable IN some_namespace DO some_command. Rozszerzenia polecenia FOR zawierają kilka pożytecznych parametrów. Polecenie FOR /D umożliwia stosowanie identyfikatorów swobodnych (wildcards) w parametrach wyrażenia IN. Jeśli na przykład plik wsadowy ma wyświetlić zawartość katalogu z wyłączeniem plików, należy użyć następującego polecenia: FOR /D %1 IN (*) DO @echo %1.

• FOR /R. Działanie podane w instrukcji DO dotyczy katalogu zapisanego w wyrażeniu FOR. Jeśli katalog zawiera podkatalogi, to instrukcja DO przechodzi do każdego podkatalogu. Na przykład do wyświetlenia listy plików z rozszerzeniem TXT zapisanych w katalogu MY_FILES i jego podkatalogach służy polecenie FOR /R c:\my_files %1 IN (*.TXT) DO @echo %1.

• FOR /L. Polecenie to wykonuje daną operację określoną liczbę razy. Składnia polecenia jest następująca: FOR /L %variable IN (start, step, end) DO command %variable. Przykładowym zastosowaniem może być dodawanie wielu kont użytkowników w celach testowych. Polecenie FOR /L %1 IN (100, 1, 10000) DO Net User /add User%1 dodaje 9900 użytkowników o nazwach User100, User101, User102 itd.

• FOR /F. Parametr ten powoduje podzielenie pliku na wiersze, każdego z wierszy na słowa (tokens) i wyświetla wybrane słowa. Składnia jest następująca: FOR /F „opcje analizy składni” %variable IN (pliki) DO command %variable. Część „opcje analizy syntaktycznej” musi być umieszczona w cudzysłowie i zawierać przynajmniej jedną z poniższych opcji:

eol= Wprowadź specjalny znacznik końca wiersza (end-of-line). Odczytując standardowy plik tekstowy ASCII ze znacznikami końca wiersza systemu DOS, można opuścić tę pozycję.

skip= Podaj liczbę początkowych wierszy, które mają być pominięte. Odczytując na przykład plik z czterowierszowym nagłówkiem, można zacząć czytanie pliku od wiersza numer 5 podając opcję „skip=4”.

delims= Podaj znak, który jest ogranicznikiem poszczególnych słów (tokens) w wierszu. Jeśli w pliku jako ogranicznik występuje znak przecinka, opcja ma postać delims=,.

token= Określa, których słów (tokens) dotyczy instrukcja FOR /F. Jeśli na przykład w wierszu jest 5 pozycji, a operacja ma dotyczyć tylko drugiego i czwartego, należy wprowadzić opcję w postaci „token=2,4”.

Poniżej zamieszczono przykład wykorzystania polecenia FOR /F. Mamy plik TEST.FOR w postaci:

One, two, three, four

Four, five, six, seven, eight, nine

Wprowadzając polecenie w postaci:

FOR /F “tokens=1,3-4 delims=,” %1 IN (testfor.txt) DO @echo %1 %j %k

Otrzymamy w wyniku:

One three four

Five seven eight nine

• Opcje specjalne rozszerzeń zmiennych wsadowych (batch variable expansion). W przypadku pliku wsadowego (batch file), na przykład test.cmd, który zawiera polecenia wykorzystujące zmienne plików wsadowych (batch file variable) takich jak %1, %2 itd., CMD umożliwia stosowanie specjalnych parametrów modyfikujących. Oto lista tych parametrów:

%1 — standardowa obsługa zmiennej.

%~f1 — podaje pełną nazwę ścieżki dostępu zmiennej %1.

%~d1 — podaje symbol (literę) dysku zmiennej %1.

%~p1 —podaje ścieżkę zmiennej %1.

%~n1 — podaje nazwę pliku zmiennej %1.

%~x1 — podaje rozszerzenie pliku zmiennej %1.

%~s1 — zmienia opcję n i x, podając nazwę pliku w postaci 8.3 zamiast nazwy długiej.

%~$PATH:1 — przeszukuje katalogi podane jako parametr PATH, dopóki nie znajdzie pozycji dotyczącej %1. Następnie wartością tego parametru zostanie ścieżka dostępu do zmiennej %1. Jest to przydatne przy uruchamianiu pliku wsadowego w innym katalogu niż argument. Jeśli plik nie zostanie znaleziony, parametr ten zawiera łańcuch pusty.

Rozszerzenie poleceń zewnętrznych CMD

Większość poleceń zewnętrznych w Windows 2000 jest podobnych do swoich odpowiedników w systemie DOS. Poniższe polecenia nie są opisane gdzie indziej, mogą okazać się przydatne.

• PUSHD i POPD. Są to polecenia wzięte prosto z systemu UNIX. Do zmiany katalogów należy stosować PUSHD zamiast CD. Jeśli nastąpiło przejście do nowego katalogu, CMD pozostawia wskaźnik (pointer) do starego katalogu. Później można powrócić do pierwotnego katalogu korzystając z polecenia POPD. Załóżmy, że bieżącym katalogiem jest C:\Presidents\20thCentury\Democrats i należy przejść do katalogu C:\Presidents\18thCentury\Whigs, a potem powrócić do katalogu pierwotnego. Można to zrobić za pomocą następującego polecenia:

PUSHD C:\Presidents\18thCentury\Whigs : :Zmiana katalogu

POPD :Powrót do katalogu pierwotnego

Wydając kilka poleceń PUSHD z rzędu można umieścić na stosie kilka katalogów. Każde następne polecenie POPD zwalnia jedno miejsce na stosie, dopóki nie nastąpi powrót do katalogu początkowego.

• PROMPT. CMD zawiera kilka dodatkowych znaków, które można umieścić w wyrażeniu PROMPT i ułatwić w ten sposób przechodzenie pomiędzy katalogami za pomocą poleceń PUSHD/POPD. Symbol $+ dodaje znak + do znaku zachęty (prompt), kiedy wykorzystuje się polecenie PUSHD, a usuwa go przy powrocie za pomocą polecenia POPD. Wprowadzając na przykład $p$+$g, po trzykrotnym użyciu polecenia PUSHD zostanie wyświetlony następujący znak zachęty (prompt):

C:\New_Directory+++>.

• ASSOC i FTYPE. Jedną ze specjalnych cech interpretatora CMD jest zdolność otwierania plików danych stosując związane z nimi aplikacje, rozpoznawane na podstawie rozszerzenia plików danych. Wprowadzenie na przykład następującego łańcucha znaków C:\>"furry dog.bmp" spowoduje otwarcie przez CMD pliku mapy bitowej za pomocą Paintbrusha. Więcej informacji poniżej.

Kojarzenie plików

Za pomocą poleceń ASSOC i FTYPE można tworzyć skojarzenia dla rozszerzeń nazw plików.

• Polecenie FTYPE tworzy klucz, kojarzący typ pliku z określonym programem. Na przykład typ pliku TXTFILE jest związany z programem NOTEPAD.EXE.

• Polecenie ASSOC tworzy klucz, kojarzący rozszerzenie nazwy pliku z określonym typem pliku. Na przykład rozszerzenie .TXT jest związane z typem TXTFILE.

Poniżej zamieszczono przykład wykorzystania tych poleceń. Aby automatycznie rozpakowywać (unzipping) pliki podczas przeszukiwania zasobów Internetu, za pomocą programu PKUNZIP.EXE po dwukrotnym kliknięciu nazwy pliku z rozszerzeniem ZIP należy wpisać polecenia w następującej postaci:

ftype zipfile=c:\zip\pkunzip.exe

assoc=.zip=zipfile

• COLOR. Polecenie to zmienia kolory tła i tekstu w bieżącym oknie sesji i może służyć do rozróżniania sesji w trybie wiersza poleceń (command sessions) dla różnych aplikacji. W tym celu należy utworzyć plik wsadowy (batch file), który wydaje polecenie COLOR, a następnie uruchamia aplikację.

Kolor w trybie tekstowym

Niektóre aplikacje znakowe zmieniają tryb znakowy na tryb graficzny i w takim przypadku ustawienia polecenia COLOR nie mają znaczenia. Polecenie COLOR przyjmuje jednobajtowe argumenty określające kolorystykę. Bajt jest dzielony na dwie cyfry szesnastkowe. Pierwsza z nich określa kolor tła, a druga kolor tekstu. Na przykład COLOR 47 oznacza czerwone tło i biały tekst. Dostępną paletę kolorów przedstawia tabela 16.2

Tabela 16.2. Oznaczenia szesnastkowe kolorów

Kolor	Oznaczenie szesnastkowe
Czarny (Black)	0
Niebieski (Blue)	1
Zielony (Green)	2
Akwamaryna (Aqua)	3
Czerwony (Red)	4
Żółty (Yellow)	6
Biały (White)	7
Szary (Gray)	8
Jasnoniebieski (Light Blue)	9
Jasnozielony (Light Green)	A
Jasna akwamaryna (Light Aqua)	B
Jasnoczerwony (Light Red)	C
Jasnopurpurowy (Light Purple)	D
Jasnożółty (Light Yellow)	E
Jaskrawobiały (Bright White)	F

Polecenie START

Polecenie START jest jednym z najbardziej przydatnych poleceń zewnętrznych, więc poświęcenie mu szczególnej uwagi jest usprawiedliwione. Za pomocą tego polecenia można konfigurować pamięć wspóldzieloną (shared memory), przydzielać aplikacjom priorytety itp. Pracuje poprawnie dla dowolnego programu. Poniżej przedstawiono listę parametrów polecenia START i ich zastosowanie:

• /I. Środowiskiem pracy nowo uruchomionej aplikacji jest pierwotne środowisko pracy macierzystego okna interpretatora CMD. Nie przekazuje się żadnej zmiennej środowiska pracy (environment variable) CMD dodanej podczas trwania sesji.

• /MIN. Minimalizuje okno nowo uruchomionej aplikacji do Paska zadań (Task Bar). Dotyczy to wszystkich aplikacji, systemu Windows, znakowych, 32-bitowych i 16-bitowych.

• /MAX. Otwiera okno nowo uruchomionych aplikacji. Aplikacje znakowe uruchamiane są w oknie, a nie w trybie pełnoekranowym, a okno nie ma pasków przewijania.

• /SEPARATE. Uruchamia aplikacje 16-bitowe systemu Windows w osobnym obszarze pamięci oraz z nowymi wątkami NTVDM i WOWEXEC. Uruchamianie aplikacji 16-bitowych w oddzielnych obszarach pamięci zapewnia stabilność systemu w przypadku aplikacji, które mogą działać nieprawidłowo. Parametr ten umożliwia uruchomienie aplikacji 16-bitowych jako oddzielne wątki (threads), co zezwala na pracę wielowątkową (multithread performance), zamiast działania wszystkich aplikacji 16-bitowych jako jednego wątku (thread), jak to się robi domyślnie w systemach Windows 2000 i Windows NT.

• /SHARED. Uruchamia 16-bitowe programy systemu Windows we wspólnym obszarze pamięci. Jeśli nie istnieje wspólny wątek NTVDM i WOWEXEC, to jest on tworzony domyślnie.

• /IDLE, /NORMAL, /HIGH, /REALTIME. Parametry te określają priorytet aplikacji. System Windows 2000 wykorzystuje priorytety wątków (thread priority) do sterowania przerwaniami programowymi (software interrupts). Istnieją 32 poziomy priorytetów, ponumerowane od 0do 31. Kiedy wątek (thread), który ma określony priorytet, wysyła przerwanie programowe, system maskuje wszystkie przerwania wysyłane przez wątki (threads) o niższych priorytetach. Gwarantuje to, że aplikacje o niższym priorytecie, takie jak aplikacje użytkownika, nie przejmą kontroli nad wątkami (threads) o wyższym priorytecie, takimi jak składniki systemu operacyjnego. Wątkom (threads) uruchomionym przez dany proces nadaje się priorytety, zależnie od priorytetu procesu macierzystego. Priorytety dzielą się na cztery kategorie: Idle, Normal, High i Realtime. Nadając priorytet nieodpowiedni dla danej aplikacji, można obniżyć wydajność systemu. Inaczej mówiąc: „Nie wolno stosować polecenia start /realtime excel do zwiększenia szybkości obliczeń dokonywanych przez arkusz kalkulacyjny”.

• /WAIT. Polecenie START domyślnie otwiera nową sesję i przekazuje kontrolę nad poprzednią sesją do wątku CMD, który jest jego właścicielem. Parametr /WAIT wstrzymuje pierwotną sesję CMD dopóki aplikacja uruchomiona przez polecenie START nie zakończy się. Jest to przydatne, jeśli w pliku wsadowym (batch file) trzeba uruchomić kilka aplikacji, a każda z nich musi czekać na zakończenie poprzedniej.

• /B. Parametr ten powoduje uruchomienie nowej aplikacji w istniejącym oknie sesji, zamiast tworzenia nowego okna. Ten sam efekt daje uruchomienie aplikacji bez polecenia START, tak więc parametr w rzeczywistości nie jest przydatny. Może być przyczyną problemów dla aplikacji zmieniających tryb ze znakowego na graficzny, chociaż wyglądają na aplikacje pracujące w trybie znakowym. Parametr /B powoduje również zablokowanie obsługi kombinacji klawiszy Ctrl+C, więc jedynym sposobem przerwania pętli programu jest naciśnięcie Ctrl+Break.

Rozszerzenia polecenia START umożliwiają określenie nazwy katalogu zamiast programu lub pliku wykonywalnego. Na przykład polecenie w postaci start .. daje w wyniku okno Mój komputer (My Computer) przedstawiające zawartość katalogu macierzystego.

Konfigurowanie interfejsu konsoli

Każdy z użytkowników pracuje z aplikacjami DOS-owymi na swój sposób. Użytkownik, który traci wzrok, może używać monitora 21-calowego i chce mieć duże okno sesji i dużą czcionkę. Inny może życzyć sobie, aby tło było niebiesko-zielone (cyan), a litery zielone. Lista życzeń nie ma końca.

Poprzez kliknięcie prawym klawiszem myszy na ikonę w górnym lewym rogu okna sesji CMD i wybranie z menu pozycji Właściwości (Properties), zostanie uruchomione okno Cmd.exe Właściwości (Cmd.exe Properties). Te same czynności w przypadku sesji COMMAND spowodują pojawienie się okna NTVDM Właściwości (NTVDM Properties). Na rysunku16.26 przedstawiono przykładowe okno NTVDM Właściwości (NTVDM Properties). Porównując obydwa okna widać, że można je wykorzystać do zmiany czcionek, kolorów i rozmiarów bufora. Widać także, że okno właściwości NTVDM zawiera wiele parametrów dotyczących wirtualnego środowiska systemu DOS (virtual DOS environment). Niezbyt sprawna obsługa pamięci, ekranu i skrótów w systemie DOS jest zachowana w środowisku VDM, a konfiguruje się ją poprzez właściwości NTVDM.

--> Rysunek 16.26. Okno NTVDM Właściwości (NTVDM Properties) otwarte poprzez okno konsoli COMMAND.COM.[Author:E]

Po dokonaniu zmian ustawień okna sesji można zapisać je, by były stosowane do wszystkich okien o tej samej nazwie lub odnosiły się tylko do aktualnego okna.

Zmiany ustawień okien sesji CMD dokonywane są w następujący sposób:

• Jeśli zmiany domyślnych parametrów dokonuje się, gdy okno sesji CMD jest otwarte, to zmiany te są zapisywane w pozycji Rejestru HKCU|Console i dotyczą wszystkich sesji CMD.

• Jeśli zmiany właściwości sesji CMD dokonuje się, gdy określona aplikacja jest uruchomiona, to zmiany są zapisywane w pozycji Rejestru HKCU|Console|PATH_ExecutableName. Zmiany te obowiązują tylko wtedy, gdy uruchamia się daną aplikację z danego katalogu. (Rejestr nie przyjmuje spacji w ścieżce dostępu. Edytor Rejestru automatycznie wpisuje znaki podkreślenia).

Zmiany ustawień okna sesji COMMAND obowiązują we wszystkich oknach sesji 16-bitowych, ponieważ wszystkie wykorzystują NTVDM. Zmiany te dotyczą klucza Rejestru HKCU|Console|C:\_WINNT_System32_ntvdm.exe. W przypadku wyboru opcji zapisu zmian tylko dla bieżącego okna, system tworzy dla danej aplikacji plik PIF.

Pliki PIF

Ustawienia konsoli dla sesji COMMAND dotyczą wszystkich programów DOS-owych. Jeśli trzeba wprowadzić dla któregoś z programów jakieś specyficzne ustawienia, muszą one zostać umieszczone w pliku PIF (Program Information File) tego programu. Starsze wersje systemu Windows NT i system Windows 3.x zawierają edytor plików PIF. System Windows NT 4 i system Windows 2000 tworzą pliki PIF w locie podczas tworzenia skrótów (shortcut) do aplikacji 16-bitowych systemu DOS lub Windows. Tworzenie plików PIF opisano poniżej:

Procedura 16.19. Tworzenie plików PIF

1. Otwórz Eksploratora i poszukaj aplikacji 16-bitowej.

2. Kliknij prawym klawiszem myszy na odpowiedniej ikonie i z menu wybierz pozycję Utwórz skrót (Create shortcut). Pojawi się nowa ikona, utworzona na podstawie domyślnej ikony systemu MS-DOS, o nazwie Skrót do <nazwa_pliku> (Shortcut to <filename>).

3. Otwórz okno Właściwości (Properties) nowej ikony. Ustawienia dotyczące pamięci i wyświetlania zapisane w pliku PIF są wykorzystywane przez NTVDM zamiast domyślnych ustawień konsoli skonfigurowanych w Panelu sterowania (Control Panel). Istnieje kilka wyjątków. Domyślne ustawienia czcionek zawsze mają pierwszeństwo. Pliki wsadowe (batch files) zawarte w pliku PIF są opuszczane. Opcja Pokaż pasek narzędzi (Display Toolbar) jest ignorowana. Okna COMMAND w systemie Windows NT nie mają pasków narzędzi.

4. Wybierz zakładkę Program. Naciśnij Windows NT. Pojawi się okno Windows plik PIF Ustawienia (Windows PIF Settings). Okno to zawiera wskaźniki do dwóch plików: AUTOEXEC.NT i CONFIG.NT, umieszczonych w katalogu \WINNT\System32. Pliki te wykorzystywane są zamiast plików AUTOEXEC.BAT i CONFIG.SYS do konfigurowania środowiska VDM. Dokładniejsze omówienie plików AUTOEXEC.NT i CONFIG.NT zawiera następny podrozdział.

5. Naciśnij OK, aby zamknąć okno Windows plik PIF Ustawienia (Windows PIF Settings).

Config.nt i Autoexec.nt

System Windows 2000 wykorzystuje pliki Config.nt i Autoexec.nt do konfigurowania środowiska pracy wirtualnego komputera DOS (VDM), tak jak system DOS wykorzystuje pliki Config.sys i Autoexec.bat. Standardowy plik Config.nt zawiera trzy wiersze:

dos=high, umb

device=%SystemRoot%\system32\himem.sys

files=20

Wykorzystywana wersja Himem.sys jest to specjalny program menedżera pamięci A20 (A20 handler), przeznaczony do pracy w środowisku VDM. Ustawia obszar HMA (High Memory Area) i pamięć expanded w przestrzeni adresowej systemu Windows 2000. CONFIG.NT może zawierać takie same pozycje, jak standardowy plik CONFIG.SYS:

• DEVICE. Może być stosowane razem ze specjalnymi wersjami HIMEM.SYS, ANSI.SYS i COUNTRY.SYS.

• EMM. Jeśli aplikacja wymaga obszaru pamięci expanded określonego rozmiaru (przykładem może być WordPerfect 5.1) wykorzystuje parametr RAM programu EMM386, tak samo jak w przypadku zwykłego EMM386.EXE. Należy upewnić się, czy w pliku PIF ustawiony jest ten sam rozmiar obszaru pamięci extended.

• FCBS. Obsługuje bardzo stare aplikacje systemu DOS, wykorzystujące File Control Blocks. Nieprawidłowe ustawienie tego parametru sygnalizowane jest przez aplikację komunikatem o błędzie „Insufficient Control Blocks”.

• FILES. Wartością tego parametru może być 100 lub 200. Pamięć zwykle nie stanowi problemu w środowisku VDM.

• INSTALL. Config.nt obsługuje ładowanie programów rezydentnych (TSR) przed plikiem Autoexec.nt. Sterowniki transmisji blokowej (block drivers) i sterowniki wymagające bezpośredniego dostępu do sprzętu nie są obsługiwane.

• LOADHIGH. Zastosowanie tak samo jak w pliku Config.sys.

• SHELL. Służy do ustawiania rozmiarów środowiska. To samo można zrobić za pomocą pliku PIF.

• STACKS. Zastosowanie takie samo, jak w przypadku pliku Config.sys.

System Windows 2000 i system Windows NT zawierają trzy dodatkowe polecenia wpływające na działanie programów w środowisku VDM:

• ECHOCONFIG. Domyślnie ustawienia dokonywane w plikach Config.sys i Autoexec.bat nie są wyświetlane na ekranie monitora, aby nie wprowadzać zamieszania przy ładowaniu środowiska VDM. Ustawienie parametru ECHOCONFIG jest przydatne w wykrywaniu usterek.

• NTCMDPROMPT. Uruchamiając sesję konsoli COMMAND, otrzymujemy 16-bitowy interpretator poleceń. Jeśli dodatkowo ma być dostępny 32-bitowy interpretator CMD, trzeba wykorzystać parametr NTCMDPROMPT.

• DOSONLY. Zapobiega wywołaniu przez sesję konsoli DOS-a interpretatora CMD. Parametr ten wykorzystuje się, jeśli programy rezydentne, zmienne środowiska i dyski sieciowe mają pozostać w pamięci dla określonej sesji COMMAND. Jest ważny w przypadku wywołań plików wsadowych zmieniających ustawienia środowiska pracy. Bez tego parametru nowe ustawienia dotyczące DOS-a, zostałyby utracone po zakończeniu działania tego pliku wsadowego.

Plik Autoexec.nt wykorzystuje się tak samo jak Autoexec.bat. Można ustawiać zmienne środowiska pracy, uruchamiać programy rezydentne (TSR) i wywoływać dodatkowe pliki wsadowe (batch files). Dzięki specjalnym sterownikom trybu rzeczywistego (real-mode drivers) systemu Windows 2000 w środowisku VDM widoczne są składniki systemu pracujące w trybie chronionym, takie jak: napęd CD-ROM (MSCDEXNT), sieć Windows (REDIR), sieć NetWare (NW16 i VWIPXSPX) i pamięć interfejsu trybu chronionego systemu DOS (DOS Protected-Mode Interface memory-DOSX). Poniżej zamieszczono przykład przedstawiający sposób ładowania przez VDM sterowników NetWare pracujących w trybie rzeczywistym (real-mode NetWare drivers):

lh %SystemRoot%\System32\mscdexnt.exe

lh %SystemRoot%\System32\redir

lh %SystemRoot%\System32\dosx

lh %SystemRoot%\System32\nw16

lh %SystemRoot%\System32\vwipxspx

Przy uruchamianiu programów rezydentnych (TSR) i wywoływaniu plików wsadowych (batch files) domyślnie uruchamiana jest konsola CMD, nawet jeśli użytkownik uruchomił pierwotnie interprtator poleceń COMMAND. Może to spowodować, że programy rezydentne (TSR) nie będą działać. Jeśli w danej sesji ma być uruchomiony tylko interpretator COMMAND.COM, należy umieścić w pliku Config.nt polecenie DOSONLY.

Można skopiować pliki Config.nt oraz Autoexec.nt i modyfikować je odpowiednio dla poszczególnych aplikacji. Jeśli na przykład ma zostać uruchomiony WordPerfect 5.1 i wykorzystywać pamięć expanded, można skopiować plik Config.nt do pliku Config.wp i dokonać odpowiednich zmian. Konieczne jest zachowanie istniejących ustawień, aby zagwarantować prawidłowe działanie pamięci i sterowników sieciowych.

Konfigurowanie sesji 16-bitowych wersji systemu Windows i zarządzanie nimi

W przypadku zmiany systemu Windows 3.x na system Windows 2000, program instalacyjny wykorzystuje istniejące pliki INI do utworzenia niezbędnych pozycji Rejestru, dotyczących wszystkich aplikacji zainstalowanych w komputerze, jak również konfiguracji systemu, jak na przykład informacje o ustawieniach pulpitu, grupy menedżera programów itp. System Windows 2000 odwzorowuje pliki INI w Rejestrze w kluczu HKLM\Software\Microsoft\Windows NT\CurrentVersion\IniFileMapping. Klucz ten i jego podklucze działają także jako wskaźniki aktualizacji innych części Rejestru. Na przykład jeśli aplikacja aktualizuje IniFileMapping\Win.ini\Colors, to taka sama aktualizacja dokonywana jest w kluczu HKCU\Control Panel\Colors.

W przypadku nowej instalacji systemu Windows 2000 program instalacyjny umieści podstawowe pliki WIN.INI i SYSTEM.INI w katalogu \WINNT. Aby aplikacje 16-bitowe mogły dokonywać wpisów do tych plików, zmienna środowiskowa %windir% będzie wskazywała na katalog \WINNT. W przypadku komputera z systemem operacyjnym wybieranym przy uruchamianiu (dual-boot machine), jeśli dokonano zmian w trakcie pracy z systemem Windows 3.x, to system Windows 2000 zastosuje te zmiany do Rejestru przy następnym uruchomieniu tego systemu.

Na tej samej zasadzie, jeśli system Windows 2000 dokona zmian dotyczących systemu Windows 3.x, próbuje jednocześnie zsynchronizować konfigurację, wpisując odpowiednie pozycje do plików WIN.INI i SYSTEM.INI. Oznacza to również, że błędy konfiguracji popełnione w jednym systemie wpływają również na drugi, więc czasem korzystanie z możliwości wyboru systemu operacyjnego przy uruchamianiu komputera nie rozwiązuje problemów.

Wskazówka dotycząca Rejestru: Automatyczne wpisywanie zmian do plików INI

Automatyczne wpisywanie zmian do plików INI może zostać wyłączone za pomocą poniższych kluczy Rejestru:

HKCU|Windows 3.1 Migration Status

HKLM|Software|Windows 3.1 Migration Status

Automatyczne wpisywanie można wymusić usuwając wyżej wymienione klucze i uruchamiając komputer ponownie.

W przypadku, gdy w jednym komputerze zainstalowane są razem aplikacje Win16 i Win32, mogą wystąpić niezgodności bibliotek DLL. Kontrolowanie wersji współużytkowanych bibliotek DLL staje się czarną robotą jeśli programista nadpisze najważniejszą bibliotekę DLL bez zapytania o pozwolenie lub, co gorsza, zachowa tę samą nazwę swoich bibliotek DLL, przenosząc aplikację ze środowiska 16-bitowego do 32-bitowego.

Kłopoty wynikają z tego, że w systemie Windows 2000 i systemie Windows 3.x biblioteki DLL są traktowane odmiennie. Wersja 16-bitowa systemu Windows, oszczędzając pamięć, ładuje jeden egzemplarz (instance) biblioteki DLL, a wszystkie programy uruchomione w danym komputerze korzystają z niej wspólnie. Aplikacje Win32 nie mogą współużytkować biblioteki DLL bezpośrednio, ponieważ każdy proces pracuje w oddzielnym obszarze pamięci. System Windows 2000 ładuje i zapisuje w pamięci obraz biblioteki DLL, a następnie wykorzystuje Menedżera pamięci wirtualnej (Virtual Memory Manager) i kopiuje odpowiednie strony pamięci do przestrzeni adresowej procesu wywołującego tę bibliotekę DLL.

System Windows 2000 umożliwia również obsługę aplikacji 16-bitowych, wykorzystujących 32-bitowe wywołania funkcyjne. Jest to tzw. thunking. Współpraca aplikacji 16-bitowych i 32-bitowych w systemach Windows 2000 i Windows NT jest lepsza niż w Windows 9x.

Aplikacje Win32 są również obsługiwane. Win32 jest to oprogramowanie 32-bitowe przeznaczone do uruchamiania w 16-bitowej wersji systemu Windows. Aplikacje Win32 szukają współużytkowanych bibliotek DLL, ale uruchamiane są w oddzielnym obszarze pamięci. Objawami braku bibliotek DLL lub ich pomieszania są komunikaty o błędach Nie znaleziono nazwa_pliku.DLL ( --> Cannot [Author:UP] find filename.dll) oraz Call to Undefined Dynalink. Można zaobserwować niepoprawne działanie programów wywołujących interfejsy Mail API (MAPI) i Telephony API (TAPI).

Resource Kit systemu Windows 2000 zawiera kilka narzędzi, które pomagają wyszukać takie niepokorne biblioteki DLL. Jednym z nich jest Tlist, dający obraz uruchomionych procesów i ich hierarchię.

C:\>tlist-t

System Process (0)

System (2)

smss.exe (20)

csrss.exe (24)

Winlogon.exe (34)

services.exe (40)

spoolss.exe (72)

RpcSs.exe (80)

tcpsvcs.exe (83)

tapisrc.exe (88)

rasman.exe (104)

pstores.exe (116)

lsass.exe(43)

nddeagnt.exe (57)

Explorer.exe (13) Program Manager

SysTray.Exe (141)

loadwc.exe (131)

Deskmenu.exe (119)

Winword.exe (59) Microsoft Word-TEST.DOC

cmd.exe (66) C:\cmd.exe -tlist -t

sol.exe (75) Solitaire)

TLIST.EXE (46)

Jest to przydatne przy wykrywaniu usterek bibliotek DLL, ponieważ można załadować program i uzyskać listę bibliotek DLL, z których korzysta.

C:\>tlist sol

75 sol.exe Solitaire

CWD: C:\

CmdLine: sol

VitualSize: 17 364 kB PeakVirtual Size: 21524 kB

WorkingSetSize: 820 kB PeakWorkingSetSize: 888 kB

Number of threads: 1

163 Win32StartAddr:0x02415f00 LastErr:0x00000002 State:Waiting

4.0.1371.1 shp 0x02410000 sol.exe

4.0.1381.4 shp 0x77f60000 ntdll.dll

4.0.1381.4 shp 0x77e70000 USER32.dll

4.0.1381.4 shp 0x77f00000 KERNEL32.dll

4.0.1381.4 shp 0x77ed0000 GDI32.dll

4.0.1381.4 shp 0x77dc0000 ADVAPI32.dll

4.0.1381.4 shp 0x77e10000 RPCRT4.dll

4.0.1371.1 shp 0x77370000 CARDS.dll

4.0.1381.4 shp 0x77c40000 SHELL32.dll

4.71.1008.3 shp 0x70c70000 COMCTL32.dll

4.20.0.6201 shp 0x779f0000 MSVCRT.dll

4.71.1008.3 shp 0x77780000 msidle.dll

Resource Kit zawiera także narzędzie o nazwie Dependency Walker, ładujące programy wykonywalne i wyświetla ich biblioteki DLL. Zaletą programu Dependency Walker dla programisty poszukującego błędów jest to, że wyświetla katalog źródłowy bibliotek DLL. Wadą tego narzędzia jest to, że pracuje tylko w środowisku 32-bitowym.

Dostępne jest również narzędzie, które pozwala sporządzić listę katalogów źródłowych i ich wewnętrznych numerów wersji o nazwie LISTDLLS, dostępne na stronie www.sysinternals.com. Oto przykład:

E:\ntinternals>listdlls -p sol

ListDLLs V2.0

Copyright © 1997 Mark Russinovich

http://www.ntinternals.com

----------------------------------------------------------------------------------------------------------------------

sol.exe pid:4b

Base Size Version Path

0x02410000 0xc000 4.00.1371.0001 C:\WINNT\system32\sol.exe

0x77f60000 0x5c000 4.00.1381.0004 C:\WINNT\system32\ntdll.dll

0x77e70000 0x54000 4.00.1381.0004 C:\WINNT\system32\USER32.dll

0x77f00000 0x5e000 4.00.1381.0004 C:\WINNT\system32\KERNEL32.dll

0x77ed0000 0x2c000 4.00.1381.0004 C:\WINNT\system32\GDI32.dll

0x77dc0000 0x3e000 4.00.1381.0004 C:\WINNT\system32\ADVAPI32.dll

0x77e10000 0x52000 4.00.1381.0004 C:\WINNT\system32\RPCRT4.dll

0x77370000 0x29000 4.00.1371.0001 C:\WINNT\system32\CARDS.dll

0x77c40000 0x13c000 4.00.1381.0004 C:\WINNT\system32\SHELL32.dll

0x70c70000 0x7b000 4.71.1008.0003 C:\WINNT\system32\COMCTL32.dll

0x779f0000 0x46000 4.20.0000.6201 C:\WINNT\system32\MSVCRT.dll

0x77780000 0x6000 4.71.1008.0003 C:\WINNT\system32\msidle.dll

Żadne z tych narzędzi nie pozwala na śledzenie działania programów 16-bitowych w środowisku NTVDM, ponieważ przestrzeń wirtualna ukrywa działanie programu. Jedynym sposobem śledzenia działania aplikacji 16-bitowych w środowisku VDM jest obserwacja ich wpływu na system Windows.

W następnym rozdziale

Instalowanie systemu Windows 2000 dochodzi do finału, ponieważ użytkownicy mają w sieci lokalnej stabilne i przyjazne środowisko pracy. Teraz nadszedł czas na poszerzenie środowiska pracy dla podróżników i użytkowników pracujących w domu. Biura oddalone, które nie mają stałego połączenia sieciowego również wymagają obsługi. I każdy chce mieć dostęp do Internetu. W następnym rozdziale opisano usługi zdalnego dostępu, rutowanie według potrzeb (demand-dial routing) i połączenia Internetowe.

71

Zmniejszyć spacje.

Sprawdzić sens tego kawałka zdania w oryginale. Proponuję: ..rozróżnia pomiędzy pozycjami menu Start w profilu użytkownika i w profilu Wszyscy użytkownicy...

Strona: 1
Gdzie indziej słowo "placeholder" było inaczej tłumaczone...

Strona: 1
Preserving - konserwacja, ochrona.

Strona: 1
To jest niepotrzebne

Strona: 1
Chodzi o klonowanie

Can not?

Dalej nazywa się „obowiązkowy”.

Propozycja: „jest dostarczonych wraz z systemem” lub „jest dostępnych w systemie”.

Propozycja: ...zostały wprowadzone w celu przystosowania do usług terminala, który obecnie jest częścią systemu. (Nie rozumiem, więc nie poprawiam.)

Strona: 1
Niekompletne tłumaczenie. Powinno być: ...dla tego skryptu, wartość nie jest wpisywana do %rootdrive% i skrypt kończy pracę.

Strona: 1
Brak rysunku!

Strona: 1
W tym miejscu nieudało się ustawić stylu : wyróżnienie+pogrubienie

Strona: 1
Nieprzetłumaczona tabela!

Za duże spacje.

Strona: 1
Wyróżnienie czy listing?

Liczby profilów?

Strona: 1
Brak angielskiej wersji polecenia

Strona: 1
Brak angielskiej wersji polecenia

Propozycja: NTVDM umożliwia aplikacjom DOS-owym swobodną pracę, ale jeśli...

Brak rysunku!

Can not?

---