GPP, RDS i zawieszające się sesje

server, windows

ciekawy przypadek – użytkownicy nie mogą zalogować się do serwera terminalowego, ponieważ sesja zawiesza się na przetwarzaniu polis grupowych. serwer w2k8R2.

kilka ciekawostek:

  • w eventlogu cisza. żadnych błędów
  • nawet część dot. group policy eventvwrapplications and servicesmicrosoftwindowsgrouppolicy nie zawiera żadnych błędów – biało.
  • spodziewałem się, że będzie widoczna sesja usera, jakieś dowiązanie do plików cokolwiek – nihuhu
  • w process explorer nie widać żadnych procesów użytkownika, który się loguje – to dość zrozumiałe i do przełknięcia
  • w RD Managerze widać tą sesję w dość specyficzny sposób – jako ‘disconnected’ i z nieokreślonym statusem, bez nazwy użytkownika. jedyna dostępna opcja to ‘reset’ i jak się można domyślać – nie działa. czyli jedna próba logowania i żeby user mógł się zalogować – restart serwera
  • RSoP nie działa – zwraca timeout

    • jak widać debugowanie jest dość upierdliwe. szczęśliwie szybko wpadłem na pomysł jak sobie z tym poradzić [w dużym środowisq by to nie wyszło q: ] i zlokalizowałem polisę, która powodowała zawieszanie – chodziło o polisę mapująca drukarki mechanizmem Group Policy Preferences.

    biorąc pod uwagę, że użytkownicy normalnie pracują a problem jest tylko na serwerze RDS, udało mi się dojść o co chodzi:

    • drukarka A została dodana via GPP na stacji lokalnej użytkownika
    • ta sama drukarka zawieszała przetwarzanie polis, ponieważ na serwerze terminalowym była równocześnie przemapowywana mechanizmem RDP oraz dodawana dokładnie tą samą polisą.

    robiło się jakieś sprzężenie zwrotne, serwer reagował w głupi sposób, zawieszając cały proces przetwarzania polis.

    rozwiązanie:

    • w GPP do mapowania drukarek został dodany warunek ‘nie uruchamiaj jeśli nazwa netbios komputer = <nazwa RDS>’

    pacjent uratowany.

    eN.

    SCCM – rozszerzamy Hardware Inventory

    3 komentarzearticle, HOWTO, server

    Zbierałem się do napisania artykułu, a wyszło jak zwykle Puszczam oczko

    Więc szybka notka na blogu:

    SCCM za pomocą Hardware Inventory potrafi zbierać informacje nie tylko o sprzęcie, ale o wszystkim co mamy zapisane w WMI. Szczegółowo jest to opisane na MyITForum – http://www.myitforum.com/myitwiki/SCCMINV.ashx 

    Ostatnio trafił mi się przypadek – zbierz info o wszystkich profilach użytkowników i ich ścieżkach.

    Najpierw trzeba wyciągnąć info z kluczy rejestru HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList

    Więc do pliku configuration.mof dodajemy na końcu sekcję:

    #pragma namespace("\\.\root\CIMV2")

    #pragma deleteclass("Local_SID_List",NOFAIL)

    [dynamic,provider("RegProv"),ClassContext("Local|HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList")]

    Class Local_SID_List

    {

      [key]   string KeyName;

      [PropertyContext("ProfileImagePath")]  String ProfileImagePath;

    };

    Dzięki temu na każdym komputerze z zainstalowanym agentem SCCM-a w rootcimv2 stworzy się klasa Local_SID_List, która automatycznie będzie się wypełniać kluczami rejestru. Dzięki temu mamy parę: SID <-> profil

    Teraz trzeba połączyć SID <-> User. Żeby to osiągnąć dodajemy do tego samego pliku następną sekcję:

    #pragma namespace("\\.\root\cimv2")

    #pragma deleteclass("User_Account",NOFAIL)

     

    [Union,ViewSources{"select * from Win32_Account where SIDType=1"},ViewSpaces{"\\.\root\cimv2"},dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]

    Class User_Account

    {

      [key,PropertySources{"Domain"}]    string    Domain;

      [key,PropertySources{"Name"}]    string    Name;

      [key,PropertySources{"SID"}]    string    SID;

    };

    Na każdym kompie wyciągnie info o użytkownikach lokalnych. Jeśli chcemy mieć info o SIDach kont domenowych, to musimy po prostu mieć agenta SCCM na jednym z kontrolerów domeny (konta domenowe mają swoje instancje w klasie Win32_Account)

    Teraz trzeba zmusić agentów SCCM, żeby raportowali info z lokalnego WMI (instancje klas Local_SID_List i User_Account) do serwera. W tym celu modyfikujemy plik sms_def.mof

    #pragma namespace("\\.\root\cimv2\sms")

    #pragma deleteclass("Local_SID_List",NOFAIL)

    [SMS_Report(TRUE),SMS_Group_Name("Local_SID_List"),SMS_Class_ID("SMSExpert|Local_SID_List|1.0")]

    Class Local_SID_List : SMS_Class_Template

    {

      [SMS_Report(TRUE),key] string   KeyName;

      [SMS_Report(TRUE) ]    string   ProfileImagePath;

    };

     

    #pragma namespace("\\.\root\cimv2\SMS")

    #pragma deleteclass("User_Account",NOFAIL)

    [SMS_Report(TRUE),SMS_Group_Name("User_Account"),SMS_Class_ID("SMSExpert|Local_User_Account|1.0") ]

    Class Local_User_Account : SMS_Class_Template

    {

      [key,SMS_Report(TRUE)]    string    Domain;

      [key,SMS_Report(TRUE)]    string    Name;

      [key,SMS_Report(TRUE)]    string    SID;

    };

    Teraz SMS Provider na serwerze sam stworzy dane w bazie SQL (w formie tabel i perspektyw), które możemy wykorzystywać do tworzenia raportów. Jeśli nie chce nam się bawić w SQLki, to można na maszynie uruchmić SCCMowy Resource Explorer i obejrzeć wyniki Hardware Inventory.

    Co do dokładnego procesu tworzenia raportów – to już temat na inny wpis Uśmiech

    SCCM. notki z pola walki

    1 Komentarzfreeware, server, tools

    Ostatni sporo walczyłem z SCCMemem. tym, którzy nie znają, polecam artykuły Jacusia D. na http://jacekdoktor.pl/html/cm07.html jednym z nich, który ma wg mnie etykietę “must read” jest dotyczący instalacji tego narzędzia Belzebuba (parafraza opinii neXora Uśmiech z językiem ) na 2008/2008R2 – http://jacekdoktor.pl/html/webdav.html

    niestety mimo dobrych rad i artykułów nie zawsze to się udaje :/ czasami mimo przeprowadzania 10 lub 20 instalacji dostajemy jakiś nowy błąd. tym razem napatoczyłem się na coś takiego:
    SMS Management Point — Error 25006. Setup was unable to create the Internet virtual directory CCM_Incoming
    The error code is 80070005

    po chwili wyszukiwania okazało się, ze folder C:winsowstasks miał nieprawidłowe uprawnienia. po odpięciu szkodzącego GPO, zatrzymaniu usługi, skasowaniu folderu, uruchomieniu usługi Task Scheduler wszystko (IIS, WebDAV, BITS, Managememnt Point, WSUS) działa jak powinno Uśmiech

    dodatkowo jak już się uda Behemota doprowadzić do działania, jest szereg przydatnych narzędzi wspomagających jego działanie. większość można znaleźć tutaj: http://www.myitforum.com/myitwiki/SCCMTools.ashx 

    dodatkowo right click tools: http://myitforum.com/cs2/blogs/rhouchins/archive/2008/04/09/sccm-right-click-tools.aspx
    Console Extensions: http://myitforum.com/cs2/blogs/direland/pages/sccm-console-extensions.aspx 
    I oczywiście SCCM Toolkit 2.0, który zawiera niezbędne narzędzie Trace 32 http://www.microsoft.com/download/en/details.aspx?id=9257

    PS. Uwaga – bardzo lubię SCCM-a i uważam, że dobrze zaprojektowany i skonfigurowany jest fantastycznym narzędziem. większość problemów z nim wynika z kiepskiego wdrożenia lub implementacji rozwiązania.

    DFS–narzędzia

    1 Komentarzserver, tips'n'tricks, windows

    takie repozytorium narzędzi i linków dot. DFS jakie mi się zebrały podczas ostatnich 3 tygodni.

    Linki

    Narzędzia

    • dfscmd [wymaga instalacji DFS Namespace Role dla w2k8+] – do tworzenia katalogów i targetów w Namespace
    • dfsutil [j/w] – ogólnie dla tych, co nie lubią GUI – to co w snap-in’ie DFS
    • dfsradmin – narzędzie do tworzenia grup replikacyjnych i testów dla  DFSR
    • dfsrdiag – diagnostyka replikacji DFSR. ciekawa opcja w w2k8 R2 – replicationstate. ciekawe, ale nie ma oficjalnej doqmentacji żadnej poza ‘/?’
    • dfsrmig – do pełnej przesiadki na DFS czyli migracji SYSVOL
    • bardziej dla developerów – WMI DFS Provider
    • commandlety dla powershella do podstawowych operacji – czyli wykorzystanie WMI DFS Providera w praktyce

    eN.

    UEFI i serwery Blade IBM

    6 komentarzyserver

    Dziś miałem okazję pobawić się serwerami Blejodwymi od IBMa. Ustrojstwa te już wcale nie mają BIOSu, tylko UEFI http://pl.wikipedia.org/wiki/UEFI. Ogólnie pięknie, tylko po włożeniu płytki z W2k8R2 miałem piękny komunikat, że dyski (które są widoczne w instalatorze) nie mogą być bootowalne O_O Po szukaniu informacji na stronie IBM (istna masakra BTW), walk z diskpartem i szukaniu w UEFI opcji kompatybilności wstecznej, znalazłem coś takiego na stronach M$ http://www.microsoft.com/whdc/system/platform/firmware/uefiguide.mspxszczególnie interesujący był punkt:  Use Device Manager’s Firmware option and select Boot from file.więc znalazłem w UEFI opcję boot from file. namierzyłem na płytce plik  Boot64.efi i śmiga :D czy instalacja się udała, okaże się jutro :)

    ADFS 2.0 i Google Apps

    2 komentarzeCloud, server, windows

    Misja: uwierzytelniać klientów korzystających z Google Apps za pomocą SAML i Active Directory Federation Services.

    Niestety Google nie udostępnia Federation Metadata więc trzeba ręcznie skonfigurować Relying Partner Trust.

    Opis do tego jest niemalże wszędzie, jednak gdyby ktoś nie mógł tego znaleźć:

    Po stronie Google ustawiamy:

    1. Sign-in page URL https://naszadomena.com/adfs/ls  
    2. Sign-out page URL https://naszadomena.com/adfs/ls/?wa=wsignoutcleanup1.0  
    3. Change password URL https://nasza_strona_do_zmiany_hasla.naszadomena.com  

    Przy czym ostatnie pole jest nieobowiązkowe, nawet nigdy nie widziałem żeby gdzieś była użyta jego wartość.

    Dodatkowo należy zaimportować certyfikat używany przez ADFS do podpisywania tokenów (token-signing) wyciągnięty wcześniej za pomocą konsoli MMC dla ADFS 2.0

    Warto też zaznaczyć "Use a domain specific issuer " żeby zapytania przychodziły z adresu  https://www.google.com/a/naszadomena.googleapps.pl/acs zamiast z https://google.com

    Po stronie ADFS trzeba dodać nowy Relying Party Trust:

    Wybieramy ręczne wpisanie danych

    1. Profil ADFS 2.0
    2. Pomijamy certyfikaty (zostaną użyte domyślne)
    3. Włączamy protokół SAML i jako service URL wpisujemy:  https://www.google.com/a/naszadomena.googleapps.pl/acs 
    4. Jako relying trust identifier podajemy:  https://www.google.com/a/naszadomena.googleapps.pl/acs

    Do Relying Party Trust dodajemy Claim rules wysyłający LDAP atrybut e-mail jako Name ID.

    I tyle.Powinno działać, no prawie działa bo wylogowanie jest nieprzewidywalne. Raz wylogowuje poprawnie, raz pojawia się komunikat błędu ADFS, innym razem pojawia się błąd na stronie Google. Zero determinizmu, zdarzenia wydają się być całkowicie losowe.

    Problem wynika prawdopodbnie z tego, że Google źle przygotowuje zapytanie SAML do wylogowania i parametry są niewłaściwie parsowane. Tudzież ADFS nie do końca jest zgodny ze standardem i nie potrafi wyciągnąć informacji z prawidłowego zapytania generowanego przez Google. W wyniku czego nie udaje się wygasić poprawnie wszystkich cookies, u klienta. Tutaj należy pamiętać, że funkcja wylogowywania w SAML jest opcjonalna :-)

    W każdym razie przeładowanie strony https://adfs.naszadomena.pl/adfs/ls/?wa=wsignoutcleanup1.0 bez  dodatkowych parametrów wylogowuje skutecznie.

    Jako, że nie udało mi się znaleźć rozwiązania zastosowałem proste obejście polegające na tym, że w przypadku błędu wylogowywania przekierowuję ponownie na stronę wylogowania. Co prawda można się trochę zapętlić ale jak narazie nie udało mi się doprowadzić to takiej sytuacji.

    Do pliku error.aspx.cs dodałem (kod jest zależny od wersji językowej serwera ADFS, pewnie można sprawdzać sam kod błędu ale tego nie testowałem)

    if (Exception.Message == "MSIS7055: Not all SAML session participants logged out properly. It is recommended to close your browser.")
        {
            Response.Redirect("?wa=wsignoutcleanup1.0");
        }

    Zmodyfikowany plik znajduje się załączniku error.aspx.cs

    SCCM i synchronizacje

    1 Komentarzserver, tips'n'tricks

    Ostantnio walczyłem z Software Updates i Asset Intellignece z SCCM w środowisku gdzie jest proxy. Żeby przeglądać logi korzystałem oczywiście z genialnego narzędzia Trace 32 będą cego częścią toolboxa do SCCMa.

    Ale pojawiła się kwestia: jak wymusić synchronizację SUP-a albo AISP-a?

    jak to w SCCMie, jest to schowane w gałęzi Update Repository… I nigdzie indziej… chyba Winking smile

    WSUS-SCCM

    root AI trzyma polecenie synchronizacji katalogu, ale trzeba pamiętać, że można ją robić max raz na dobę.

    migawki, VSS, shadow copy, previous versions i inne takie

    1 Komentarzserver, tips'n'tricks

    czyli tak na prawdę wszystko to samo z trochę innego punktu widzenia. w razie gdyby ktoś nie przeglądał bloga GT (wątpliwe ale…) to ten art ma status ‘must see’.

    a ponieważ ja mam tendencje do wyjaśniania rzeczy jasnych dodam od siebie trochę podstaw/podsumowania:

    • migawka aka snapshot: pojedyncza kopia danych dysq zrobiona w określonym czasie.
    • shadow: nie wiedzieć czemu programiści eMeSa sami tworzą taki bałagan nazewniczy. w samym vssadminie ‘snapshot’ tworzy się poleceniem ‘create shadow’. tak, żeby było fajnie i ciekawie.
    • VSS aka Shadow Copy: Volume Shadow copy Service.
    • Previous Versions: nazwa używana w interfejscie, lista dostępnych snapshotów [polska nazwa mnie dziwnie boli (; może kiedyś się przyzwyczaję.. ] wykonanych za pomocą mechanizmu VSS

    to tak dla jasności, żeby nie pogubić się w skrótach.

    dodatkowo jeszcze ciekawostka: na kontrolerach domeny jest jeszcze jedno narzędzie, które pozwala utworzyć snapshot: ntdsutil. czym to się różni od zwykłego? snapshot ntdsutil jest typu “ApplicationRollback” co wiąże się z atrybutami “Persistent, No auto release, Differential, Auto recovered” natomiast zwykły snapshot, wykonany za pomocą komponentu Previous Versions ma atrybuty: “Persistent, Client-Accessible, No auto release, No writers, Differential”. Atrybut client-accessible powoduje, że kiedy z interfejsu się sprawdza dostępne migawki – widać ich listę. poza tym różnic specjalnych nie ma – działa mklink, w snapshocie są wszystkie pliki całego dysq [a nie, jak by można się spodziewać tylko pliki bazy NTDS], itd.

    przy okazji jeszcze jedna ciekawostka: pomimo, że powershell ma być zastępstwem dla cmd, to komeny mklink nie implementuje. obejściem może być albo użycie [LOL] :

    cmd /c "mklink $d `"$link`" `"$target`"" > $null

    albo użycie fsutil create hardlink.

    zrobienie snapshotu dostępnego przez sieć bez programowania nie udało mi się znaleźć. miło byłoby móc zrobić snapshot i zdalnie dostawać się do kopii plików..

    eN.