Office Deployment Tool – niestandardowa instalacja Office może być prosta!

Office Deployment Tool (ODT) to darmowe narzędzie wiersza poleceń, które pozwala administratorom pobrać i zainstalować aplikacje Microsoft 365 na dyskach lokalnych z całkowitym pominięciem standardowego instalatora. Żeby z niego skorzystać, musisz przygotować plik konfiguracyjny XML i uruchomić plik setup.exe z odpowiednim parametrem. To rozwiązanie daje pełną kontrolę nad tym, jakie dokładnie programy trafią na stacje robocze użytkowników, w jakiej wersji językowej i z jakiego kanału aktualizacji.

Prawda jest zresztą absolutnie taka, że standardowy instalator pakietu biurowego pobierany prosto z portalu użytkownika przypomina czarną skrzynkę. Klikasz i czekasz. Instaluje się wszystko. Word, Excel, PowerPoint, a do tego dorzuca Accessa i Publishera, których w większości firm nikt nigdy nie otworzył. Office Deployment Tool odcina ten balast. Zmieniliśmy te zasady na robocie lata temu, bo zapychanie łączy w oddziałach lokalnych gigabajtami nieużywanych danych to czyste marnotrawstwo zasobów.

Dlaczego standardowy instalator Microsoft 365 doprowadza działy IT do szału?

W dziale wsparcia technicznego szybko uczysz się nienawidzić domyślnych rozwiązań. Instalator internetowy Click-to-Run (Szybka instalacja) w swojej podstawowej formie zakłada, że masz idealne łącze i chcesz absolutnie każdy składnik pakietu. Kiedy masz do postawienia pięćdziesiąt nowych stacji roboczych w małym biurze na warszawskim Targówku, gdzie łącze potrafi zgubić pakiety przy mocniejszym wietrze, puszczenie pięćdziesięciu jednoczesnych pobierań z serwerów Content Delivery Network (CDN) Microsoftu kładzie całą sieć. Telefony dzwonią. Routery się dławią. Praca staje.

Office Deployment Tool rozwiązuje ten problem u źródła. Pobierasz pliki instalacyjne dokładnie jeden raz. Tworzysz lokalne repozytorium na dysku sieciowym. Potem każda kolejna instalacja Office ciągnie dane z twojego serwera plików, a nie z internetu. To oszczędza transfer i dramatycznie przyspiesza cały proces.

W zeszły wtorek o trzeciej nad ranem siedziałem w serwerowni po nieudanej migracji starych licencji. Zwykły instalator wywalił się na etapie deinstalacji starych paczek MSI i zostawił system w stanie absolutnego zawieszenia. Zlagowało wszystko. Zmęczenie materiału było ogromne, a rano ludzie musieli normalnie otworzyć skrzynki pocztowe. Wtedy właśnie na szybko złożyłem plik configuration.xml, wydałem komendę z parametrem RemoveMSI i ODT wyczyścił ten bałagan w piętnaście minut, stawiając obok czystą instancję Microsoft 365 Apps for enterprise. Bez tego narzędzia musiałbym ręcznie czyścić rejestry na każdym komputerze z osobna.

Plik XML ma błąd. Cała instalacja leży.

To jest twarda rzeczywistość pracy z Office Deployment Tool. Narzędzie nie wybacza literówek. Jeśli wpiszesz zły identyfikator języka, instalator po prostu rzuci ogólnym błędem i zakończy działanie. Musisz dokładnie wiedzieć, co robisz.

Jak napisać plik configuration.xml bez błędów w składni?

Zamiast rzucać się od razu na gotowe generatory z sieci, warto zrozumieć, z czego składa się ten plik konfiguracyjny. Dokumentacja Microsoftu bywa w tej kwestii sucha. Omijając całą tę otoczkę, plik XML dla Office Deployment Tool opiera się na kilku konkretnych węzłach. Zaczynasz od znacznika Configuration. W środku umieszczasz znacznik Add, który definiuje architekturę, na przykład OfficeClientEdition równą 64. Tam też określasz kanał aktualizacji. My w zdecydowanej większości korzystamy z MonthlyEnterprise, bo daje odpowiedni balans między nowościami a stabilnością na produkcji. Pod znacznikiem Add dajesz Product ID. Jeśli masz licencję biznesową, wpisujesz O365BusinessRetail. Jeśli korporacyjną, dajesz O365ProPlusRetail. Następnie określasz język w węźle Language ID równym pl-pl. Najważniejsze dzieje się jednak pod spodem, gdzie używasz znacznika ExcludeApp, żeby wyciąć aplikacje takie jak Groove, Lync czy Bing. Piszesz to po prostu w jednym ciągu logicznym, zachowując hierarchię znaczników, zamykając każdy z nich poprawnie. Jeśli tego nie domkniesz, parser w pliku setup.exe natychmiast odrzuci konfigurację.

Nie używamy tu żadnych graficznych interfejsów do klikania. Czysty kod.

Skąd wziąć poprawne identyfikatory produktów dla Office Deployment Tool?

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Najczęstszym powodem jest złe dopasowanie Product ID do posiadanej licencji. Microsoft używa specyficznych ciągów znaków, które nie zawsze pokrywają się z nazwą handlową, którą widzisz na fakturze.

• O365ProPlusRetail uchodzi za standard dla subskrypcji Enterprise (E3, E5).
• O365BusinessRetail przypisujemy do planów Microsoft 365 Business Standard i Premium.
• VisioProRetail oraz ProjectProRetail służą do instalacji dodatkowych narzędzi specjalistycznych.
• Standard2021Volume to identyfikator dla licencji wieczystych kupowanych grupowo (KMS/MAK).

Zawsze weryfikuj te wartości przed wdrożeniem masowym. Próba aktywacji wersji ProPlus kluczem z planu Business zakończy się monitem o błąd licencji u użytkownika końcowego. To jest bez mała najgorsza opcja z wszystkich, gdy wypchniesz paczkę na sto maszyn i nagle wszyscy zgłaszają brak możliwości edycji dokumentów.

Jakie parametry wiersza polecenia obsługuje setup.exe?

Uruchomienie Office Deployment Tool opiera się na wywołaniu pliku wykonywalnego z jednym z kilku zdefiniowanych przełączników. Mechanika jest prosta. Otwierasz wiersz polecenia jako administrator, przechodzisz do folderu z rozpakowanym ODT i wydajesz komendę.

Komenda /download jest twoim głównym narzędziem do budowania lokalnego repozytorium. Pamiętaj, żeby w pliku XML zadeklarować atrybut SourcePath w znaczniku Add. Jeśli tego nie zrobisz, setup.exe utworzy folder “Office” w tym samym katalogu, z którego został uruchomiony. My na wdrożeniach przeważnie ustawiamy SourcePath na zasób sieciowy typu \\serwer\udzial\Office.

Wyrzucenie paczki po GPO (Zasady Grupy) albo przez Microsoft Intune wymaga użycia parametru /configure w połączeniu z odpowiednio spreparowanym skryptem, który wywoła instalację w trybie cichym.

Czy da się wyłączyć telemetrię i aktualizacje w tle za pomocą ODT?

Tak. Office Deployment Tool pozwala kontrolować zachowanie pakietu już na etapie wdrożenia. W węźle Updates możesz ustawić atrybut Enabled na “FALSE”. Wtedy pakiet biurowy przestanie samoczynnie szukać łatek. Oczywiście zrzucasz wtedy na siebie obowiązek ręcznego łatania dziur w zabezpieczeniach lub wymuszania aktualizacji przez narzędzia klasy RMM (Remote Monitoring and Management).

Możesz również zaakceptować umowę licencyjną za użytkownika, dodając węzeł Display z atrybutem AcceptEULA ustawionym na “TRUE”. To eliminuje pierwsze okno powitalne, które normalnie blokuje start pracy. Dodatkowo ustawienie atrybutu Level na “None” sprawia, że cały proces instalacji przebiega w tle. Użytkownik widzi tylko pojawiające się nagle skróty na pasku zadań. Brak pasków postępu zapobiega sytuacjom, w których pracownik celowo krzyżykiem zamyka instalator, bo “komputer mu wolno chodzi”.

Jak przetestować wdrożenie ODT zanim wyślesz je na produkcję?

NIGDY nie puszczaj wdrożenia na żywy organizm bez testów na maszynie wirtualnej. Nawet weterani popełniają błędy w składni. Wystarczy zapomnieć o jednym zamknięciu cudzysłowu w atrybucie PIDKEY, żeby instalator wywalił się z błędem parsowania.

Dobrym pomysłem jest przygotowanie wyizolowanego środowiska. Odpalasz czystego Windowsa. Kopiujesz folder z narzędziem Office Deployment Tool i swoim plikiem configuration.xml. Uruchamiasz instalację z lokalnego źródła. Obserwujesz zachowanie systemu. Sprawdzasz, czy usunęły się stare wersje MSI, jeśli użyłeś atrybutu RemoveMSI. Weryfikujesz, czy nie zainstalował się OneDrive, jeśli kazałeś go wykluczyć przez ExcludeApp.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, wydaje się to tylko jedną z możliwych hipotez, że Microsoft zmienia czasem po cichu nazwy wewnętrzne pewnych modułów. Dlatego plik XML, który działał pół roku temu, dzisiaj może wyrzucić błąd z powodu braku kompatybilności jakiegoś przestarzałego znacznika. Test lokalny to twoja jedyna polisa ubezpieczeniowa przed masową awarią w firmie.

Zwróć uwagę na zachowanie aktywacji. Jeśli używasz atrybutu AUTOACTIVATE ustawionego na 1 dla licencji wieczystych, komputer musi mieć w momencie instalacji dostęp do serwera KMS w twojej sieci lub do internetu w przypadku kluczy MAK. Jeśli sieć będzie odcięta, Office zainstaluje się poprawnie, ale przy pierwszym uruchomieniu poprosi użytkownika o podanie klucza. To generuje niepotrzebne zgłoszenia do działu IT.

Jak migrować stare instalacje MSI do technologii Click-to-Run?

Stare pakiety Office 2013 czy 2016 oparte na technologii Windows Installer (MSI) to koszmar utrzymaniowy. Mają osobne łatki, instalują się godzinami i często konfliktują z nowszymi rozwiązaniami. Microsoft 365 Apps działa w technologii Click-to-Run (C2R). Te dwa światy nie mogą współistnieć na jednym systemie operacyjnym w obrębie tej samej głównej wersji. Instalator C2R po prostu odmówi współpracy, jeśli wykryje stare resztki MSI.

Office Deployment Tool ma wbudowany mechanizm czyszczący. Wystarczy dodać do pliku konfiguracyjnego znacznik <RemoveMSI />. To proste polecenie nakazuje instalatorowi odszukanie i brutalne odinstalowanie wszystkich starych produktów Office, Visio i Project opartych na MSI, zanim rozpocznie się właściwa instalacja Click-to-Run. Możesz to polecenie doprecyzować. Jeśli chcesz zostawić starego Visio 2016, dodajesz atrybut IgnoreProduct. My zazwyczaj tniemy wszystko do zera. Czysta instalacja zawsze sprawia mniej problemów niż próba łatania hybrydowego środowiska.

Usuwanie MSI wydłuża całkowity czas wdrożenia. Deinstalator musi wyczyścić rejestr, usunąć pliki z Program Files i zarejestrować zmiany w systemie komponentów Windows. Jeśli robisz to w tle (Display Level=”None”), komputer może przez kilkanaście minut wydawać się obciążony, zanim w ogóle zacznie pobierać nowe pliki C2R z lokalnego bufora. Użytkownik musi być poinformowany, żeby w tym czasie nie restartował maszyny.

Co zrobić, gdy Office Deployment Tool rzuca kodem błędu?

Sprawdzasz logi i widzisz ten cholerny błąd 30088-1007. Frustracja rośnie.

Kody błędów ODT są z reguły bardzo mało intuicyjne. Komunikat wyświetlany na ekranie najczęściej informuje tylko o tym, że “Coś poszło nie tak” lub że brakuje połączenia z internetem. Żeby dokopać się do prawdziwej przyczyny, musisz wejść do katalogu tymczasowego użytkownika, na którym uruchamiano instalację. Wpisujesz w pasku adresu eksploratora %temp% i szukasz plików tekstowych zaczynających się od nazwy maszyny i słowa “Setup”.

Pliki logów z Click-to-Run są potężne. Notatnik może mieć problem z ich szybkim przewijaniem. Szukaj fraz takich jak “Failed”, “Error” albo “Unexpected”. Często znajdziesz tam informację, że instalator nie mógł uzyskać dostępu do ścieżki sieciowej zdefiniowanej w SourcePath (np. brak uprawnień odczytu dla konta SYSTEM, z którego uruchamiany jest skrypt instalacyjny przez Intune). Innym razem log pokaże, że na dysku brakuje miejsca na wypakowanie plików cab.

Pospolite błędy i ich przyczyny:

• Błąd 30088-1007: Najczęściej oznacza problem z parsowaniem pliku XML. Masz literówkę w nazwie znacznika, nie zamknąłeś cudzysłowu lub użyłeś znaku specjalnego bez odpowiedniego kodowania.
• Błąd 30015-11: Problemy z usunięciem starej wersji. W systemie wiszą zablokowane pliki lub uszkodzony jest podsystem Windows Installer.
• Błąd 0-1008: Próba instalacji wersji 64-bitowej na komputerze, gdzie rezyduje już jakiś 32-bitowy komponent Office (np. stary silnik bazy danych Access). Musisz usunąć ten komponent przed wdrożeniem.

Często najszybszą metodą naprawy jest całkowite wyczyszczenie maszyny z resztek Office za pomocą asystenta odzyskiwania Microsoft (SaRA), restart i ponowne wypchnięcie paczki przez ODT.

Zarządzanie kanałami aktualizacji w ODT

Microsoft dostarcza aktualizacje w różnych tempach. Kanał, który wybierzesz w pliku XML, determinuje, jak często użytkownicy będą widzieć zmiany w interfejsie i dostawać nowe funkcje. To krytyczna decyzja biznesowa.

CurrentChannel to kanał bieżący. Aktualizacje wpadają co miesiąc, a czasem częściej. Dostajesz nowości natychmiast. Ryzyko usterek jest najwyższe. Wykorzystujemy to głównie w działach IT do testowania tego, co za chwilę trafi do reszty firmy.

MonthlyEnterpriseChannel to kompromis. Zmiany zbierane są przez miesiąc i wypuszczane raz, zazwyczaj w drugi wtorek miesiąca (Patch Tuesday). Daje to przewidywalność. Wiesz, kiedy sieć będzie obciążona pobieraniem łatek.

SemiAnnualEnterpriseChannel to kanał półroczny. Używany na stacjach roboczych w halach produkcyjnych, w szpitalach, wszędzie tam, gdzie zmiana położenia przycisku w Excelu może wywołać paraliż procesów. Aktualizacje funkcji pojawiają się dwa razy w roku (w styczniu i lipcu). Łatki bezpieczeństwa są oczywiście dostarczane na bieżąco.

Zmiana kanału u już zainstalowanego klienta nie wymaga ponownej instalacji całego pakietu. Wystarczy wywołać setup.exe z parametrem /customize i nowym plikiem XML, w którym podasz inny atrybut Channel. Silnik Click-to-Run pobierze w tle odpowiednie pliki różnicowe i zaktualizuje ścieżkę aktualizacji. To mechanizm, który znacząco ułatwia życie, gdy zarząd nagle zażąda dostępu do nowej funkcji AI w Wordzie, a reszta firmy siedzi na kanale półrocznym.

Wdrożenie pakietu biurowego w środowisku firmowym nigdy nie jest procesem, który można po prostu wyklikać myszką na każdym stanowisku z osobna. Office Deployment Tool wymaga od ciebie na początku odrobiny wysiłku przy pisaniu kodu XML. Musisz zrozumieć strukturę, przetestować przełączniki i przygotować zasób sieciowy. Odpal notatnik, napisz ten plik XML, ustaw blokady na zbędne aplikacje i wypchnij to na jeden testowy komputer z wiersza poleceń. Wynik udowodni ci od razu, ile czasu do tej pory traciłeś na ręczne instalacje.

Najczęściej zadawane pytania (FAQ)

• Czym jest Office Deployment Tool (ODT)?
  Office Deployment Tool to darmowe narzędzie wiersza poleceń od Microsoftu, które pozwala administratorom pobierać, konfigurować i wdrażać aplikacje Microsoft 365 w sieciach firmowych z pominięciem standardowego instalatora internetowego.
• Jak utworzyć plik configuration.xml dla ODT?
  Plik configuration.xml tworzy się w zwykłym edytorze tekstu (np. Notatnik). Należy w nim zdefiniować znaczniki takie jak Add, Product ID, Language ID oraz ExcludeApp, określając architekturę, wersję językową i aplikacje, które mają zostać pominięte.
• Do czego służy komenda setup.exe /download?
  Parametr /download nakazuje narzędziu ODT pobranie plików instalacyjnych z serwerów Microsoftu do wskazanego folderu lokalnego lub sieciowego, bez instalowania pakietu Office na danym komputerze. Służy do budowania lokalnego repozytorium.
• Czy ODT potrafi usunąć starsze wersje Office (MSI)?
  Tak. Aby usunąć starsze wersje instalowane przez Windows Installer (MSI), należy dodać znacznik <RemoveMSI /> do pliku configuration.xml. Instalator automatycznie odinstaluje stare pakiety przed wdrożeniem Microsoft 365.
• Jak wyłączyć okna dialogowe podczas instalacji Office?
  W pliku XML należy dodać węzeł Display i ustawić atrybut Level na wartość ‘None’ oraz atrybut AcceptEULA na ‘TRUE’. Dzięki temu instalacja przebiegnie całkowicie w tle, bez interakcji ze strony użytkownika.
• Gdzie znaleźć logi błędów Office Deployment Tool?
  Logi z przebiegu instalacji ODT zapisywane są domyślnie w katalogu tymczasowym użytkownika, z którego konta uruchomiono proces. Można się do nich dostać, wpisując %temp% w pasku adresu Eksploratora plików.

Bibliografia i źródła

1. Microsoft Learn – https://learn.microsoft.com
2. TechNet – https://technet.microsoft.com
3. Microsoft Tech Community – https://techcommunity.microsoft.com
4. Spiceworks IT Community – https://community.spiceworks.com
5. GitHub (repozytoria skryptów administracyjnych) – https://github.com