it-flow.pl

Ostatnimi czasy zdarza mi się doradzać czy też może prowadzić jakieś dłuższe uzasadnienia dlaczego SCCM to jednak przydatne narzędzie. Niestety w przypadku niektórych osób nie jest to łatwe, szczególnie gdy ktoś wydaje sporo na software, przy którym administrator spędza kilka godzin tylko po to by zainstalować jedną paczkę. Niestety jak to zwykle bywa, na konferencjach czy prezentacjach często stykamy się z hasłami:

•  “Pamięta Pan jak administrator tłumaczył się, że nie może zdalnie zainstalować tego oprogramowania na waszych 600 komputerach ponieważ producent nie udostępnił paczki MSI? Od teraz będą Państwo mogli w dowolnej chwili zainstalować dowolne oprogramowanie niezależnie od typu instalatora!”
• “… I teraz widzimy jak  w przeciągu 4 minut stworzyliśmy paczkę, którą możemy w dowolnym czasie rozdystrybuować na wszystkich stacjach w naszej firmie…. Sam użytkownik stacji roboczej nie musi przechodzić przez proces instalacji.”

Wszystko fajnie, niestety jak to mówią: Lucyfer tkwi w szczegółach, które często są pomijane przez osoby reklamujące dany produkt. Nie ma w tym nic dziwnego, przecież sprzedawca zawsze chce zarobić na systemie. Niestety w 80% przypadków przedstawiając wady danego produktu lub czas jaki będzie musiał poświęcić administrator na konfiguracje niestandardowych programów, nasz sprzedawca raczej nie utrzymałby się w branży.

W przypadku chęci wykorzystania SCCM do dystrybucji oprogramowania trzeba pamiętać  o tym, że Configuration Manager nie odpowiada za przygotowanie samego instalatora. Ta czynność nadal pozostaje w gestii administratora. Jeśli chcemy zainstalować dowolne oprogramowanie bez ingerencji użytkownika to musimy przygotować odpowiedni skrypt, plik podpowiedzi, zapoznać się z parametrami instalatora. W przypadku większości aplikacji proces ten może trwać od trzech do pięciu minut. Jeśli chcemy przygotować bardziej zaawansowaną instalację musimy się liczyć z faktem, że wymagany czas może drastycznie wzrosnąć.

Po utworzeniu paczki, trzeba ją jeszcze przetestować, sprawdzić czy instalator się nie zawiesza w dowolnym kroku, czy proces instalacji trwa tyle co zakładaliśmy, itd.

Podczas ostatnich potyczek z Windows 7 i Cross realm zauważyłem ciekawą rzecz. W przypadku wykorzystania interfejsu hosta poprzez maszyny wirtualne (Bridged connection) z stacji hosta na którym jest zainstalowany VMware można uruchomić Wiresharka i śledzić ruch przesyłany z maszyn wirtualnych w świta. Jedynie w celu wyczyszczenia zbędnego ruchu warto użyć filtru ip.addr=Adres_IP. Jest to o tyle przydatne, że nie trzeba się bawić w zdalne łapanie ruchu. Niby oczywista rzecz a przez kilka dni męczyłem się w zdalne łapanie ruchu czy przełączanie między kontami na jednej stacji.

Migracje, migracje i jeszcze raz migracje. Od pewnego czasu siedzę i staram się poprawić i udoskonalić stare usługi, zaktualizować systemy, itd.

Jedną z bardziej interesujących rzeczy jest migracja z Windows XP do Windows 7. Jak to zwykle bywa jednym z częstszych problemów jest odpowiednia konfiguracja systemów do współpracy z trustem między REALM-em MIT Kerberos a Active Directory.

W Windows 7 Microsoft wprowadził sporo zmian część z nich dotyczy konfiguracji samego logowania do REALMu.

Główne zmiany to:

• Uproszczenie konfiguracji samego REALMu na stacjach klienckich
• Wyłączenie przestarzałych mechanizmów szyfrowania (DES-CBC-{CRC,MD5})- źródło
• Wprowadzenie odpowiedniego szablonu polis do konfiguracji REALMu

Po instalacji Windows 7 i wpięciu systemu do domeny rozpocząłem konfigurację REALMu. Po małym przeglądnięciu kilku stron amerykańskich uniwersytetów okazało się, że konfiguracji realmu w Windows 7 nie przeprowadza się już za pomocą ksetup.exe:

ksetup.exe /addkdc nazwa_realmu nazwa_serwera_kdc_dla_podanego_realmu

ksetup.exe /domain nazwa_domyslnej _domeny

Dla ułatwienia Microsoft utworzył odpowiedni szablon polis:

Na początku zainteresowałem się tylko dwiema opcjami:

• Define interoperable Kerberos V5 realm settings – opcja odpowiada za odpowiednią konfigurację realmu oraz serwerów KDC, które ma wykorzystać klient. W Windows XP konfiguracja tych ustawień dobywała się za pomocą ksetup.exe
• Require strict KDC validation – sprawdza pewne obostrzenia dotyczące certyfikatu serwera KDC.

Dodatkowo skusiłem się na ustawienie DefaultLogonDomain na nazwę mojego Realmu. Jak większość pamięta od Visty z ekranu logowania zniknęła możliwość wyboru domeny/realmu logowania. Aktualnie użytkownik ma się logować za pomocą User Principal Name (login@nazwadomeny). Ustawnie DefaultLogonDomain pozwala logować się do domyślnej domeny/realmu za pomocą samego loginu

Jeśli, ktoś nie chce konfigurować tych ustawień za pomocą GPO to może wykorzystać odpowiedni wpisy w rejestrze

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
“DefaultLogonDomain”=”Nazwa_Realmu”

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos]
“MitRealms_Enabled”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\MitRealms]
“Nazwa_Realmu”=”<f>0×00000008</f><k>serwer_kdc_1;serwer_kdc_2</k>”

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
“KdcValidation”=dword:00000002

W przypadku trzeciego ustawienia (Define interoperable Kerberos V5 realm settings) między <f></f> podajemy w postaci hex-a listę opcji, które mają być wykorzystane podczas odpytywania serwerów KDC w danym realmie:

• 0×00 None – brak flag
• 0×01 SendAddress – pozwalaj na adresy IP w generowanych ticketach
• 0×02 TcpSupported – serwery kluczy akceptują ruch TCP, wymagany przy dużych pakietach
• 0×04 Delegate – każdy w realmie jest zaufany do delegacji
• 0×08 NcSupported – podany realm wspiera Name Canonicalization

Przepraszam za trochę lakoniczne tłumaczenie, więcej informacji o opcjach w technecie.

Jeśli po konfiguracji nie udaje się zalogować do systemu. Występuje komunikat błędny login lub hasło, to najprawdopodobniej serwery kluczy wykorzystują mechanizmy DES-CBC-CRC lub DES-CBC-MD5, które w Windows 7 i Windows Server 2008 R2 zostały domyślnie wyłączone. Włącznie mechanizmów najlepiej wykonać za pomocą GPO:

Tutaj taka drobna uwaga, którą podał Tomek Onyszko na wss.pl. W niektórych przypadkach warto wyłączyć AES128 i AES256 jeśli nie jest on wykorzystywany.

Po zmianie tych ustawień można się poprawnie zalogować używając MITowskiego realmu. Niestety po zalogowaniu na użytkownika nie zostały nadrzucone polisy oraz sam użytkownik nie miał dostępu do serwerów będących w domenie Windows. Co prawda w logach DC widać, że zaszło mapowanie użytkownika z realmu na użytkownika w AD jednak polecenie klist nie wyświetla wymaganych ticketów.

Po trzech dniach spędzonych przy Wiresharku postanowiłem zapytać na wss i jak zwykle w sprawach związanych z Kerberosem Tomek Onyszko okazał się być bardzo pomocny. Nie wiem jak mu podziękować bo gdyby nie jego pomoc to nadal ślęczałbym nad ekranem z dumpem wiresharka.

Poniżej postaram się krótko opisać gdzie tkwił problem.

W przypadku zaufania między domenami czy realmami, komputer odpytuje odpowiednie serwery kluczy w celu pozyskania odpowiednich ticketów, które później będzie wykorzystywał do uzyskania dostępu do konkretnych serwerów. W tym poście nie będę tego jakoś szczególnie opisywał (dobry materiał na kolejny post). W skrócie jeśli klient nie dostanie ticketu z serwera kluczy z jednej domeny to prosi o odpowiedni ticket Granting Services, który pozwala mu odpytać kolejny serwer kluczy odpowiedniej domeny.

Tak robił XP, który jest aktualnie na stanowiskach:

Powyższy zrzut ekranu obrazuje prośbę klienta o odpowiedni ticket na potrzeby dostępu do miejsca gdzie leża polisy:

1. Klient prosi o TGS serwera KDC w realmie, w którym uwierzytelnił się użytkownik
2. Serwer kluczy dla danego realmu zwraca informacje PRINCIPAL_UNKNOWN – informacja o określonym SPN znajduje się w innym serwerze kluczy ( w moim przypadku kontrolerze domeny z którą zestawiony był trust realm )
3. Klient prosi o TGS (krbtgt/nazwa_realmu) ticket jest wymagany by klient mógł rozmawiać z zaufaną domeną
4. Serwer kluczy w naszym realmie odsyła odpowiedni ticket
5. Klient prosi kontroler domeny o określony ticket dla cifs/nazwa_kontrolera (strzałka 3 na zdjęciu), wykorzystując ticket, który otrzymał w kroku czwartym.
6. Serwer zwraca odpowiedni ticket.
7. Klient przystępuje do komunikacji z serwerem plików.

W przypadku Windows 7 spraw wyglądała trochę gorzej ponieważ, system pomijał prośbę o TGS (krbtgt, oraz o odpowiedni ticket w zaufanej domenie i przeskakiwał na NTLM):

Jak widać na powyższym zrzucie ekranu klient:

1. Pyta serwer kluczy dla wykorzystywanego realmu
2. Serwer zwraca odpowiedź o braku Principala o określonej nazwie (2)
3. Klient próbuje wykorzystać NTLM by dostać się do zasobów.
4. Próba w dalszej części kończy się fiaskiem.

Po pomocy Tomka okazało się że problem ten można rozwiązać poprzez wskazanie systemowi klienckiemu jakie nazwy realmow/lasow ma przeszukiwać. Można to skonfigurować w GPO ( pierwsze zdjęcie w wpisie) Use forest search order. Po dopisaniu tam nazwa_realmu, nazwa_domeny_ad, klient zaczyna odpytywać kontroler. Jedynym minusem który tutaj występuje jest brak zapytania ok określony  TGS (krbt/…) jednak ticket ten zostaje pobrany na samym początku podczas logowania do domeny. Po ostatniej zmianie klient zaczyna poprawnie funkcjonować:

• pobierane są polisy dla użytkownika
• można uzyskać dostęp do określonych zasobów dyskowych w zaufanej domenie.

Przyznam się, że problem jest dość ciekawy i w wolnej chwili trzeba się będzie trochę bardziej w niego zagłębić. Ale wcześniej muszę sobie skonfigurować wirtualnej środowisko by nie bawić się w zamazywanie zrzutów z Wiresharka. Przy okazji może uda mi się opisać proces konfiguracji Cross Realm Trusta.

Jak zwiększyć dostępność usługi DHCP w naszej sieci? Z pomocą przychodzą nam dwa rozwiązania:

- reguła 80/20

- klastrowanie usługi DHCP

W przypadku klastra sprawa jest prosta:

• instalujemy kilka węzłów przyszłego klastra
• tworzymy wspólny zasób na potrzeby klastra.
• tworzymy klaster dla usługi DHCP

W przypadku reguły 80/20 konfiguracja jest trochę bardziej skomplikowana. Poniżej postaram się w kilku zdaniach opisać działanie i konfigurację tej reguły.

80/20 w założeniu ma zwiększyć dostępność usługi DHCP w przypadku awarii jednego z serwerów. Ogólnie rzecz ujmując 80% niezarezerwowanych adresów jest przydzielana przez jeden serwer a reszta poprzez drugi.

Jakie korzyści niesie konfiguracja reguły 80/20?

Jak można szybko zauważyć w przypadku naszej konfiguracji cała reguła wymaga od nas poprawnej konfiguracji wykluczeń. Podczas działania obu serwerów reguła nie wnosi nic poza drobnym odciążeniem Serwera 1. Sytuacja zaczyna robić się ciekawa gdy awarii ulegnie serwer 1. Wtedy tylko 20% niezarezerwowane adresów może zostać przydzielonych z drugiego DHCP. Jeśli nasza sieć jest duża to 20% adresów bardzo często może pokryć tylko cześć pomieszczeń lub kilka pięter dużego budynku. Na szczęście po awarii lub celowym wyłączeniu serwera administrator może usunąć wykluczenie z drugiego serwera i tym samym udostępnić do dystrybucji wszystkie wolne adresy, które przynależą do skonfigurowanego zakresu. Jeśli serwer 1 zacznie znowu funkcjonować to administrator musi ponownie nałożyć nowe wykluczenie na drugim serwerze.

Dlaczego cały czas mówisz o niezarezerwowany adresach, co z rezerwacjami?

W przypadku rezerwacji administrator jest zmuszony do utrzymania identycznych rezerwacji na obu serwerach. Tak jak pisałem w poprzednim wpisie o wykluczeniach, serwer DHCP na systemie Windows może rozdawać zarezerwowane adresy, które leżą w wykluczonej części. Tak więc administrator jest zmuszony to utrzymania spójnej listy rezerwacji. Dobrze jest napisać odpowiedni skrypt do tworzenia rezerwacji na obu serwerach.

Kiedy nie trzeba usuwać wykluczenia?

Jeśli w naszym zakresie mamy 200 adresów a mniej niż czterdzieści jest przydzielanych bez rezerwacji to wtedy nie ma potrzeby usuwania wykluczenia.

Czy muszę ręcznie usuwać wykluczenia?

Nie. Jeśli potrafisz napisać proste skrypty to np. za pomocą batch-a, vbscript-a, powershell-a da się napisać proste skrypty uruchamiane w harmonogramie zadań. Działanie skryptu ogranicza się do:

• Sprawdzenia czy serwer jest dostępny:
• Jeśli dodatkowy serwer jest niedostępny to usuwamy wykluczenie.
• Jeśli serwer jest dostępny to nakładamy wykluczenie na nadmiarowe adresy.

Jak skonfigurować serwery?

1. Instalujemy na dwóch serwerach usługę DHCP
2. Konfigurujemy na obu serwerach ten sam zakres adresów oraz niezbędne opcje
3. Na pierwszym serwerze wykluczamy 20% końcowych adresów
4. Na drugim serwerze wykluczamy 80% początkowych adresów.
5. W razie potrzeby na obu serwerach wpisujemy te same rezerwacje.

Skonfigurować klaster usługi DHCP czy wykorzystać regułę 80/20?

To zależy:>

Jeśli masz już w sieci zainstalowany klaster typu Failover i nie jest on zbyt mocno obciążony to można na nim skonfigurować usługę DHCP, która domyślnie będzie przetwarzana przez aktualnie niewykorzystywany węzeł.  Jeśli nie posiadasz w sieci serwerów działających w klastrze FO to bardziej opłacalna będzie konfiguracja reguły 80/20. Usługa DHCP nie obciąża zbyt mocno systemu więc można ją uruchomić nawet na małej maszynie wirtualnej. Dodatkowo reguła 80/20 nie wymaga posiadania dostawowej przestrzeni dyskowej na kolejnym serwerze.

Ostatnio zostałem zapytany o to jak wymusić pojawienie się ikonki klienta Software Update gdy są dostępne nowe aktualizacje lub system czeka na restart.

Po drobnym szperaniu w systemie i kilku testach, okazało się, że w przypadku zdalnego podłączenia się do Windows 2k3 ikona (1) jest wyświetlana tylko w sesji 0. Trochę się zdziwiłem, bo na  Wind2k8 wszystko działa ok i ikona pojawia się niezależnie od rodzaju nawiązanej sesji.

Nie lubię diagnozować problemów z replikacją. Zazwyczaj problemy te są proste do zidentyfikowania i poprawienia, jednak czasem człowiek wyrywa sobie włosy z głowy.

W jednej z domen, którą zarządzam mam mieszane środowisko Wind2k3 i Win 2k. Zazwyczaj wszystko pięknie chodzi, co często usypia moją czujność i pozwala mi zapomnieć o niektórych maszynach na długi czas ( czasem w końcu trzeba wgrać poprawki). Po ostatnich przenosinach, podmiankach, wymianach, readresacjach…, które odbyły się o dziwo bez problemu od pewnego czasu w logach pojawiały się Eventy 1311, 1566. Osoby zajmujące się Active Directory stwierdź – haha standardowe problemy How to troubleshoot intra-site replication failures. No i wszystko fajnie przeszedłem całą standardową procedurę omijając kroki, które mnie nie dotyczą, czyli ogólnie: repadmin …, net stop lsass …, netdom resetpwd …, net start lsass. Po restarcie wszystko działa jak poprzednio , replikacja nadal Access Denied. Wireshark mówi, że kontrolery się komunikują jednak DC wyraźnie stwierdza ze KCC nie może zbudować topologii replikacji.  Repadmin stwierdza, że wszystko spięte, połączenia istnieją, itd.  Jak się okazało rozwiązaniem problemu była aplikacja łatki Q819249.

In Windows 2000, the Knowledge Consistency Checker (KCC) uses the Intersite Messaging service to help it build the spanning tree topology for Microsoft Active Directory directory service replication. In a very small percentage of cases, Intersite Messaging may not complete building the hash table that it passes to the KCC. When the KCC uses this hash table in its calculations, this may generate the KCC logging event ID 1311 in the Directory Services event log.
This problem typically occurs in environments with large numbers of sites, domain controllers, and domains.

W sumie niewiele brakło a zadałbym pytanie na WSS. Jednak stwierdziłem, że skoro od pewnego czasu interesuję się AD to trzeba sobie z problemami radzić samemu <taniec szczęścia>.

Kilka dni temu skusiłem się na zakup uaktualnienia VMware workstation z 6.5 do 7. Na stronie vmware jest opis nowych dodatków, które zostały zaimplementowane w Workstation 7. Mnie najbardziej interesowało wsparcie dla Windows 7 jako systemu hosta i gościa.

Sama aktualizacja przeszła dość szybko. Niestety co pewien czas przytrafiały mi się różne problemy z siecią, które często ignorowałem. Pewnego dnia okazało się, że połączenie się do nowej sieci czy zestawienie VPN na systemie hosta potrafiło całkowicie zawiesić system.  Po kilku godzinach wpadłem na pomysł by powyłączać mechanizmy mostka, które dorzuca VMware do połączeń sieciowych. Jak się okazało wyłączenie tej funkcji spowodowało usunięcie problemu z zawieszającym sie systemem jednak uniemożliwiło wykorzystanie mostkowanego połączenia w maszynach wirtualnych.  Niestety mam kilka maszyn, które po prostu muszą być podpięte bezpośrednio do tej samej siec co host.

W niedzielny wieczór (hmm w sumie to już była 4 nad ranem) okazało się, że po instalacji VMware i restarcie systemu należy się zalogować na konto administratora i poczekać, aż workstation7 doinstaluje niezbędne komponenty.  Jeśli pominiemy ten krok to może się okazać, że co pewien czas mogą się pojawiać dziwne problemy z maszynami wirtualnymi.

PS

Aktualnie przymieszam się napisać coś więcej o tym problemie na community VMware by utwierdzić się w przekonaniu, że faktycznie problem wygenerowałem sobie sam wykorzystując do instalacji zwykłe konto i UAC:(

Ostatnimi czasy byłem zmuszony wrzucić kilka pakietów, które napsuły mi sporo krwi przez swoje przełączniki do cichej instalacji oraz domyślne opcje instalatora.

Po przetestowaniu paczek na wirtualce przyszła kolej na produkcje.  Kilka kliknięć i poszło. Patrzę w Advertisement Status, wszystkie stacje ładnie pobrały ogłoszenie o poprawkach jednak większość nie zaraportowało o tym, że rozpoczęły proces instalacji. Przeglądając logi znalazłem wpisy, który rozpoczynał się od słów:

Software Distribution is currently paused

Myślę sobie “Hmm, zapominałem o restarcie?”. Psshutdown i czekamy, czekamy, czekamy i dalej to samo wszystko pobrane ale nie uruchomione. Bracia Google i Bing powiedzieli, że prawdopodobnie nie zakończył się popranie jakiś TS. Na Social MS ktoś napisał, że jeśli klient SCCM nie dostanie sygnału od TS przez 24h to sam odblokuje sobie blokadę instalacji softu. Trochę to dziwne bo ostania sekwencyjna instalacja poszła całkiem ładnie.

Po 24h:

Software Distribution is currently paused

Hmm, powoli zaczyna się robić nerwowo. PSexplorer nie pokazuje żadnego podejrzanego procesu, restart nie pomógł, ponowne uruchomienie niektórych usług też nie pomogło. Po 30 minutach przez pomyłkę, zamiast zrestartować usługę klienta SCCM, uruchomiłem usługę Task Sequence Managera. TSM jak to zwykle wstał i potem się zatrzymał, odchodzę już zdenerwowany od komputera i nagle coś miga na ekranie(:

Instalacja nowej aplikacji rozpocznie się za 4,3,2,1

Uff, dzień zabawy z vCenter. Od pewnego czasu trzeba było zaktualizować vCenter do nowszej wersji:) Dziś się za to zabrałem i muszę przyznać, że trochę zeszło (7h z przerwami):/

Po dzisiejszych zabawach parę uwag:

1. Jeśli  vCenter 2.5 było zainstalowane na kontrolerze domeny to nie da się go zaktualizować. Wynika to z faktu, że nowe vCenter wykorzystuje ADAM, który z wiadomych przyczyn nie może zostać zainstalowany na kontrolerze domeny Tak więc jeśli migrujesz do wersji 4 postaw sobie maszynkę wirtualną (zgodnie z zaleceniami VMware) i na niej instaluj od zera nowe vCenter server.
2. Niestety zrobienie remove na węźle ESX, który jest w starym klastrze  wymaga zatrzymania wszystkich maszyn wirtualnych i przejścia w tryb maintenance mode. Jeśli w tym klastrze na maszynie wirtualnej mamy nową instalacje vCenter  to wyłączenie jej raczej jest strzałem w kolano. Dlatego najlepiej na węzłach zrobić disconnect i potem usunąć je poprzez opcje remove z starego vCenter. Operacja ta spowoduje odłączenie serwerów ESX jednak nie zatrzyma maszyn, które są na nich umieszczone. Następnie na nowym vCenter dodajemy wypięte węzły. Maszyny na tych węzłach będą cały czas uruchomione. Jedynie podczas dodawania węzła do nowego vCenter może on (ale nie musi) rzucić ostrzeżenie, że  jest już związany z innym serwerem vCenter.
3. Po przepięciu węzłów nie usuwamy starego serwera licencji. Dopóki ESX nie zostaną uaktualnione do wersji 4.0  nie będą mogły skorzystać z nowego sposobu pobierania licencji z serwera vCenter 4. Stary serwer licencji usuwamy dopiero jak zaktualizujemy wszystkie ESX i zobaczymy na starym serwerze licencji, że żadna licencja nie jest wykorzystywana.
4. Aktualizacje ESX do wersji 4.0 przeprowadza się za pomocą update managera, który jest dostępny w nowym vCenter. Podajemy mu kulturalnie obraz iso ESX 4.0 i konfigurujemy trzy opcje dotyczące uaktualnień. Następnie przypinamy polisę uaktualnienia do każdego węzła. Jeśli za pierwszym razem uaktualnienie zakończy się fiaskiem trzeba zmodyfikować polisę (zgodzić się na licencje i kliknąć trzy razy next:)
5. Client vCenter nie działa poprawnie na windows 7 RC:( Trzeba wykorzystać windows mode.

To chyba tyle wskazówek, które mogą się przydać. Przepraszam za jakość wypowiedzi jednak aktualnie próbuję nie zasnąć na backspace.

Jeśli coś jeszcze wpadnie mi do głowy odnośnie migracji Vi do vSphere to postaram się dopisać.

Jeśli ktoś potrzebuje stworzyć kolekcje w oparciu o konkretną jednostkę organizacyjną należy pamiętać o kilku rzeczach.

Podczas włączania Metod wykrywania komputerów w AD poza włączeniem “Active Directory System Discovery” należy też włączyć “Active Directory System Group Discovery”. Dopiero po włączeniu obu tych opcji będzie można przydzielać komputery do określonej kolekcji na podstawie OU w którym się znajduje.

Wynika to z faktu, że:

1. Active Directory System Discovery – zbiera nam takie informacje jak:

• Computer name
• Active Directory container name
• Active Directory site name
• IP address
• MAC address
• SMS assigned site
• SMS Unique Identifier (GUID

1. Active Directory System Group Discovery – dodaje takie informacje jak:

• Organizational unit
• Global groups
• Universal groups
• Nested groups
• Nonsecurity groups

Następnie podczas tworzenia zasad przynależności do danej kolekcji trzeba ustawić by wartość System Resource –> System OU Name była równa pełnej ścieżce OU. Np: TESTY.LOCAL/FINANSE/BUDYNEK1.