Rozproszone środowisko IT z wieloma administratorami w tej samej dzierżawie Microsoft Intune

  • Artykuł

Wiele organizacji korzysta z rozproszonego środowiska IT, w którym mają jedną dzierżawę Microsoft Intune z wieloma administratorami lokalnymi. W tym artykule opisano jeden ze sposobów skalowania Microsoft Intune w celu obsługi wielu administratorów lokalnych, którzy zarządzają własnymi użytkownikami, urządzeniami i tworzą własne zasady w ramach jednej dzierżawy Microsoft Intune. Nie ma właściwej ani złej odpowiedzi na temat liczby administratorów, których możesz mieć w dzierżawie. Artykuł koncentruje się na dzierżawach, które mają wielu administratorów lokalnych.

Rozproszona infrastruktura IT jest potrzebna w systemach, w których duża liczba administratorów lokalnych łączy się z jedną dzierżawą usługi Intune. Na przykład niektóre systemy szkolne są zorganizowane tak, aby mieć administratora lokalnego dla każdej szkoły w systemie lub regionie. Czasami to środowisko rozproszone może być 15 lub więcej różnych administratorów lokalnych, którzy są rzutowane do tego samego systemu centralnego lub Microsoft Intune dzierżawy.

Każdy administrator lokalny może skonfigurować grupy zgodnie z potrzebami organizacji. Administrator lokalny zazwyczaj tworzy grupy i organizuje wielu użytkowników lub urządzenia według lokalizacji geograficznej, działu lub cech sprzętu. Administratorzy lokalni również używają tych grup do zarządzania zadaniami na dużą skalę. Na przykład administratorzy lokalni mogą ustawiać zasady dla wielu użytkowników lub wdrażać aplikacje na zestawie urządzeń.

Role, które musisz znać

  • Zespół centralny: Centralny zespół lub grupa obejmuje administratorów globalnych lub administratorów podstawowych w dzierżawie. Administratorzy ci mogą nadzorować wszystkich administratorów lokalnych i udostępniać wskazówki administratorom lokalnym.

  • Administratorzy lokalni: administratorzy lokalni są lokalni i koncentrują się na zasadach i profilach dla określonych lokalizacji; w szkołach, szpitalach itd.

Kontrola dostępu oparta na rolach

W tej sekcji krótko opisano różne modele i zaproponowano wytyczne w poszczególnych modelach dotyczące zarządzania zasadami, profilami i aplikacjami między zespołem centralnym a administratorami lokalnymi. Modele są następujące:

  • Model delegowania częściowego
  • Model pełnego delegowania
  • Model centralny
  • Model zdecentralizowany
  • Model hybrydowy

Model delegowania częściowego

Model delegowania częściowego proponuje następujące wytyczne dotyczące zarządzania zasadami między zespołem centralnym a administratorami lokalnymi.

✔️ Uprawnienia

  • Uprawnienia do tworzenia, aktualizowania i usuwania zasad, profilów rejestracji i aplikacji powinny być przechowywane przez zespół centralny.
  • Przyznaj uprawnienia tylko do odczytu i przypisz je administratorom lokalnym.

✔️ Ponownego użycia

  • Często skonfigurowane zasady, profile rejestracji i aplikacje powinny być udostępniane administratorom lokalnym w celu ich ponownego użycia w jak najszerszym zakresie.
  • Microsoft Intune używa wielu typowych konfiguracji, które dzielą się na kilka kategorii. Przejrzyj zalecenia wymienione dla zasad ochrony aplikacji.
  • Jako administratorzy lokalni powinni zapoznać się z istniejącymi zasadami i ponownie użyć ich w razie potrzeby.

✔️ Wyjątki

  • Zespół centralny może tworzyć pewne nowe zasady, profile rejestracji i aplikacje jako wyjątki w razie potrzeby w imieniu administratorów lokalnych. Zazwyczaj te wyjątki obejmują dowolny typ profilu, który wymaga unikatowych parametrów.

Model delegowania częściowego jest proponowany w tych dwóch obszarach:

Wytyczne dotyczące grup i przypisań dla administratorów lokalnych: Jakie są jedne z najlepszych rozwiązań dla administratorów lokalnych do przyjęcia podczas organizowania grup zarządzania urządzeniami za pośrednictwem Microsoft Intune? Aby się tego dowiedzieć, przeczytaj artykuł Grupowanie, określanie wartości docelowych i filtrowanie usługi Intune: Zalecenia dotyczące najlepszej wydajności — Microsoft Tech Community

Wytyczne specyficzne dla funkcji: jak zasady/profile/aplikacje są zarządzane między urzędem centralnym a administratorami lokalnymi z określonymi uprawnieniami dla różnych funkcji. Aby uzyskać więcej informacji, przejdź do sekcji Wytyczne dotyczące funkcji.

Model pełnego delegowania

Model pełnego delegowania proponuje następujące wytyczne dotyczące zarządzania zasadami między zespołem centralnym a administratorami lokalnymi.

  • Każdy administrator lokalny powinien mieć własny tag zakresu, aby rozdzielić każdy obiekt, który w pełni zarządza.
  • Jeśli administrator lokalny nie musi tworzyć, aktualizować ani usuwać, przyznaj administratorowi lokalnemu rolę z uprawnieniami do odczytu i przypisywania oraz unikaj przypisywania do nich innej roli z pełnym uprawnieniem. Dzięki temu podejściu można uniknąć łączenia uprawnień między tagami zakresu.
  • Czasami administratorzy lokalni mogą potrzebować tworzenia własnych zasad, profilów i aplikacji, udostępniając niektóre typowe zasady, profile i aplikacje. W takich przypadkach utwórz specjalną grupę i przypisz do tej grupy typowe zasady, profile i aplikacje. Ta grupa nie powinna być uwzględniona w grupie zakresów dla żadnego administratora lokalnego. Grupa zakresów. Takie podejście uniemożliwia tworzenie, aktualizowanie i usuwanie uprawnień przypisanych administratorom lokalnym do stosowania do tych typowych zasad, profilów i aplikacji.

Model centralny

W modelu centralnym jeden lokalny zespół administracyjny (nadrzędny) zarządza wieloma organizacjami podrzędnymi. Czynniki takie jak geografia, jednostka biznesowa lub rozmiar mogą być powiązane z organizacjami podrzędnymi.

  • Istnieje tylko jeden tag zakresu używany do objęcia wszystkich zarządzanych administratorów lokalnych.

  • Jeśli to możliwe, lokalny zespół administracyjny powinien ustandaryzować przypisania między administratorami lokalnymi i umieścić wszystkie swoje urządzenia w jednej grupie Microsoft Entra do przypisania. Jeśli nie można utworzyć pojedynczej grupy Microsoft Entra, lokalny zespół administracyjny może tworzyć różne grupy Microsoft Entra w celu wykonywania różnych przypisań.

  • Jeśli inny lokalny zespół administracyjny zarządza organizacją lub przenosi ją, należy wykonać następujące kroki:

    • Wszystkie urządzenia i użytkownicy organizacji muszą zostać wyodrębnieni ze wspólnych grup Microsoft Entra w zakresie oryginalnego lokalnego zespołu administracyjnego.

    • Wszystkie zasady/aplikacje/profile przypisane unikatowo dla tej organizacji muszą mieć zaktualizowany tag zakresu dla nowego lokalnego zespołu administracyjnego.

Model zdecentralizowany

W modelu zdecentralizowanym wielu administratorów lokalnych (dzieci) jest zarządzanych zarówno przez dedykowanego administratora lokalnego, jak i przez pośredniczący lokalny zespół administracyjny. Administratorzy nadrzędny i podrzędny mają własne tagi zakresu reprezentujące granice zarządzania.

  • Jeśli administratorów podrzędnych jest mniej niż 50, pośredniemu lokalnemu zespołowi administracyjnemu można udzielić dostępu, przypisując wszystkie tagi zakresu dzieci do przypisania roli RBAC pośrednich lokalnych zespołów administracyjnych.
  • Jeśli jest więcej niż 50 administratorów podrzędnych, pośredni lokalny zespół administracyjny powinien otrzymać własny tag zakresu, aby reprezentować całą kolekcję administratorów podrzędnych, którymi nadzorują.
  • Nowo utworzone zasady w tagach zakresu administratora podrzędnego muszą mieć tag pośredni dodany przez rolę administratora globalnego, aby zapobiec utracie widoczności przez pośredni lokalny zespół administracyjny.

Model hybrydowy

W modelu hybrydowym ten sam administrator nadrzędny jest jednocześnie używany w modelu centralnym i zdecentralizowanym. Nie ma żadnych specjalnych zaleceń dla tego modelu.

Wytyczne specyficzne dla funkcji

W zależności od wymagań biznesowych dla każdej funkcji wytyczne przedstawione w tej sekcji mogą zalecić utworzenie zasad dla administratora lokalnego i/lub delegowanie uprawnień wymaganych do tworzenia obiektów do administratorów lokalnych.

Uwaga

Wskazówki przedstawione w tej sekcji nie dotyczą każdej funkcji, ale obejmują tylko te obszary, dla których mamy specjalne instrukcje.

zasady Ochrona aplikacji

Ochrona aplikacji zasady to reguły, które zapewniają, że dane organizacji pozostają bezpieczne lub zawarte w zarządzanej aplikacji. Aby uzyskać więcej informacji, przejdź do Ochrona aplikacji zasad.

Wytyczne dotyczące zasad Ochrona aplikacji są podzielone między zespół centralny i administratorów lokalnych w następujący sposób:

Zespół centralny — zadania

  • Przejrzyj potrzeby związane z zabezpieczeniami i potrzebami biznesowymi w całej organizacji i wygeneruj zestaw typowych zasad Ochrona aplikacji dla administratorów lokalnych.
  • Przejrzyj wymienione zalecenia, aby określić, jakie mechanizmy kontroli zabezpieczeń są odpowiednie przed utworzeniem jakichkolwiek zasad Ochrona aplikacji.
  • Mieć ustaloną metodę dla administratorów lokalnych, aby zażądać dostosowanych zasad Ochrona aplikacji, jeśli to konieczne, dla określonych potrzeb biznesowych, w których nie można osiągnąć wymagań biznesowych przy użyciu istniejących wspólnych zasad.
  • Aby uzyskać szczegółowe zalecenia dotyczące poszczególnych poziomów konfiguracji i minimalnych aplikacji, które muszą być chronione, zapoznaj się z tematem Struktura ochrony danych przy użyciu zasad Ochrona aplikacji, przejdź do Ochrona aplikacji zasad

Administratorzy lokalni — uprawnienia i zadania

  • Podaj uprawnienia do odczytu i przypisywania, ale nie twórz, aktualizuj i usuwaj uprawnienia w aplikacjach zarządzanych, aby nie mogli tworzyć własnych zasad Ochrona aplikacji.
  • Podaj uprawnienia do odczytu i przypisywania zasad konfiguracji aplikacji do swoich aplikacji.
  • Podaj uprawnienia do odczytu i przypisywania tylko wtedy, gdy istnieją różne zasady ochrony dla urządzeń zarządzanych i urządzeń niezarządzanych. Jeśli zespół centralny zdecyduje się zaoferować tylko jedną zasadę dla obu tych zasad, zasady konfiguracji aplikacji nie są potrzebne.
  • Jeśli są używane zasady konfiguracji aplikacji, zaleca się przypisanie zasad konfiguracji aplikacji do wszystkich wystąpień aplikacji bez wyjątku.
  • Wybierz jedną z typowych zasad Ochrona aplikacji. Administratorzy lokalni mogą zażądać od zespołu centralnego utworzenia niestandardowych zasad ochrony aplikacji jako wyjątku i tylko w razie potrzeby.
  • Aby uzyskać więcej informacji, przejdź do Ochrona aplikacji zasad

Zasady zgodności

Zasady zgodności w usłudze Intune definiują reguły i ustawienia, które użytkownicy i urządzenia muszą spełniać, aby były zgodne. Aby uzyskać więcej informacji na temat zasad zgodności, przejdź do tematu Zasady zgodności.

Centralny zespół

Zespół centralny powinien utworzyć wspólne zasady zgodności dla administratorów lokalnych do wyboru i tylko w razie potrzeby utworzyć zasady wyjątków. Aby uzyskać więcej informacji, przejdź do tematu Zasady zgodności. Tworzenie zasad obejmuje tworzenie niestandardowych skryptów zasad zgodności, ponieważ podlegają one tej samej skali co normalne zasady zgodności.

Aby uzyskać więcej informacji na temat tworzenia zasad zgodności, przejdź do tematu Zasady zgodności.

Administratorzy lokalni

Podaj administratorom lokalnym uprawnienia do odczytu i przypisywania, ale nie utwórz, zaktualizuj lub usuń uprawnienia w zasadach zgodności. Uprawnienia do odczytu i przypisywania umożliwiają im wybór spośród typowych zasad zgodności utworzonych przez zespół centralny i przypisywanie ich do użytkowników i urządzeń.

Konfiguracja urządzenia

W tej sekcji:

  • Ograniczenia dotyczące urządzeń i konfiguracja ogólna
  • Dostęp do zasobów
  • Pierścienie aktualizacji systemu Windows
  • Aktualizacje funkcji
  • Aktualizacje dotyczące jakości

Ograniczenia dotyczące urządzeń i konfiguracja ogólna

  • Przyznaj administratorom lokalnym uprawnienia do tworzenia, aktualizowania i usuwania w ramach własnego zakresu.

  • Użyj wykazu ustawień i punktów odniesienia zabezpieczeń w maksymalnym możliwym zakresie, zamiast profilów utworzonych na liście Profile konfiguracji, aby ograniczyć skalę w centrum administracyjnym Microsoft Intune.

  • Ogólnie rzecz biorąc, centralny zespół powinien starać się centralnie monitorować zawartość konfiguracji i zastępować wiele zduplikowanych profilów, jeśli to możliwe, profilem udostępnionym.

Dostęp do zasobów

Zalecany jest model pełnego delegowania .

Pierścienie aktualizacji systemu Windows

  • Zalecamy centralne zarządzanie pierścieniami aktualizacji systemu Windows. Zespół centralny powinien utworzyć tyle typowych zasad pierścienia aktualizacji systemu Windows, ile jest potrzebnych do obsługi wariancji administratorów lokalnych.
  • Administratorzy lokalni nie powinni tworzyć własnych pierścieni aktualizacji systemu Windows. Po delegowaniu do dużej liczby administratorów całkowita liczba obiektów może stać się duża i trudna do zarządzania. Najlepsze rozwiązania różnią się w zależności od funkcji. Aby uzyskać więcej informacji, przejdź do obszaru Pierścienie aktualizacji systemu Windows.

Aktualizacje funkcji

Zalecany jest model pełnego delegowania .

Aktualizacje dotyczące jakości

Zalecany jest model pełnego delegowania .

Certyfikaty

  • Zalecamy używanie uprawnień za pośrednictwem zespołu centralnego do dołączania/odłączenia łączników zgodnie z potrzebami. Dołączanie łączników dla każdego administratora lokalnego w celu obsługi wystawiania certyfikatów.

  • Nie udzielaj administratorom lokalnym uprawnień do łączników UPDATE lub DELETE.

Aplikacje

Przyznaj administratorom lokalnym pełne uprawnienia do zarządzania aplikacjami w zakresie ich zakresu.

W tej sekcji:

  • Program zakupów zbiorczych firmy Apple

  • System Windows

  • Android

Aby uzyskać więcej informacji, przejdź do tematu Zarządzanie aplikacjami.

Program zakupów zbiorczych firmy Apple

Obecnie nie ma żadnych obaw dotyczących skalowania obsługiwanej liczby tokenów programu zakupów zbiorczych. Aby uzyskać więcej informacji, przejdź do tematu Ile tokenów mogę przekazać..

System Windows

Android

  • Administratorzy lokalni powinni wybierać spośród istniejących aplikacji ze sklepu lub poprosić centralny zespół o dodanie nowych aplikacji ze sklepu z systemem Android. Administratorzy lokalni nie powinni tworzyć nowych aplikacji ze sklepu dla systemu Android. Całkowita liczba obiektów może stać się duża i trudna do zarządzania.

  • Administratorzy lokalni mogą w razie potrzeby tworzyć aplikacje biznesowe dla systemu Android w ramach limitu międzyplatformowych aplikacji biznesowych i linków internetowych.

  • Zespół centralny musi dodać aplikacje zarządzanego sklepu Google Play.

    • Centralny zespół może wyświetlać tylko aplikacje zarządzanego sklepu Google Play dostępne w kraju/regionie dzierżawy. Jeśli zespół centralny potrzebuje aplikacji zarządzanego sklepu Google Play dostępnej tylko w niektórych krajach/regionach, może być konieczne współpracowanie z deweloperem aplikacji w celu jej poprawnego wyświetlenia.
    • Centralny zespół powinien zarządzać całą zawartością związaną z zarządzanymi aplikacjami Google Play, w tym aplikacjami prywatnymi, aplikacjami internetowymi i kolekcjami. Jeśli na przykład klient planuje publikowanie aplikacji prywatnych przy użyciu zarządzanego elementu iframe google play, musi to zrobić przy użyciu jednego konta dewelopera należącego do zespołu centralnego.
    • Centralny zespół może wybrać pojedynczy tag zakresu jako tag zakresu zarządzanego sklepu Google Play. Na stronie łącznika zarządzanego sklepu Google Play jest dostępny specjalny listę rozwijaną. Tag zakresu będzie miał zastosowanie do wszystkich zarządzanych aplikacji Google Play po dodaniu ich do konsoli przez zespół centralny, ale nie będzie stosowany wstecznie do aplikacji, które zostały już dodane. Zdecydowanie zaleca się, aby centralny zespół ustawił tag zakresu przed dodaniem aplikacji, a następnie przypisz każdy regionalny zespół, który ma tag zakresu. W przeciwnym razie administratorzy regionalni mogą nie być w stanie wyświetlić swoich zarządzanych aplikacji Google Play.

  • Tylko jedna zasada OEMConfig jest obsługiwana na urządzeniu, z wyjątkiem urządzeń Zebra. W przypadku urządzeń Zebra zdecydowanie zaleca się stosowanie najmniejszej możliwej liczby zasad, ponieważ czas wymuszania zasad jest addytywny. Jeśli na przykład przypiszesz sześć zasad z założeniem, że będą one nakładać warstwę na siebie nawzajem, rozpoczęcie pracy na urządzeniu trwa około 6 razy dłużej niż pojedyncze zasady.

Uwaga

Podczas ustawiania trybu aktualizacji o wysokim priorytecie w wielu różnych aplikacjach i grupach należy zachować szczególną ostrożność. Jest to spowodowane wieloma przyczynami:

  • Chociaż wiele aplikacji można ustawić na tryb o wysokim priorytecie, jednocześnie można zainstalować tylko jedną aktualizację aplikacji. Jedna duża aktualizacja aplikacji może potencjalnie blokować wiele mniejszych aktualizacji do czasu ukończenia instalacji dużej aplikacji.
  • W zależności od tego, kiedy aplikacje udostępniają nowe aktualizacje, może wystąpić nagły wzrost użycia sieci, jeśli wydania aplikacji zbiegają się. Jeśli Wi-Fi nie jest dostępna na niektórych urządzeniach, może również wystąpić wzrost użycia sieci komórkowej.
  • Chociaż wspomniano już o destrukcyjnych środowiskach użytkowników, problem rośnie wraz z ustawieniem większej liczby aplikacji na tryb aktualizacji o wysokim priorytecie.

Aby uzyskać więcej informacji na temat problemów ze skalowaniem dotyczących aktualizacji aplikacji zarządzanego sklepu Google Play przy użyciu trybu aktualizacji o wysokim priorytecie, przejdź do tego artykułu Techcommunity.

Profile rejestracji

W tej sekcji:

  • Autopilot
  • Strona stanu rejestracji (ESP)
  • Apple Business Manager (ABM)
  • Profile systemu Android Enterprise
  • Ograniczenia rejestracji
  • Kategorie urządzeń

Autopilot

  • Przyznaj administratorom lokalnym uprawnienia do odczytywania urządzeń rozwiązania Autopilot i przekazywania nowych urządzeń rozwiązania Autopilot.
  • Administratorzy lokalni nie powinni tworzyć profilów rozwiązania Autopilot. Po delegowaniu do dużej liczby administratorów całkowita liczba obiektów może stać się duża i trudna do zarządzania. Najlepsze rozwiązania różnią się w zależności od obszaru funkcji. Aby uzyskać więcej informacji na temat rozwiązania Autopilot, przejdź do tematu Używanie rozwiązania Autopilot do rejestrowania urządzeń z systemem Windows w usłudze Intune.

Strona stanu rejestracji

  • Administratorzy lokalni powinni wybrać z istniejących profilów strony stanu rejestracji do przypisania lub zażądać od zespołu centralnego utworzenia profilu wyjątku tylko wtedy, gdy jest to konieczne.
  • Administratorzy lokalni nie powinni tworzyć profilów stron stanu rejestracji. Po delegowaniu do dużej liczby administratorów całkowita liczba obiektów może stać się duża i trudna do zarządzania. Najlepsze rozwiązania różnią się w zależności od obszaru funkcji. Aby uzyskać informacje na stronie Stan rejestracji, przejdź do tematu Konfigurowanie strony ze stanem rejestracji.

Apple Business Manager

Jeśli to możliwe, administratorzy lokalni nie powinni mieć uprawnień do tworzenia, aktualizowania ani usuwania profilów rejestracji. Jeśli administratorzy lokalni mają uprawnienia do tworzenia profilów usługi Apple Business Manager, daje im to również uprawnienia do tworzenia, aktualizowania i usuwania w programie Autopilot. Administratorzy lokalni nie powinni jednak tworzyć profilów rozwiązania Autopilot.

Po delegowaniu do dużej liczby administratorów całkowita liczba obiektów może stać się duża i trudna do zarządzania. Najlepsze rozwiązania różnią się w zależności od obszaru funkcji. Aby uzyskać więcej informacji, przejdź do tematu Używanie programu Apple Business Manager do rejestrowania urządzeń firmy Apple w usłudze Intune.

Profile systemu Android Enterprise

  • Zespół centralny powinien utworzyć profile rejestracji dedykowanych urządzeń należących do firmy w systemie Android Enterprise dla każdego administratora lokalnego na potrzeby grupowania urządzeń.
  • Jeśli to możliwe, administratorzy lokalni nie powinni mieć uprawnień do tworzenia, aktualizowania ani usuwania na urządzeniach z systemem Android Enterprise. Te ograniczenia uniemożliwiają administratorom lokalnym modyfikowanie ustawień systemu Android Enterprise dla całej dzierżawy i globalnego w pełni zarządzanego profilu rejestracji.

Ograniczenia rejestracji

  • Ten sam zestaw uprawnień podlega zarówno ograniczeniom konfiguracji urządzenia, jak i rejestracji. Gdy udzielasz uprawnień do tworzenia dla konfiguracji urządzenia, udzielasz również uprawnień do tworzenia ograniczeń rejestracji. Jednak administratorzy lokalni nie powinni mieć uprawnień do tworzenia profilów ograniczeń rejestracji. Dlatego należy poinstruować, aby nie tworzyć nowych profilów ograniczeń rejestracji.

  • Ograniczenia limitu urządzeń rejestracji określają liczbę urządzeń, które każdy użytkownik może zarejestrować. Ograniczenia limitu urządzeń rejestracji powinny obejmować wszystkie możliwe limity urządzeń dla administratorów lokalnych do udostępnienia. Aby uzyskać więcej informacji, przejdź do tematu Co to są ograniczenia rejestracji.

  • Zespół centralny powinien jak najwięcej ujednolicić ograniczenia typu urządzenia i dodać nowe ograniczenia, ale tylko jako specjalne wyjątki po przejrzeniu istniejących ograniczeń przez administratora lokalnego.

Kategorie urządzeń

Funkcja Kategorie urządzeń (Kategorie urządzeń>) nie ma własnej rodziny uprawnień. Zamiast tego uprawnienia są regulowane przez uprawnienia ustawione w obszarze Organizacja. Przejdź do pozycji Role administracji > dzierżawy. Wybierz rolę niestandardową lub wbudowaną, a następnie wybierz pozycję Właściwości. W tym miejscu możesz przypisać uprawnienia, z których jedno to Organizacja. Jeśli więc potrzebujesz uprawnień do odczytu dla kategorii Urządzenia, ustaw uprawnienia do odczytu w organizacji.

Zespoły centralne mogą tworzyć kategorie urządzeń. Jednak administratorzy lokalni nie powinni mieć prawa do tworzenia, aktualizowania ani usuwania kategorii urządzeń, ponieważ wymagałoby to udzielenia im uprawnień w organizacji, dając im dostęp do innych funkcji na poziomie dzierżawy podlegających uprawnieniom organizacji.

Aby uzyskać więcej informacji, przejdź do pozycji Kategorie urządzeń.

Analiza punktów końcowych

  • Zespół centralny powinien utworzyć tyle typowych punktów odniesienia usługi Endpoint Analytics, ile potrzebuje do obsługi wariancji administratorów lokalnych.
  • Jeśli to możliwe, administratorzy lokalni nie powinni tworzyć własnych punktów odniesienia usługi Endpoint Analytics. Po delegowaniu do dużej liczby administratorów całkowita liczba obiektów może stać się duża i trudna do zarządzania. Najlepsze rozwiązania różnią się w zależności od obszaru funkcji.
  • Aby uzyskać więcej informacji, przejdź do tematu Konfigurowanie ustawień w analizie punktów końcowych.