Microsoft Intune to nie tylko narzędzie do rozsyłania aplikacji na firmowe telefony i laptopy. W praktyce łączy wdrażanie, konfigurację, zabezpieczenia, aktualizacje i kontrolę dostępu do danych, więc dobrze sprawdza się tam, gdzie aplikacje są równie ważne jak samo urządzenie. W tym tekście pokazuję, jak sensownie podejść do tego tematu: od typów aplikacji, przez model ochrony danych, po najczęstsze błędy przy wdrożeniu.
Najważniejsze rzeczy, które warto wiedzieć o aplikacjach w Intune
- Intune obsługuje różne modele aplikacji: sklepowe, Win32, LOB, web i mobilne chronione politykami.
- Nie zawsze trzeba zarządzać całym urządzeniem; czasem wystarczy ochrona danych w samej aplikacji.
- Aktualizacje działają różnie w zależności od typu aplikacji, więc jedna strategia dla wszystkiego zwykle się nie sprawdza.
- Company Portal jest ważny, bo to tam użytkownik widzi dostępne aplikacje i sam wykonuje część akcji.
- Najwięcej problemów powodują złe przypisania, brak testów i założenie, że każda aplikacja aktualizuje się automatycznie.
Jak patrzeć na Intune, gdy chodzi o aplikacje
Z mojej perspektywy największy błąd polega na traktowaniu Intune jak zwykłego dystrybutora pakietów. To platforma, która obejmuje cały cykl życia aplikacji: przypisanie do użytkownika lub urządzenia, ustawienie polityk konfiguracji, ochronę danych i monitoring skuteczności wdrożenia. W praktyce trzeba rozdzielić dwa podejścia: MDM, czyli zarządzanie urządzeniem, oraz MAM, czyli zarządzanie samą aplikacją i danymi w niej.
- MDM ma sens, gdy chcesz kontrolować zgodność urządzenia, szyfrowanie, aktualizacje systemowe lub dostęp do zasobów firmowych.
- MAM jest lepsze, gdy zależy ci głównie na ochronie danych w aplikacji, zwłaszcza na prywatnych telefonach pracowników.
- Conditional Access łączy te światy, bo może uzależnić dostęp do firmowych zasobów od stanu urządzenia albo aplikacji.
Jeśli myślisz tylko o instalacji aplikacji, łatwo przeoczyć tę warstwę polityk i kontroli. A właśnie ona decyduje, czy wdrożenie będzie wygodne, czy stanie się kolejnym źródłem zgłoszeń do help desku. To dobry moment, żeby przejść od modelu zarządzania do konkretnych typów aplikacji.
Jakie typy aplikacji można wdrażać i kontrolować
Intune nie ogranicza się do jednego formatu. W zależności od platformy i scenariusza możesz wdrażać aplikacje sklepowe, desktopowe pakiety Win32, aplikacje firmowe tworzone wewnętrznie, skróty do aplikacji webowych oraz aplikacje mobilne chronione politykami. To ważne, bo od wyboru typu zależy sposób instalacji, aktualizacji i późniejszej kontroli.
| Typ aplikacji | Kiedy ma sens | Co daje | Na co uważać |
|---|---|---|---|
| Publiczne aplikacje sklepowe | Gdy korzystasz ze standardowego oprogramowania dostępnego w Microsoft Store, App Store lub Managed Google Play. | Prostsze wdrożenie i mniejszy narzut administracyjny. | Nie każda aplikacja sklepu daje pełną kontrolę nad wersją i zachowaniem. |
| Win32 | Na Windows, gdy potrzebujesz pełnej kontroli nad instalacją desktopową. | Największa elastyczność, dobre dla rozbudowanych programów biznesowych. | Trzeba dobrze ustawić reguły wykrywania, kontekst instalacji i zachowanie po restarcie. |
| LOB | Gdy wdrażasz aplikacje tworzone wewnętrznie lub specyficzne dla organizacji. | Pasuje do własnych narzędzi i niszowych scenariuszy. | Aktualizacje zwykle wymagają ponownego przygotowania pakietu. |
| Web apps | Gdy aplikacja działa w przeglądarce i nie wymaga lokalnej instalacji. | Szybki dostęp bez ciężkiego pakietu instalacyjnego. | To bardziej punkt dostępu niż pełne wdrożenie aplikacji. |
| Aplikacje chronione na mobile | Gdy chcesz chronić dane w aplikacji bez pełnej rejestracji urządzenia. | Dobre rozwiązanie dla BYOD i pracy hybrydowej. | Wymaga, by aplikacja obsługiwała polityki ochrony Intune. |
| Microsoft 365 Apps | Gdy standaryzujesz pakiet biurowy na Windows. | Ułatwia spójne wdrożenie i utrzymanie pakietu. | Trzeba przemyśleć kanał aktualizacji i zakres dodatków. |
W praktyce to nie jest wybór czysto techniczny. Jeśli aplikacja ma przede wszystkim „dostarczyć funkcję”, wystarczy web app. Jeśli ma mieć lokalne pliki, integrację z systemem i kontrolę wersji, zwykle potrzebujesz pakietu desktopowego. Jeśli natomiast najważniejsze jest niedopuszczenie do wycieku danych, sama instalacja bywa najmniej istotna.
To prowadzi do kolejnego pytania: jak te aplikacje są faktycznie wdrażane i aktualizowane.
Jak wygląda wdrażanie, aktualizowanie i wycofywanie aplikacji
Tu najczęściej widać różnicę między teorią a codzienną administracją. Jak podaje Microsoft Learn, wymagane aplikacje mogą zostać automatycznie ponownie zainstalowane, zaktualizowane lub usunięte w ciągu 24 godzin, bez czekania na standardowy 7-dniowy cykl ponownej oceny. To dobry przykład, że w Intune liczy się nie tylko sam start wdrożenia, ale też późniejsza konsekwencja egzekwowania polityk.
Najpierw wybierasz model przypisania
Najprostszy podział wygląda tak: Required oznacza aplikację obowiązkową, Available for enrolled devices pozwala użytkownikowi zainstalować ją samodzielnie z Company Portal, a Uninstall służy do usuwania aplikacji z urządzeń. To właśnie ten wybór najczęściej decyduje o tym, czy użytkownik ma poczucie porządku, czy chaosu.
Jeśli coś ma być zawsze obecne na urządzeniu służbowym, ustawiam to jako obowiązkowe. Jeśli aplikacja jest dodatkowa, eksperymentalna albo przydatna tylko części zespołu, lepiej dać ją jako opcjonalną. Dzięki temu nie zamieniasz telefonu pracownika w przypadkowy kosz aplikacji.
Aktualizacje zależą od typu aplikacji
W przypadku aplikacji sklepowych i wybranych pakietów katalogowych aktualizacje mogą przebiegać niemal bezobsługowo. W środowisku Windows coraz większe znaczenie ma też Enterprise App Management, gdzie przy odpowiedniej konfiguracji Intune może sam wykrywać nową wersję i zaktualizować aplikację na przypisanych urządzeniach. W przypadku niektórych pozycji z katalogu aktualizacje pojawiają się zwykle po automatycznej walidacji w 24 godziny, a te wymagające ręcznego testu mogą potrwać do 7 dni.
Inaczej wygląda to przy aplikacjach LOB. Tu najczęściej trzeba przygotować nowy pakiet, wrzucić go ponownie i zadbać o to, aby stara wersja została zastąpiona w kontrolowany sposób. Dla Win32 bardzo przydaje się mechanizm supersedence, czyli świadomego zastępowania starej wersji nową. To drobiazg, ale w większym środowisku robi ogromną różnicę.
Przeczytaj również: API co to? - Działanie, rodzaje i integracja w aplikacjach
Co sprawdzać przed pilotem
- czy reguły wykrywania faktycznie rozpoznają poprawną wersję aplikacji,
- czy instalacja ma działać w kontekście użytkownika, czy systemu,
- jak aplikacja zachowuje się po restarcie,
- czy kody zwracane przez instalator są poprawnie interpretowane,
- czy licencje i dostęp do źródeł instalacji są dostępne dla wszystkich grup testowych.
To właśnie tu najłatwiej o problem, który potem wygląda jak awaria platformy, choć w rzeczywistości jest tylko źle opisanym pakietem. Gdy ten etap jest dobrze przygotowany, przejście do ochrony danych w aplikacjach staje się dużo prostsze.
Kiedy sama ochrona aplikacji wystarczy
Jeśli organizacja przede wszystkim chce zabezpieczyć dane, a nie zarządzać całym urządzeniem, wchodzi w grę Mobile Application Management. Jak podaje Microsoft Learn, app protection policies pomagają utrzymać dane firmowe wewnątrz zarządzanej aplikacji nawet wtedy, gdy urządzenie nie jest w pełni zarejestrowane. To praktyczne rozwiązanie dla pracy na prywatnych telefonach i w modelu mieszanym.
W takich politykach można ustawić między innymi ograniczenia kopiowania i wklejania, wymaganie kodu PIN w aplikacji, szyfrowanie danych służbowych, otwieranie linków w Microsoft Edge oraz blokady uruchamiania, gdy aplikacja nie spełnia minimalnych warunków bezpieczeństwa. Z mojego doświadczenia największą wartość daje właśnie ten zestaw: nie spektakularny, ale realnie ograniczający wyciek danych.
Warunek jest jednak prosty: aplikacja musi wspierać ochronę Intune, zwykle przez Intune SDK albo odpowiednią integrację partnera. Jeśli tego wsparcia nie ma, polityka nie zadziała tak, jak oczekujesz. Wtedy trzeba rozważyć pełniejsze zarządzanie urządzeniem albo inną aplikację do pracy.
W skrócie: MAM wybieram wtedy, gdy ważniejsza jest kontrola nad danymi niż nad sprzętem. MDM zostawiam tam, gdzie potrzebuję też polityk urządzeniowych, zgodności, certyfikatów lub pełniejszego nadzoru. Ten wybór oszczędza czas i zwykle zmniejsza liczbę niepotrzebnych ograniczeń dla użytkowników.
Co widzi użytkownik w Company Portal i dlaczego to ważne
Od strony użytkownika Intune najczęściej kończy się w Company Portal, czyli w aplikacji i wersji webowej, przez które pracownik widzi dostępne aplikacje, instaluje je, sprawdza stan urządzeń i kontakt do IT. Jeśli ten punkt jest źle zaprojektowany, nawet dobra polityka administracyjna zaczyna wyglądać jak chaos.
Company Portal działa na Windows, macOS, Android i iOS, a także w przeglądarce. To oznacza, że użytkownik może mieć jeden spójny punkt wejścia do firmowych zasobów, niezależnie od platformy. Dla zespołu IT to duża oszczędność, ale tylko wtedy, gdy opisy aplikacji są czytelne i decyzje o przypisaniach są przemyślane.
- Nazwa aplikacji powinna mówić, do czego służy, a nie być tylko technicznym identyfikatorem.
- Opis powinien od razu wyjaśniać, czy aplikacja jest obowiązkowa, czy opcjonalna.
- Aplikacje startowe dla nowych pracowników warto wyróżniać jako featured, żeby nie trzeba było ich szukać.
- Przy mobilnych pakietach trzeba jasno komunikować, czy wymagają konta służbowego i rejestracji urządzenia.
To niby detal, ale właśnie detale redukują liczbę zgłoszeń typu „nie wiem, co mam zainstalować” albo „dlaczego ta aplikacja się nie pojawia”. Gdy warstwa użytkownika działa dobrze, widać dopiero prawdziwą jakość całego wdrożenia.
Najczęstsze błędy, które psują wdrożenie aplikacji
W projektach aplikacyjnych najczęściej nie wygrywa najbardziej rozbudowana konfiguracja, tylko ta, która najlepiej odzwierciedla realny sposób pracy. Właśnie dlatego kilka błędów wraca zaskakująco często.
- Mylenie MDM z MAM - organizacja wymaga pełnej rejestracji urządzenia tam, gdzie wystarczyłaby ochrona danych w aplikacji. Efekt to większy opór użytkowników bez realnej korzyści.
- Złe targetowanie - aplikacja trafia do złej grupy, a potem pojawia się problem z tym, kto widzi instalację, a kto jej nie dostaje.
- Zakładanie automatycznych aktualizacji dla wszystkiego - to działa tylko dla części typów aplikacji. Resztę trzeba zaplanować osobno.
- Brak testów pakietu - instalator wygląda poprawnie na papierze, ale w realnym środowisku psuje się przez brak uprawnień, złą detekcję albo restart.
- Brak planu zastępowania wersji - przy Win32 i LOB łatwo zostawić kilka wersji tej samej aplikacji w obiegu.
- Przeładowany Company Portal - użytkownik widzi za dużo opcji i nie rozumie, co jest ważne, a co dodatkowe.
Najgorsze jest to, że te błędy rzadko wyglądają dramatycznie na etapie konfiguracji. Uderzają dopiero później: w zgłoszeniach, opóźnieniach i ręcznym gaszeniu pożarów. Dlatego sensowniejsze od poprawiania wszystkiego naraz jest zbudowanie prostej strategii od początku.
Jak zbudować prostą strategię aplikacji, która naprawdę działa
Jeśli miałbym ułożyć to w praktyczny plan, zacząłbym od czterech kroków. Najpierw zrobiłbym inwentaryzację aplikacji i podzielił je na krytyczne, opcjonalne, mobilne i webowe. Potem dla każdej z nich wybrałbym właściwy model dostarczenia: sklep, Win32, LOB, web albo ochronę aplikacji bez pełnego wdrożenia urządzenia.
- Ustal, które aplikacje są obowiązkowe, a które mają być dostępne na życzenie.
- Dobierz typ aplikacji do platformy i sposobu utrzymania wersji.
- Zdecyduj, kto odpowiada za aktualizację: Intune, supersedence, katalog producenta czy ręczny proces.
- Przetestuj wdrożenie na małej grupie i obserwuj błędy instalacji oraz zgłoszenia użytkowników.
- Jeśli środowisko jest mieszane, zacznij od ochrony aplikacji, a pełne zarządzanie urządzeniem stosuj tylko tam, gdzie naprawdę daje wartość.
Jeśli mam wskazać jedną zasadę, to jest nią separacja. Nie mieszaj wszystkiego w jeden koszyk, bo inne reguły mają aplikacje biurowe, inne firmowe mobilne, a jeszcze inne narzędzia wewnętrzne. Dobrze ustawiony Intune nie jest widowiskowy, ale oszczędza dużo pracy i zwykle po prostu znika z pola widzenia użytkownika.
