Rozpoczęcie pracy z Microsoft Application Virtualization

Autor: Anthony Kinney

Opublikowano: 27 października 2008

Ten artykuł jest oparty na przedpremierowej wersji App-V. Wszystkie zawarte w nim informacje mogą ulec zmianie.

Zawartość strony

	Architektura App-V
	Jak działa pełna infrastruktura App-V
	Aktualizacja aplikacji wirtualnych
	Wersja 4.5
	Integracja App-V z menedżerem konfiguracji (Configuration Manager)

Microsoft Application Virtualization (lub App-V) jest bliska i droga mojemu sercu. App-V była wcześniej znana jako SoftGrid. Przeszedłem do firmy Microsoft, gdy ten kupił firmę Softricity, która utworzyła SoftGrid. Bardzo się cieszę, iż mam teraz możliwość napisania tego artykułu dla TechNet Magazine, ponieważ od tego czasu wiele się zmieniło.

Najlepszą metodą przybliżenia App-V jest porozmawianie o wyzwaniach w kategoriach zarządzania przedsiębiorstwem, w obliczu których stają specjaliści IT. Komputery używane obecnie w biznesie są przeładowane aplikacjami. Zanim aplikacja zostanie zainstalowana musi przejść prze długie testowanie regresywne, aby zapewnić, że będzie mogła współistnieć z innymi zainstalowanymi w systemie aplikacjami, bez wpływu na ich zdolność działania. Następnie, zanim aplikacja przejdzie do produkcji, musi przejść szereg procedur wdrażania. Ponieważ aplikacja jest w gruncie rzeczy dostępna tylko wtedy, gdy jest zainstalowana, użytkownicy są związani z określonymi komputerami. To jeszcze bardziej komplikuje złożone, lecz krytyczne projekty, takie jak migracje systemów operacyjnych i aplikacji, odświeżanie zabezpieczeń i planowanie odzyskiwania po awarii.

App-V zmienia to wszystko. Zamiast złożonego szeregu czasochłonnych działań, które zajmują zasoby, administracja komputerem za pomocą App-V staje się procesem łatwiejszym i bardziej zautomatyzowanym. Można w sposób prostszy i z lepszym rezultatem wdrażać, korygować, aktualizować i kończyć aplikacje.

Korzystając z App-V, użytkownik może usiąść przy dowolnym komputerze i mieć dostęp do swoich aplikacji. Aplikacje są dostarczane na żądanie, lecz działają tak, jakby były zainstalowane lokalnie. W ten sposób nie ma potrzeby instalowania komponentów aplikacji lub zmiany urządzenia hosta.

To zastosowanie wirtualizacji może radykalnie zmienić sposób zarządzania komputerami przez specjalistów IT. Nie zmieniając urządzenia hosta i uruchamiając zamiast tego wirtualizowane aplikacje, zyskujemy wiele korzyści, a wśród nich:

• mniej konfliktów między aplikacjami,
• szybsze i łatwiejsze aktualizacje aplikacji,
• możliwość uruchamiania wielu wersji tej samej aplikacji obok siebie,
• elastyczne aplikacje, które podążają za użytkownikami w trybie online oraz offline,
• zredukowane testowanie regresywne typu aplikacja-aplikacja.

Architektura App-V

Teraz popatrzmy na to, co w rzeczywistości dzieje się za kulisami platformy App-V. Platforma składa się z kilku głównych komponentów: sekwensera, bazy danych, klientów, serwera zrządzania, serwera przesyłania strumieniowego oraz konsoli zarządzania (patrz rysunek 1).

Rysunek 1: Plan środowiska App-V.

Rdzeniem systemu App-V jest klient App-V. Są dwa typy klientów, których można użyć – klient serwera terminala (Terminal Server Client) oraz klient pulpitu (Desktop Client). W obu przypadkach klient musi być zainstalowany na każdym serwerze pulpitu i terminala, na którym planujemy wdrażanie aplikacji wirtualnych. Klient zajmuje względnie małą przestrzeń na dysku. Instaluje on sterownik i ma widoczny komponent czasu wykonania dla użytkownika, który pojawia się jako wskaźnik zasobnika.

Klient gromadzi listę wirtualnych aplikacji z serwera zarządzania (Management Server) App-V i wyświetla dostępne aplikacje wirtualne. Obsługuje uruchamianie tych aplikacji (po zainicjowaniu przez użytkownika) oraz zarządzanie pamięcią podręczną po stronie klienta. Klient jest także odpowiedzialny za zarządzanie tworzeniem wirtualnego środowiska wykonawczego i zapewnienie, aby każde środowisko działało w swojej własnej wirtualnej „bańce”. Środowisko wirtualne obejmuje kilka komponentów, łącznie z wirtualnym rejestrem (Virtual Registry), wirtualnym systemem plików (Virtual File System) oraz wirtualnym menedżerem usług (Virtual Services Manager).

Dostępne są trzy opcje wdrażania infrastruktury w App-V 4.5: infrastruktura pełna, lekka oraz niezależna. Kiedy wdrażamy pełną infrastrukturę, obejmuje ona App-V Management Server oraz App-V Streaming Server (jest to nowy komponent, który jest dalej omówiony). Host serwera zarządzania App-V udostępnia oraz dostarcza scentralizowane aplikacje wirtualne, jak również aktualizuje aplikacje wirtualne, gdy wprowadzane są korekty lub aktualizacje.

Ten serwer zarządzania opiera się na systemie SQL Server do przechowywania bazy danych App-V, która zawiera konfiguracje oraz ustawienia dla aplikacji wirtualnych. Jako narzędzia do zarządzania dostarczaniem i kontrolowaniem uprawnień dla aplikacji wirtualnych trzeba użyć grupy Active Directory.

Do zarządzania ustawieniami i konfiguracją platforma App-V udostępnia usługę Microsoft .NET Framework Web, która może być ładowana na tym samym serwerze, pod warunkiem, że jest zainstalowana jako IIS. Ta usługa Web działa jako łącznik pomiędzy konsolą zarządzania App-V (App-V Management Console) – przystawką MMC (Microsoft Management Console) – oraz bazą danych App-V. Administratorzy mogą użyć konsoli do publikowania oraz zarządzania aplikacjami wirtualnymi, przypisywania grup Active Directory oraz kontrolowania ustawień serwera, jak również do uruchamiania raportów na temat użycia wirtualizowanych aplikacji (patrz rysunek 2).

Rysunek 2: Konsola zarządzania.

Lekka infrastruktura obejmuje serwer strumieniowy App-V, który daje możliwości transmisji strumieniowej, takie jak aktualizacja aktywna/pakietowa. Ta opcja nie wymaga Active Directory lub SQL Server, nie ma usługi konfiguracji pulpitu i brakuje w niej możliwości licencjonowania oraz pomiaru. Lekka infrastruktura pozwala jednak na dodanie możliwości strumieniowych do SCCM (System Center Configuration Manager) oraz rozwiązań wdrażania oprogramowania dla przedsiębiorstw (ESC) dostarczanych przez inne firmy.

W trybie niezależnym sekwenser App-V może tworzyć plik MSI, który automatyzuje dodawanie wirtualnej aplikacji (patrz rysunek 3). Plik MSI zawiera metadane, które pozwalają dowolnemu systemowi ESD rozpoznawać go i kontrolować wirtualizowaną aplikację. Ten tryb wymaga, aby klient przeszedł do trybu niezależnego, w którym dopuszczone są tylko aktualizacje aplikacji wirtualnych oparte na MSI, a transmisja strumieniowa w tym trybie nie jest dopuszczalna. Tryb niezależny daje organizacji możliwość wykorzystania możliwości izolacji App-V.

Rysunek 3: Sekwenser App-V.

Pliki MSI są bardzo elastyczne, mogą być uruchamiane całkowicie niezależnie za pomocą klienta App-V i nie wymagają żadnych komponentów serwera. Oznacza to, że mogą być wdrażane ręcznie, przy użyciu dysku lub poprzez dowolne, tradycyjne narzędzia wdrażania.

HTTP oraz HTTPS są teraz obsługiwanymi protokołami do transmisji strumieniowej w App-V 4.5. Pozwala to lepiej wykorzystywać wydajność transmisji strumieniowej wraz z szerszym zastosowaniem protokołów, szczególnie dla transmisji strumieniowej w bezpiecznych środowiskach sieci WAN oraz w Internecie.

 Do początku strony

Jak działa pełna infrastruktura App-V

Użytkownik loguje się na urządzeniu, na którym jest zainstalowany jeden z klientów (albo App-V Terminal Services, albo Desktop Client), a klient wysyła do serwera żądanie z listą aplikacji przypisanych do bieżącego użytkownika. Serwer komunikuje się z Active Directory, aby określić grupy, których członkiem jest użytkownik, a następnie zwraca listę aplikacji z powrotem do klienta. Klient zaczyna budowanie ogłoszeń dla wirtualnych aplikacji, które były przypisane do określonego użytkownika.

W tym procesie publikowania wykonywanych jest kilka działań:

• kopiowane są pliki konfiguracji,
• tworzone są ikony pulpitu,
• tworzone są łącza Wyślij do (Send To),
• tworzone są foldery menu Start,
• konfigurowane są typy plików.

Ten proces jest bardzo szybki i, co najważniejsze, zapewnia, że środowisko będzie wyglądać dokładnie tak, jak oczekuje użytkownik, bez widocznych zmian. Aplikacje wirtualne działają, tak jakby były zainstalowane lokalnie, lecz oczywiście nie zmieniają maszyny hosta. Ikony, zamiast wskazywać programy wykonywane, umieszczone w katalogu plików programów, wskazują klienta App-V, który opiera się na pliku programu uruchamiającego (plik OSD) dla potrzeb swojej konfiguracji.

Ważne jest, aby zauważyć, że ma to bardzo mały wpływ na sieć, ponieważ – inaczej niż w tradycyjnym wdrażaniu oprogramowania – nic nie jest instalowane. Daje to ogromne korzyści, szczególnie w środowiskach użytkowników mobilnych, ponieważ aplikacje są dostępne dla użytkownika, lecz nic nie jest faktycznie dostarczane, zanim aplikacja nie zostanie uruchomiona. Ta metoda ogłaszania jest stosowana jest również do dostarczenia funkcji aplikacji na życzenie oraz aplikacji mobilnych w App-V.

Kiedy użytkownik uruchamia wirtualną aplikację, klient czyta plik konfiguracji OSD, który jest zapisany na lokalnej maszynie. Informuje on klienta, którego protokołu użyć przy komunikacji z serwerami zarządzania App-V i na którym serwerze jest umieszczona aplikacja.

Właściwy serwer odpowiada klientowi, transmitując strumieniowo próg początkowego uruchomienia, który zwykle jest równy 20–40 procent pełnej aplikacji. Kiedy cały próg uruchomienia zostanie przesłany strumieniowo (ponownie tylko 20–40 procent aplikacji), wirtualna aplikacja jest gotowa do działania.

Transmisja strumieniowa jest rzeczywiście jednym z kluczowych elementów zmiany modelu wprowadzanej poprzez App-V. Może ona wysłać część aplikacji wystarczającą do działania, więc nie marnuje cennej przepustowości sieci. Wszystkie dane dostarczane do klienta są umieszczane w pliku lokalnej pamięci podręcznej danego urządzenia i wszystkie dalsze uruchomienia aplikacji są rozpoczynane z lokalnego bufora, co eliminuje dodatkowy ruch sieciowy.

Kiedy wirtualna aplikacja zakończy transmisję strumieniową, klienty budują izolowane środowisko chroniące aplikację przed zmienianiem maszyny lokalnej (innymi słowy, aplikacja nie zawiera śladów klienta). Klient pozwala jednak maszynie wirtualnej na dostęp do lokalnego system plików przy zapisywaniu oraz edycji plików, a to również umożliwia komunikację aplikacji z lokalnymi usługami (takimi jak drukowanie), jeśli tylko użytkownik ma odpowiednie uprawnienia w lokalnym systemie. Lecz dowolne zmiany dokonywane przez wirtualną aplikację w plikach lokalnego systemu są przekierowywane do wirtualizowanego środowiska, więc urządzenie hosta pozostaje niezmienione.

Kiedy aplikacja jest uruchomiona, dowolne funkcje, które nie były poprzednio użyte są dostarczane według potrzeb i buforowane do kolejnego użycia. Pozytywny aspekt tego jest taki, że tylko komponenty potrzebne użytkownikowi są ładowane przy początkowym uruchomieniu a funkcje, które nie są potrzebne nie zużywają zasobów sieciowych (nowa wersja zapewnia poprawę buforowania po stronie klienta, co pozwala na lepsze wykorzystanie pamięci podręcznej oraz przesyłanie strumieniowego w tle).

Weźmy przykładowo Microsoft Office Word. Większość użytkowników korzysta z korektora pisowni (bez niego nie mógłbym napisać tego artykułu), dlatego będzie on częścią początkowego uruchomienia. A co z funkcją Pomocy w programie Word? Niezbyt wielu użytkowników korzysta z tej funkcji, tak więc nie musi być dostarczana przy początkowym uruchomieniu. Zamiast tego będzie wysyłana użytkownikowi, gdy po raz pierwszy do niej wejdzie.

Kiedy użytkownik zakończy pracę i zamknie aplikację, klient rozmontowuje środowisko wirtualne i przechowuje wszystkie ustawienia użytkownika w lokalizacji właściwej dla użytkownika, tak aby mogło być ono zachowane i odbudowane przy następnym uruchomieniu. Niezależnie od tego, jaki odsetek aplikacji wirtualnych został przesłany strumieniowo, pozostają one w lokalnym buforze i są dostępne do następnego uruchomienia. A jeśli inny użytkownik zaloguje się do tego samego system hosta i uruchomi tę samą aplikacje wirtualną, nowy użytkownik będzie korzystać z aplikacji przechowywanej w buforze.

Aby usunąć ogłoszenia wirtualnej aplikacji, zwyczajnie usuwamy użytkownika z odpowiedniej grupy Active Directory. Aby całkowicie odinstalować wirtualną aplikację z komputera, można po prostu opróżnić bufor. Ponieważ aplikacja nigdy nie była w rzeczywistości zainstalowana lokalnie, nie będą pojawiać się denerwujące monity z pytaniami, „Czy chcesz usunąć tej wspólny komponent?"

Zwróćmy uwagę, że nawet jeśli wirtualna aplikacja jest przechowywana w buforze, nie oznacza to, że wszyscy użytkownicy mają do niej dostęp. W odróżnieniu od aplikacji zainstalowanych lokalnie, których użytkownicy mogą po prostu przeszukiwać lub poszukiwać pliki wykonywalne, do których nie mają uprawnień, nie istnieje żadna wizualna lub fizyczna reprezentacja faktu istnienia wirtualnej aplikacji, zanim użytkownik nie będzie miał nadanych do niej jawnych praw poprzez grupy Active Directory.

 Do początku strony

Aktualizacja aplikacji wirtualnych

Aktualizacja jest wykonywana przy użyciu sekwensera. Kiedy aplikacja zostanie skorygowana z uwzględnieniem aktualizacji, jest umieszczana w serwerze zarządzania App-V obok poprzedniej wersji. Przy następnym uruchomieniu aplikacji serwer powiadamia klienta, że została dokonana zmiana. Jeśli poprzednia wersja jest nadal używana, użytkownik ma do niej dostęp do momentu zamknięcia aplikacji wirtualnej. Przy kolejnym uruchomieniu, zmiany, które składają się na aktualizację są przesyłane strumieniowo do klienta i ładowane do bufora podręcznego, czego wynikiem jest zaktualizowana wersja aplikacji.

Powiedzmy, że mamy 1 000 użytkowników z uruchomionym programem Word 2000. Administrator musi zaktualizować Word 2000 (word2K.sft) na Word 2000 SP3, więc kopiuje plik word2K.sft poprzez stację sekwencjonującą i w sekwenserze wybiera opcję Open for Package Upgrade (Otwórz do aktualizacji pakietu). Wybierając tę opcję, administrator zaczyna pracę od ostatniego stanu pakietu. Może wtedy skopiować pliki DLL, uruchomić aktualizacje lub wykonać korekty w aplikacji wirtualnej, aby zaktualizować ją do wersji Word 2000 SP3. Następnie administrator zapisuje zaktualizowany pakiet.

Sekwenser automatycznie przydziela nazwę nowego pliku, word2K_2.sft, aby zapobiec zdublowaniu nazw plików oraz wskazać wersję sekwencjonowania. Nowy pakiet jest umieszczany w tym samym katalogu co stary pakiet na serwerze zarządzania App-V, tak że Word 2000 (word2K.sft) oraz Word 2000 SP3 (word2K_2.sft) ostatecznie znajdują się w tym samym katalogu. Administrator korzysta wtedy z konsoli zarządzania App-V, aby połączyć ze sobą te dwa pliki SFT.

Po stronie klienta użytkownicy, którzy mają otwartą aktywną sesję programu Word 2000 bez SP3 nadal normalnie działają. Użytkownicy, którzy uruchomią nową sesję aplikacji po dokonaniu tego połączenia przez administratora, otrzymają komunikat, że została wykryta zmiana. Klient zaczyna wtedy przesyłać strumieniowo tylko zmiany pomiędzy word2K.sft a word2K_2.sft, automatycznie aktualizując aplikację na Word 2000 SP3.

Ze względu na dynamiczną naturę aplikacji wirtualnych, cofnięcie zmian jest całkiem proste. Wystarczy powrócić do konsoli zarządzania App-V i usunąć nowo dodaną wersję. To powoduje, że po ponownym uruchomieniu klient wraca do poprzedniej wersji. Aby dane nie zachodziły na siebie, klient automatycznie czyści bufor i przesyła strumieniowo właściwy plik SFT. To jest dobry kompromis, gdy weźmiemy pod uwagę, co trzeba zrobić, aby cofnąć aktualizację aplikacji zainstalowaną fizycznie przy użyciu tradycyjnych narzędzi wdrażania oprogramowania.

Aby uświadomić sobie zalety App-V, trzeba najpierw utworzyć pakiety wirtualnych aplikacji. Tutaj do gry wchodzi sekwenser App-V. Wszelka wiedza i doświadczenie w pisaniu skryptów oraz tworzeniu pakietów dla tradycyjnych narzędzi wdrażania oprogramowania ułatwi przejście do sekwencjonowania (należy tu zwrócić uwagę, że samo sekwencjonowanie mogło by być tematem całego artykułu).

Większość rozwiązań wdrażania oprogramowania opiera sie na skryptach, które wychwytują sposób, w jaki aplikacja sama się instaluje, a następnie powielają ten proces na innej maszynie, eliminując potrzebę odwiedzania każdego komputera w celu instalowania lub aktualizowania aplikacji. Po zainstalowaniu aplikacji typowe narzędzia do wdrażania oprogramowania oczyszczają się z pakietów. Trzeba wtedy zainstalować wszelkie zależności, na których aplikacja może się opierać, uruchomić inne skrypty lub wykonać ręcznie kroki w celu skonfigurowania aplikacji do swoich potrzeb.

Fundamentalną zmianą w App-V jest to, że proces sekwencjonowania generuje obraz już istniejącej aplikacji, wraz z jej zależnościami oraz konfiguracjami. Może to być „odtworzone” przez klienta App-V bez zmiany urządzenia, na którym jest wykonywane.

Sekwenser tworzy wiele plików, z których najważniejszy jest plik SFT, zawierający wszystkie zasoby aplikacji, jej zależności oraz informacje o konfiguracji. W niektórych przypadkach może również zawierać wiele aplikacji. Nic więc dziwnego, że ten plik może być dość duży. Istnieje kilka opcji jego kompresji, lecz najważniejszą jest solidna wiedza na temat wydajności sieci i urządzenia. Tworzony przez sekwenser plik ikony (.ico) służy do wskazywania aplikacji wirtualnej, co sprawia, że działa, jakby była zainstalowana lokalnie.

Plik OSD jest również bardzo ważny, a jego dostępne opcje są niezliczone. Domyślnie jest to plik oparty na XML, który informuje klienta App-V, jak uruchamiać wirtualną aplikację. Plik OSD może być także modyfikowany, aby skonfigurować i kontrolować sposób uruchamiania i działania wirtualnej aplikacji. Gorąco polecam przeczytanie przewodnika dla administratora dotyczącego sekwencjonowania (Sequencing Admin Guide) oraz dokumentu o najlepszych praktykach sekwencjonowania (Sequencing Best Practices), aby zapoznać się z właściwościami i wartościami dostępnymi dzięki plikowi OSD.

Wreszcie, nowy plik manifest.xml zawiera informacje konfiguracji oparte na pakiecie i może być użyty do integracji z rozwiązaniami ESD innych firm oraz wdrożeniami MSI. Sekwenser może również generować plik MSI dla pakietu wirtualnej aplikacji. Można to wykorzystać do ładowania wirtualnej aplikacji do niezależnych (bezserwerowych) klientów oraz poprzez system ESD.

Sam sekwenser jest narzędziem opartym na kreatorze, prowadzącym nas podczas pakowania, poprzez proces instalowania aplikacji i przekształcania jej w aplikację wirtualną (patrz rysunek 4). Pierwszy krok pozwala nam skonfigurować domyślne właściwości dla pakietu. Te właściwości, które są przechowywane w pliku OSD, obejmują nazwę pakietu oraz komentarze. Niektóre zaawansowane ustawienia pozwalają nam określić serwer, z którego ma być dokonywana transmisja strumieniowa, katalog zawartości oraz systemy operacyjne, które powinny być obsługiwane przez pakiet.

Rysunek 4: Kreator sekwencjonowania.

Drugim krokiem jest instalacja, konfiguracja oraz testowanie aplikacji. Podczas instalacji sekwenser wyłapuje wszystkie zmiany robione w systemie lokalnym, łącznie z systemem plików, rejestrem oraz systemem. Kreator zawiera także kilka programów użytkowych, które na przykład umożliwiają integrację z Windows Update.

Kolejnym krokiem jest konfiguracja związków między typami plików oraz określenie, gdzie mogą być umieszczone skróty. Do standardowych miejsc należą menu Start, pulpit oraz pasek szybkiego uruchamiania, lecz można także tworzyć lokalizacje niestandardowe.

Następnie trzeba uruchomić aplikację i skonfigurować próg początkowego uruchomienia. Jest to etap, na którym App-V określa początkową porcję aplikacji, która powinna być dostarczona do klienta, aby aplikacja mogła zacząć działać.

Aby skonfigurować ten początkowy kod (zwykle określany jako blok funkcyjny – Feature Block 1, FB1), trzeba po prostu uruchomić aplikację i użyć najbardziej typowych funkcji potrzebnych użytkownikom. Przykładowo uruchamiamy program Word, a następnie włączamy korektor pisowni. Wszystkie biblioteki DLL, pliki lub klucze rejestrów wywoływane przez aplikację w tej fazie są automatycznie uznawane za część FB1. Wszelkie pliki, ustawienia lub komponenty nieużywane w tym momencie są dodawane do FB2. Podczas użycia aplikacji, klient otrzyma mapę pliku SFT, który wskazuje, gdzie zaczyna i kończy się FB1, a gdzie inne pliki znajdujące w FB2, tak aby klient mógł pobrać pliki potrzebne dla aplikacji.

Końcowy etap w procesie sekwencjonowania to sprawdzenie, czy wszystko jest właściwie skonfigurowane. Sekwenser wyświetla okno dialogowe pokazane na rysunku 5, które reprezentuje SFT i pozwala nam wprowadzać dowolne zmiany lub dodatki do pakietu.

Rysunek 5: Zatwierdzanie i ulepszanie ostatecznego pakietu.

 Do początku strony

Wersja 4.5

Po dwóch latach produkcji App-V 4.5 ma się ukazać pod koniec tego roku. To pierwsza wersja produktu firmy Microsoft, która ma się ukazać i według zapowiedzi wznieść wirtualizację na wyższy poziom poprzez wprowadzenie kilku kluczowych rozszerzeń, takich jak dynamiczna integracja wirtualnej aplikacji (Dynamic Virtual Application Interaction), zwiększona skalowalność oraz poprawione dopasowanie do wymagań Microsoft Internalization and Security.

Dynamic Virtual Application Interaction umożliwia interakcję między wirtualizowanymi aplikacjami. Ta interakcja nosi nazwę Dynamic Suite Composition (DSC). DSC nie zastępuje możliwości dodawania wielu aplikacji do tego samego pakietu. Zamiast tego oferuje nowe sposoby integracji zależności, oprogramowania pośredniego oraz rozszerzeń współużytkowanych przez aplikacje wirtualne.

Administratorzy mogą określić, które wirtualizowane aplikacje mogą ze sobą współdziałać. Załóżmy na przykład, że mamy pięć aplikacji Web, które wymagają tej samej wersji Java. W App-V 4.1 trzeba było dodawać tę samą wersję Java do każdego z pięciu osobnych pakietów. Przypuśćmy, że dana wersja Java wymaga zainstalowania programu korygującego. Administrator musiałby wtedy robić to dla pięciu różnych pakietów. Przy użyciu DSC Java może być spakowana raz, a następnie skonfigurowana jako pakiet do użycia przez wszystkie pięć aplikacji Web. W rezultacie aktualizowanie Javy wymagałoby od administratora tylko jednorazowej operacji.

Taki sam scenariusz jest stosowany dla oprogramowania pośredniego oraz modułów dodatkowych. Mam zamiar opisać w blogu inne scenariusze zastosowania, gdy Microsoft będzie bliżej daty wydania App–V 4.5 i ukończy ostatnie dodatki.

Poprawa skalowalności obejmuje zarówno przesyłanie strumieniowe, jak i infrastrukturę wewnętrzną. Komponenty wewnętrzne zostały zmodyfikowane, aby lepiej obsługiwać klastrowanie i scenariusze odzyskiwania po awarii, a przesyłanie strumieniowe jest bardziej przyjazne sieci WAN i LAN. Poprawki pochodzą z kilku kluczowych dodatków.

Po pierwsze mamy nowy komponent Streaming Server Component, który umożliwia transmisję strumieniową bez zapotrzebowania na wewnętrzną infrastrukturę Active Directory i SQL Server. Nadal otrzymujemy wszystkie korzyści dostarczania na żądanie i scentralizowanej aktualizacji pakietów, lecz bez poważnych wymagań dotyczących zaplecza. Będzie to szeroko stosowane w scenariuszach biur oddziałów i dla integracji z rozwiązaniami ESD innych firm.

Klient App-V również zyskał kilka rozszerzeń. Na przykład klient przechowuje teraz lokalnie wszystkie informacje, więc ta informacja może być śledzona niezależnie od tego, czy klient jest włączony do sieci. Pamięć podręczna klienta została również rozszerzona i ulepszona dla poprawy wydajności w scenariuszach z ograniczonym obszarem dysku. Zawiera także obsługę sekwencjonowania aplikacji nieanglojęzycznych, uruchamiania App-V w systemach operacyjnych z innym językiem niż angielski oraz lokalizacji w kilku innych językach.

 Do początku strony

Integracja App-V z menedżerem konfiguracji (Configuration Manager)

Do celów integrowania App-V z SCCM 2007 R2A w App-V 4.5 zaprojektowano kilka ulepszeń i nowych funkcji. Jak już pisałem, wirtualizacja i przesyłanie strumieniowe oferuje pewne możliwości dostarczania aplikacji, których nie zapewniają tradycyjne narzędzia wdrażania oprogramowania. Nie twierdzę tu, że App-V zastąpi te narzędzia, a raczej że App-V może je uzupełnić i rozszerzać.

Za pomocą tej integracji dostajemy całą skalowalność, raportowanie, rozpoznawanie urządzeń oraz funkcje WAN w SCCM ze wszystkimi funkcjami strumieniowego oraz izolacji, które zapewnia App-V. Oto kilka obszarów, które korzystają z integrowania tych dwóch technologii:

Dostarczanie aplikacji Integracja SCCM R2 obsługuje wszystkie możliwości dostarczania na żądanie, aplikacji mobilnych, progów początkowego uruchamiania oraz wdrażania aplikacji bez zmiany komputerów klientów.

Aktualizacje SCCM Punkty dystrybucji (Distribution Points, DP) podczas aktualizacji pakietów mogą wdrażać tylko zmiany w aplikacjach wirtualnych. Wprowadza to scentralizowaną możliwość powrócenia do starszych wersji wirualizowanych aplikacji za pomocą jednego kliknięcia.

Zarządzanie Wersja R2 wprowadza kreator ogłaszania nowej aplikacji wirtualnej, który pozwala administratorom wdrażać wirtualne aplikacje, a także tradycyjne pakiety oprogramowania i ogłoszenia z pojedynczej konsoli.

Upakowywanie Nie ma potrzeby ponownego pakowania aplikacji przy integrowaniu App-V z SCCM. Początkowe sekwencjonowanie aplikacji powinno być wykonane przy użyciu sekwencji App-V poza SCCM, lecz tak naprawdę administratorzy mogą aktualizować istniejące pakiety przy użyciu SCCM.

Licencjonowanie Aplikacje wirtualne mogą być śledzone dla celów licencjonowania i zliczania przy użyciu narzędzi istniejących w SCCM.

SCCM oferuje nową metodę wdrażania wirtualnych aplikacji do App-V przy użyciu standardowego protokołu branżowego BITS. Chociaż punkty dystrybucyjne SCCM mogą transmitować strumieniowo, istnieją przypadki, gdy transmisja strumieniowa nie jest idealną metodą wdrażania wirtualizowanych aplikacji. Przy wdrażaniu za pośrednictwem SCCM mamy dwie opcje. Możemy zastosować standardowe przesyłanie strumieniowego lub możemy użyć funkcji BITS QoS (Quality of Service), aby wykonać wdrożenie w sposób bardziej kontrolowany. Jest to także użyteczne w scenariuszach, w których chcemy przeładować pamięć podręczną przed uruchomieniem wirtualnej aplikacji przez użytkowników.

Wdrożenia na komputerach SCCM daje możliwość wdrażania wirtualizowanych aplikacji na określonych komputerach, jak również kontynuowania obsługi skierowanego na użytkownika podejścia platformy App-V. Może to być korzystne, gdy wdrażamy wirtualne aplikacje w laptopach, kioskach i komputerach laboratoryjnych. Może być również przydatne jako pomoc przy kontroli licencji, gdzie oprogramowanie może być licencjonowane na urządzenie, a nie nazwanych użytkowników.

Skalowalność Typowym problemem jest konieczność wdrożenia dwóch osobnych narzędzi, które w dużej części się pokrywają. Poprzez integrację skalowalności oraz zalet WAN w SCCM z zaletami izolowania i transmisji strumieniowej w APP-V, można użyć istniejącego SCCM, który dostarcza pojedyncze narzędzie do obsługi zarówno zarządzania, jak i wdrażania, bez zwiększania złożoności.

O autorze

Anthony Kinney jest specjalistą od sprzedaży, odpowiedzialnym za pakiet optymalizacji Microsoft Desktop Optimization Pack. Anthony przyszedł do firmy Microsoft w 2006 r., po nabyciu przez Microsoft firmy Softricity. Pracując w Softricity, Anthony pisał i projektował pierwszy program szkoleniowy dla SoftGrid (teraz App-V). Jest dostępny pod adresem Anthony.kinney@microsoft.com.

Do początku strony