Instalacja sieciowych aplikacji pod Windows

Wielu producentów dostarcza oprogramowanie, które sprawuje się dobrze - jeśli zainstalować je na pojedynczym komputerze. Natomiast w środowisku sieciowym pod Windows te same aplikacje odmawiają pracy. Nadszedł czas, aby producenci zdali sobie sprawę, że ich produkty muszą być przystosowane do środowiska sieciowego.

Wielu producentów dostarcza oprogramowanie, które sprawuje się dobrze - jeśli zainstalować je na pojedynczym komputerze. Natomiast w środowisku sieciowym pod Windows te same aplikacje odmawiają pracy. Nadszedł czas, aby producenci zdali sobie sprawę, że ich produkty muszą być przystosowane do środowiska sieciowego.

Większość administratorów instaluje Windows tak, by były osiągalne w całej sieci. Zasadnicza, wspólna część Windows wraz ze sterownikami, bibliotekami i plikami wykonywalnymi znajduje się wówczas we wspólnym katalogu na novellowskim serwerze plików (do którego mają dostęp wszyscy użytkownicy). Taka metoda instalacji jest rekomendowana jako kompromis między wydajnością systemu a trudnościami z jego zarządzaniem. Jednak w tak skonfigurowanym środowisku wiele popularnych aplikacji nie pracuje poprawnie.

Kilka przykładów

Pierwszym przykładem jest Lotus Notes. Procedura zakłada, że administrator instaluje pliki w Windowsach skonfigurowanych na pojedynczy komputer. W trakcie instalacji usuwane są pliki rozpoznawane jako pochodzące z poprzedniej wersji produktu. Może to mieć fatalne następstwa. Jestem administratorem sieci Novella dużego przedsiębiorstwa naftowego, będącego klientem naszej firmy komputerowej. W naszej sieci korzystaliśmy z pakietu 1-2-3 Release 4 for Windows. Podczas instalacji Notes, program zidentyfikował niesłusznie plik olecli.dll jako plik Notes i spowodował jego usunięcie. Tymczasem plik ten umożliwiał uruchomienie przez użytkowników aplikacji 1-2-3. W rezultacie, aby rozwiązać problem, musieliśmy doinstalować skasowany plik.

Innym przykładem krótkowzroczności producenta jest niepoprawna aktualizacja bibliotek dynamicznych (DLL) dostarczanych przez Microsofta. Biblioteki te obsługują wiele aplikacji. W trakcie instalacji Windows kopiowana jest konkretna wersja bibliotek. Aplikacja zakupiona u innego producenta wymaga czasami nowszej ich wersji. Jako część procedury instalacyjnej, aplikacja porównuje datę utworzenia plików DLL - oryginalnego otrzymanego z Windows oraz oferowanego z aplikacją. Jeśli biblioteka dostarczona z aplikacją jest nowsza, to program instalacyjny podmienia plik oryginalny. W teorii miało to zapewnić umieszczenie w serwerze najnowszej wersji bibliotek. W praktyce zainstalowałem ostatnio trzy programy, które pozostawiły w serwerze starszą wersję bibliotek. W pracy na pojedynczym komputerze jest to w zasadzie niegroźne, ale mój serwer służy trzystu innym użytkownikom sieci.

Innym wielkim producentem, który oferuje oprogramowanie źle współpracujące ze środowiskiem Windows uruchamianym w sieci, jest Hewlett-Packard. Jego produktem jest DeskJet 560c. Jako część procedury instalacyjnej, program rozpoznaje miejsce zainstalowania Windows - a następnie umieszcza wszystkie aplikacje wspomagające drukarkę w tym katalogu. Niestety, w przypadku pracy w sieci, katalog ten jest najczęściej wspólnym katalogiem Windows na serwerze. W rezultacie procedura instalacyjna podmienia oryginalny Print Manager występujący w Windows na jego dedykowany odpowiednik HP. Niestety program ten nie jest kompatybilny ze środowiskiem sieciowym. W serwisie producenta potwierdzono jedynie nasze spostrzeżenie.

Na szczęście nie wszystkie instalacje sprawiają problemy. Pozytywnym przykładem może być instalacja WordPerfecta for Windows w środowisku sieciowym Novella. Mimo, że standardowo program umieszcza swoje biblioteki we własnym katalogu, to przy instalacji w sieci pyta użytkownika, gdzie chciałby umieścić pliki DLL.

Porady dla producentów

Chciałbym podzielić się kilkoma wnioskami. Po pierwsze, producenci aplikacji powinni upewnić się, że programy instalujące ich produkt zawierają zarówno opcję instalacji indywidualnej jak i sieciowej. Po drugie, instalacja sieciowa powinna posiadać dwie wersje: pierwszą - przeznaczoną dla administratora (w której decyduje on o konfiguracji instalowanego programu - np. o nazwach katalogów, w których umieszczane są pliki) oraz drugą - przeznaczoną dla końcowego użytkownika (z limitowanym prawem do zmian konfiguracji).

A co najważniejsze, producenci powinni pisać procedury instalacyjne tak, aby pozostawały one zgodne z tradycyjnym sposobem instalacji Windows w sieciach. Procedura ta powinna umieszczać w katalogu Windows wyłącznie sterowniki i biblioteki Microsofta (i to po upewnieniu się, że umieszczana wersja jest nowsza od dotychczas tam rezydującej). Inne pliki powinny być umieszczane w katalogach instalowanej aplikacji.

Cierpliwość administratorów sieci ma swoje granice. Ci producenci, którzy chcą zatrzymać klientów, powinni zwrócić baczniejszą uwagę na zgodność stosowanych przez nich procedur instalacyjnych z sieciowym środowiskiem Windows.


TOP 200