Skip to Content

IT nieuczesane.
category

Category: article

Microsoft Teams – złe strony medalu

Problemy w MS Teams

ponieważ podzieliłem się ogólną oceną Teams, jak na członka Loży Szyderców przystało, czas podzielić się spostrzeżeniami, których raczej nie znajdzie się oficjalnych materiałach.

najciekawszy artyqł dotyczący słabości Teams znalazłem na Petri. poza opisywanymi komplikacjami związanymi z faktem, że nie do końca wiadomo gdzie tak na prawdę dane Teams, największym wynikającym z tego problemem jest fakt, że nie bardzo wiadomo jak tworzyć kopię zapasową danych, a zarazem bardzo łatwo je usunąć, nieomal przez przypadek.

usunięcie grupy o365

usunięcie jest stałe i nie ma tzw. ‚soft delete’ pozwalające na szybkie przywrócenie. jak może dojść do usunięcia całego projektu? otóż Teams oparte jest [m.in.] na mechanizmie Office 365 Groups. o365G są współdzielone z innymi aplikacjami – np. Planner. czyli jedna grupa jest podstawą dla wielu innych aplikacji. o obu tych rozwiązaniach – o365 Groups oraz Planner napiszę pewnie więcej w przyszłości ale teraz ciekawy, acz straszny scenariusz:

tworząc nowy zespół w Teams automatycznie tworzone jest wiele innych elementów: grupa o365, site SharePoint, plan w Planner i kilka innych elementów. Teams spina to w całość. plan można podpiąć w Teams jako zakładka albo wejść bezpośrednio przez aplikację Planner. no i załóżmy, że zrealizowaliśmy już zadanie w Plannerze i chcemy je usunąć wraz z taskami. robi się to klikając w trzykropek -> Edit Plan -> delete Plan… i tu zaczyna się ciekawie.

pomimo opisu ‚Delete Plan’ osoba, która się nie wczyta w treść ostrzeżenia dokona potwornej rzezi, usuwając grupę o365, a wraz z nią wszystko – Teams, doqmenty, portal SP i tak dalej… a ponieważ nie ma soft-delete ani kopii zapasowej… robi się bardzo smutno.

można powiedzieć, że o grupy o365 należy dbać jak o własne oko.

wiele planów

o ile z poziomu aplikacji Planner można założyć tylko jeden plan per grupa, o tyle z Teams można założyć kilka planówi – jako zakładki – czyli do jednej grupy będzie dowiązane wiele planów…. z tą drobną niedogodnością, że nie są one dostępne z poziomu Plannera. nie działają linki przekierowujące, a jeśli usunie się zakładkę, to pozostanie osierocony plan.

czyli – jeden zespół, jedno zadanie do zaplanowania…

synchronizacja grup

jakoś to jest dziwnie skonstruowane – jeśli założy się zespół, to grupa o365 widoczna jest natychmiast w panelu office365. ale jeśli założy się, lub zmodyfiqje grupę z poziomu panelu o365, to zmiana synchronizowana jest… do 24h [SIC!].

jest to ponoć w trakcie przeróbek i zachowanie powinno zmienić się w najbliższych miesiącach.

Skype

kolejnym problemem, a może w tym przypadku – ‚utrudnieniem’ – jest inkorporowanie usługi Skype for Business, nie korzystając ze standardowych bibliotek. to bardzo dziwny wynalazek, krytykowany również przez sam team odpowiedzialny za SfB w MS. wszystkie konwersacje prowadzone w ramach Teams nie są widoczne nigdzie w SfB ani zachowywane w mailbox, również Presence jest oddzielnym bytem. całe rozwiązanie działa rozłącznie z ‚lokalnym’ SfB i powoduje to sporo niejasności.

dostępność

Teams wymaga licencji. szczęśliwie dostępny jest w większości licencji, więc wewnętrznie dla firmy może to nie być problem, niemniej np. w projekcie w którym uczestniczę, ze względu na dużą ilość użytkowników, migracja następuje krokowo, a licencje przypisywane są użytkownikom w kolejnych falach migracji. w takim scenariuszu, duża część użytkowników nie jest w stanie współuczestniczyć w projekcie.

większym i powszechniejszym problem jest brak wsparcia dla kont z poza organizacji – ten feature jest zapowiedziany, z tego plotek wiem, że ma się pojawić w ciągu 2-3 miesięcy. zobaczymy.

inne problemy i niedogodności

to oczywiście tylko główne przykłady. według mnie ważnym problemem jest również brak możliwości tworzenia skrótów do pliqw w ramach Teams. powoduje to, że przesunięcie pliq zamiast być jedną z podstawowych operacji staje się krytyczną, i zostawia uszkodzone linki lub duplikaty.

innym problem jest brak możliwości linkowania doqmentów z OneDrive. to z kolei zaburza podstawową ideę pracy na pojedynczej instancji pliq. czyli jeśli zaczęliśmy pracę nad plikiem w OD, to trzeba go dodać do Teams i na wszelki wypadek skasować, żeby nie utrzymywać dwóch kopii.

ale i tak jest super

podobnych niedogodności zalazłem jeszcze kilka, właśnie w ramach obsługi pliqw i uprawnień. niemniej jeśli się wie co omijać – nie są to jakieś straszne problemy. biorąc pod uwagę szybkość rozwoju aplikacji o365 można spodziewać się, ze niniejszy wpis będzie stawał się nieaktualny i wkrótce będzie można o nim zapomnieć.

eN.

Microsoft Teams

razem

Microsoft Teams to najmłodsze dziecko Office365 – GA ledwie 4 miesiące temu. zgodnie z nazwą, jest to narzędzie ułatwiające pracę grupową. od lutego uczestniczę w projekcie wdrożenia Office365, w którym postanowiliśmy wykorzystać to narzędzie i sprawdzić co to jest w ogóle warte… i muszę przyznać, że Teams są REWELACYJNE.

jeszcze w lutym Kamil opowiadał o Teams ogólnie, na WGUiSW i trochę się podśmiewaliśmy, że kolejne niepotrzebne narzędzie – wystarczy już szmatławego Yammera, kulejącego SharePoint, przestarzałej poczty, i niedorobionego Skype for Business – po co kolejny tool, który nie daje w zasadzie nic nowego?

może stwierdzenie ‚nie potrafię sobie wyobrazić pracy bez MS Teams’ jest na tą chwilę przesadą, ale potrafię sobie wyobrazić projekty, gdzie staje się jedynym wykorzystywanym narzędziem komunikacji. ma olbrzymi potencjał i należy się z nim koniecznie zaznajomić. ma oczywiście wady – jak każda wczesna [i późna zresztą też (; ] wersja aplikacji, ale nie zamierzam się na początq sqpiać na złych stronach. zatem…

…czym MS Teams są, a czym nie są

w zasadzie, żeby zacząć od początq, powinienem opisać ‚Office365 groups’… ale nie skleja mi się to, zacznę zatem w typowy dla mnie sposób – gdzieś od środka.

jedną z największych bolączek we wszystkich projektach/firmach jest Poczta Elektroniczna aka e-Mail, wykorzystywana do wszystkiego. gdyby nie limity na wielkości załączniqw, to programy do obróbki video musiałyby obsługiwać serwery poczty jako storage. efekt jest taki, że każdy plik, nad którym się pracuje, kopiowany jest do wielu osób. te wprowadzają poprawki, odsyłają, tworząc kolejne wersje i kopie pliqw. wyszukiwanie aktualnej wersji, komentarzy do treści czy zmian, to masakra.

rozwiązaniem na te bolączki, już dawno temu, miał stać się SharePoint. miał to być prosty, intuicyjny CMS z bibliotekami pozwalający na współdzielenie różnego typu obiektów [pliki, kalendarze, kontakty, wiki etc] i co ważne – automatycznym wersjonowaniem. opis niemal ‚jak ulał’ pasuje do MS Teams… jaka jest zatem różnica? SharePoint owszem, daje wszystkie te możliwości techniczne, ale z pominięciem pierwszej części – ‚prosty i intuicyjny’. samo korzystanie z SP jest co najmniej nieprzyjemne, no i ten cholerny klient do synchronizacji bibliotek… niby jest NGSC a do dnia dzisiejszego sprawia problemy i nie wspiera bibliotek z ewidencjonowaniem. ile to już lat? 16! [SIC!] Microsoft strzelił sobie w kolano, nie potrafiąc przez tyle lat zrobić prostego narzędzia ułatwiającego korzystanie z bibliotek SP.

…aż pojawiły się MS Teams. to jest prosty, intuicyjny front-end, łączący w jednym miejscu wiele aplikacji Office 365 [i nie tylko] – SharePoint, o365 groups, Planner, SfB, Office WebApps i więcej. efektem jest przestrzeń do pracy grupowej, funkcjonująca w intuicyjny, ‚naturalny’ sposób. pojawiło się już tyle wideo prezentujących Teams, że nie jestem pewien czy jest sens pisać kolejną ‚instrukcję obsługi’ ale kilka słów od siebie dodam.

  • kolejne dwa problemy przy projektach – rzadko kiedy wszyscy wiedzą kto zajmuje się czym – zawsze są dziury, choćby z tego powodu, że pojawia się nowe, nietypowe zadanie i ‚kto to ma zrobić’. efektów jest wiele – od problemów ze znalezieniem właściciela akcji, po masy spamu projektowego, gdzie maile wysyła się do kilqnastu czy nawet kilqdziesięciu osób, tak na wszelki wypadek żeby dotarło. czasem okazuje się, że w nagłówq i tak zabrakło tej kluczowej postaci, a pozostali są wqrzeni, że dzień-w-dzień przychodzi masa informacji, która ich nie dotyczy. prosty mechanizm kanałów tematycznych, które może założyć każdy z członków, pozwala na wprowadzenie porządq. jednocześnie informacja pozostaje dostępna dla wszystkich, dzięki czemu może być łatwiej dostrzeżona, przekierowana i obsłużona

  • podczas dysqji pojawia się potrzeba dodania pliq [lub odwrotnie – pojawia się plik wymagający dysqsji] – wystarczy go dodać… i zacząć razem pracować. w trakcie edycji pliq [korzystając wersji Office Web], cały czas widać kontekstowy dialog. niby drobiazg – ale w końcu nie muszę przegrzebywać się przez stosy wątqw dotyczących tego samego pliq, w różnych wersjach! w jednym miejscu mam plik, oraz całą dysqsję, która go dotyczy.

  • w ramach kanału są różne potrzeby – planowanie/logistyka, materiały video, Knowlege Base… – i wszystkie te materiały można po prostu podczepić jako kolejna zakładka dla kanału. kolejne ‚niby nic’ – ale dzięki temu nie muszę trzymać oddzielnie bookmarków do różnych materiałów, w różnych aplikacjach. w prosty sposób możemy udostępniać je wszystkim, i do tego kontekstowo – co nie jest bez znaczenia. przykład z życia – w ramach jednego z wątqw projektowych, który mnie nie dotyczy, utworzony jest mały site SP, na którym coś tam sobie wymieniają z zewnętrznymi vendorami. generalnie mnie to nie interesuje, ale musiałem coś szybko zweryfikować. wyszukanie ‚jakiegoś’ URLa w mailach sprzed kilq miesięcy, wysłanych przez ‚jakąś’ osobę, to mówiąc delikatnie ‚strata czasu’. kończyło się zazwyczaj kolejnym mailem z pytaniem ‚czy ktoś widział, czy ktoś zna’. teraz po prostu wchodzę na kanał danej grupy, a strona jest podczepiona jako zakładka. poniżej przykład, gdzie na kanale ogólnym wisi mała aplikacja zrobiona na SP do zgłaszania i obsługi problemów w ramach projektu

  • proste mechanizmy, dzięki którym projekt nie jest tysiącem puzzli, porozrzucanych po rożnych aplikacjach, a każdy z członków widzi inne elementy układanki. w końcu jest zorganizowany w ramach jednej przestrzeni [workspace], i każda nowa osoba dołączająca do projektu w naturalny sposób ma dostęp do całości, w zorganizowany sposób, zamiast musieć odtwarzać całość.

podsumowując

dawno nie byłem tak hmmm… podekscytowany żadnym gadżetem czy apką [Polacy raczej się nie ‚get excited about’, ale o dziwo tym razem, to słowo pasuje]. a zatem to pierwszy i na pewno nie ostatni wpis w tym temacie. aplikacja ma potencjał, ale bez wiedzy o jej wadach i problemach można zrobić srogą krzywdę całemu projektowi, niemal przez przypadek.

na koniec jeszcze jedna drobna dygresja dotycząca oczywistej oczywistości – że choćby nie wiem jakie narzędzia i jak intuicyjne dostarczyć, trzeba chęci nauczenia się pracy nimi/z nimi. niejednokrotnie zdarzyło mi się pracować w projekcie, gdzie SP był podstawą pracy grupowej, współdzielenia doqmentów, w projekcie oczywiście wykwalifikowani i wielokrotnie certyfikowani inżynierowie… a tam w bibliotece pliki typu:

  • Projekt XYZ_v1.o.docx
  • Projekt XYZ_v1.2.docx
  • Projekt XYZ_v2.o.docx

…przyzwyczajenia prawdziwą naturą człowieka…

eN.

Obronić się przed MiTM

Minęło wiele lat od kiedy napisałem tu ostatni post a do tego temat na (re)debiut już nie jest gorący. Chociaż z drugiej strony nie zdążył jeszcze wystygnąć i w każdej chwili może ponownie wybuchnąć. Ale do rzeczy. Dziesięć miesięcy temu okazało się, że przez pół roku Lenovo raczyło swoich użytkowników certyfikatami umożliwiającymi ataki MiTM (https://www.us-cert.gov/ncas/alerts/TA15-051A). Wiadomo, generalne oburzenie, Chińczycy nas śledzą, na pewno to sprawa służb, teorie spiskowe  i w ogóle koniec świata. Szczerze mówiąc temat spłynął po mnie jak po kaczce, sprawdziłem swój tablet (kupiony w przypływie weny wracając z baru po spotkaniu świąteczno noworoczny) i zapomniałem o temacie. Potem gdzieś pojawił się problem z Dell System Detect i zdalnym wywołaniem kodu, który został załatany przed opublikowaniem dziury (http://tomforb.es/dell-system-detect-rce-vulnerability). To ruszyło mnie trochę bardziej, sprawdzanie kto ma zainstalowane oprogramowanie i usunięcie starych wersji okazało się nie być trzema kliknięciami ale koniec końców temat załatwiony i systemy załatane w kilka godzin.

Niby dwie z pozoru niepowiązane rzeczy a jednak ostatnio okazało się, że niektórzy wolą się uczyć na własnych błędach zamiast na cudzych i Dell obdarzył nas kolejną serią serią wpadek (http://joenord.blogspot.in/2015/11/new-dell-computer-comes-with-edellroot.html,http://www.kb.cert.org/vuls/id/925497) instalując razem ze swoim oprogramowaniem certyfikaty w Trusted Root razem z ich kluczami prywatnymi. Do tej pory jest jeszcze prawie ok. Oprogramowanie potrzebuje coś samo podpisać żeby system się nie burzył przy instalacji, certyfikat jest oznaczony jako nieeskportowalny. Nie jest najgorzej, w końcu to narzędzie systemowe a nie aplikacja pokazujące  reklamy jak w przypadku Lenovo i jesteśmy zadowoleni dopóki nie zauważymy, że nasz kolega ma ten sam certyfikat a ktoś nam powie, że klucz prywatny można wyeksportować na przykład za pomocą mimikatz.

W głowie zaczynają układać się klocki pokazujące bardzo prosty scenariusz ataku:

  1. Eksportujemy certyfikat (patrz link powyżej)
  2. Stawiamy darmowe WiFi z SSID Starbunio i idziemy w pobliże kawiarni
  3. Czekamy na kogoś z laptopem Della kto podłączy się do naszego WiFi i otworzy stronę, którą warto przechwycić
  4. Zmieniamy SSID i miejsce bo w naszym pierwotnym celu są same błyszczące Maci
  5. Bingo, złapaliśmy klienta otwierającego stronę banku. Dla niego wszystko wygląda w porządku, jest https, jest zielona kłódeczka a przeglądarka nie ma żadnych podejrzeń. Dopiero jak gość będzie bardzo dociekliwy to okaże się, że certyfikat uwierzytelniający bank wystawił Dell a nie Verisign. My sobie po drodze cały ruch odszyfrowujemy, podmieniamy numery kont (bo kto to sprawdza w smssach) i jesteśmy szczęśliwi.

Problem pojawia się kiedy zdamy sobie sprawę, że nie tylko my możemy tak zrobić a nasi użytkownicy na pewno nie sprawdzają za każdym razem kto wystawił certyfikat stronie i możemy się założyć, że kwestią czasu jest kiedy wypłyną dane z naszej firmy albo ktoś dostanie karnego na Facebook’u. A co jeśli nie tylko Dell i Lenovo mają problem z certyfikatami? Będziemy czekać na białe kapelusze aż opublikują artykuły i łatać za każdym razem licząc na to, że czarne kapelusze nie wkroczyły jeszcze do akcji? A może pójdziemy o krok dalej i będziemy bardziej proaktywni sprawdzając czy mamy jakiekolwiek podejrzane certyfikaty na naszych komputerach?

Teoria mówi, że żaden certyfikat znajdujący się w Trusted Root Certification Authorities nie powinien mieć klucza prywatnego. Gdzieś daleko od nas jest CA a my jemu ufamy ponieważ znamy klucz publiczny CA pasujący do klucza prywatnego używanego do podpisywania certyfikatów. Tyle teorii, praktyka okazuje się być trochę bardziej brutalna ale o tym później.

Kiedy mamy problem z pomocą przychodzi korporacyjna nowomowa i nagle problem staje się on wyzwaniem, a kto nie lubi wyzwań? Do tego jeszcze można zaprzęgnąć lubianego PowerShell i System Center lubiane … inaczej ;)

Zaczynamy od kawałka banalnego kodu:

Który przeleci nam po wszystkich dostępnych certificates stores wyłączając z tego:

  • My – certyfikaty użytkownika/komputera
  • Remote Desktop – to chyba nie wymaga tłumaczenia
  • SMS – certyfikaty używane przez klienta SCCM

w tym kroku można się pokusić jeszcze o wyłączenie innych rzeczy (np. certyfikatów klienta SCOM) albo zamianę

na

żeby zaglądać tylko do Trusted Roots. Na razie trzymajmy się pierwszej wersji żeby zobaczyć co się w ogóle dzieje.

 

Jak już wiemy jakie mamy Certificates Stores to warto do nich zajrzeć i zobaczyć jakie mamy certyfikaty z kluczami prywatnymi

żeby uniknąć szumu wywalamy:

  • certyfikat Fiddlera – jego celem jest robienie MiTM i osoby mające go na komputerach wiedzą co robią
  • certyfikat zawierający z temacie nazwę hosta – tak to ciągle jest niebezpieczne ale wiemy, że ten certyfikat mamy tylko my i ewentualnie ktoś kto go nam wygenerował a nie cały internet. Takie świństwa podrzuca na przykład Skype ze skonfigurowanym Click to call

Reszta to proste działania mające na celu sprawdzenia czy mamy jakiekolwiek podejrzane certyfikaty i podanie ich listę lub potwierdzenie, że komputer jest ok.

 

Kiedy mamy już PowerShell to warto byłoby uruchomić go na wszystkich komputerach i sprawdzić kto ma coś podejrzanego na swojej maszynie. Fajnie byłoby też aby sprawdzanie odbywało się cyklicznie i informowało nas kiedy jest coś nie tak. Tutaj przydaje się SCCM i Compliance Settings.

Tworzymy Configuration Item uruchamiające skrypt i sprawdzające co jest na wyjściu

Configuration item

2015-12-08_21-47-13

Compliance Rules

2015-12-08_21-47-35

Compliance Rule

Potem robimy Configuration Baseline, dodajemy do niego nasz Configuration Item i robimy Deploy na kolekcje użytkowników oraz na kolekcje komputerów (odpowiednio All Users i All Systems). Ostatnie może się wydać trochę dziwne ale jest potrzebne żeby sprawdzić zarówno co mają użytkownicy jak i konto local system. Configuration baseline uruchomiony w kontekście systemu (Deploy na kolekcję komputerów) nie może zajrzeć do certyfikatów użytkowników bo te są trzymane w profilach*, a użytkownicy nie mogą zobaczyć jakie certyfikaty ma konto local system, za to zarówno użytkownik jak i local system mogą sprawdzić zawartość Certificate Store: Local Machine.

*-to nie jest do końca prawda bo można podmontować Hive i dekodować certyfikaty ale są na to prostsze sposoby

Jakby ktoś się pokusił dodatkowo o Remediation script żeby usuwać podejrzane certyfikaty to warto pamiętać, że Local System będzie mógł usuwać certyfikaty zarówno swoje jak o Local Machine a użytkownik będzie mógł usuwać wyłącznie swoje.

Na koniec pozostaje skonfigurowanie alertów, wysyłanie ich do SCOM i workflow do obsługi zdarzeń ale to już temat na osobny wpis.

 

PowerShell – nauka na błędach cz.IV.

Windows_PowerShell_iconna koniec samo ciało skryptu. logika.

pierwotny skrypt składa się w 2o% z komentarzy [dokumentacja] oraz 8o% z ciała skryptu zmieszanego z deklaracjami [management]. takie statystyki oznaczają jedno – to jest źle napisany skrypt. obecna wersja to [ok.] 27% komentarzy [dokumentacja], 18% deklaracje [magazyn danych], 4o% w funkcjach [siła robocza] oraz 15% ciała [management]. to oznacza, że:

  • jest jasna izolacja bloków kodu co zwiększa przejrzystość i wydziela zakresy odpowiedzialności
  • skrypt jest lepiej opisany,
  • duża część kodu może być wielokrotnie wykorzystana
  • a samo ciało zajmuje się wyłącznie zarządzaniem – niezbędna logika sterująca funkcjami [siłą roboczą] które z kolei korzystają ze zmiennych [magazyn].

dodam jeszcze, że całkiem przypadkiem, oba skrypty mają [u mnie] identyczną ilość linii.

deklaracje już były, pozostaje zatem do przedstawienia sama logika [silnik]:

i to wszystko.

ogólna idea jest bardzo prosta – zależnie od wybranego zakresu [$scope] wykonywane jest wyszukiwanie przy pomocy funkcji ‚doTheSearch’, opisanej w poprzedniej części. funkcji przekazywane są wszystkie niezbędne zmienne – informacja o rodzaju obiektu, definicja filtru oraz nazwa pliq wyjściowego, która jest zależna od typu wyszukiwania. jedyne, co jest nietypowe, to wykorzystanie prostych wyrażeń regularnych.

dzięki temu, że switch pozwala na wykorzystanie regex, można zastąpić wiele linijek ifów i elsifów bardzo kompaktowym zapisem – jak na załączonym obrazq. oznacza to, że podczas decyzji wykonywany jest $scope -match <regex> – czyli jeśli wpada parametr ‚Users’ to:

‚Users’ -match ‚nonExpiring OR all’ -> false
‚Users’ -match ‚Users OR all’ -> true, wykonaj kod

jeśli $scope jest równy ‚all’ – wpadnie we wszystkie zdefiniowane przypadki. wygodne.

obiecałem wyjaśnić bardziej złożone wyrażenie regularne, z poprzedniej części:

WTF? otóż te dwie linijki zastępują brzydkie, wielokrotne porównania, przyspieszając wyszukiwanie wartości w macierzy:

‚match’ jest ostatnio moim ulubionym operatorem. zastępuje -like ‚*coś*’ ale co ważniejsze – wyszuqje w macierzach. prosty przykład użycia przedstawiałem a propos wyszukiwania podstawowego adresu email. jest prosty, zastępuje bezsensowne pętle i … jest super szybki – nawet o rząd wielkości szybszy niż zastosowanie pętli. oczywiście nie ma to znaczenia jeśli w tablicy są 3 elementy – jak w tym przykładzie, ale jeśli ilość idzie w tysiące, zaczyna to odgrywać poważną rolę. a tutaj – po prostu jest geekowe =^.^’=

[regex]::escape($string) warto zapamiętać – jest to automat ‚escapeujący’ wszystkie znaki specjalne – kropki, przecinki, znaki z poza zakresu, slashe itd. dzięki temu cokolwiek by było w nazwie – zostanie automatycznie zmienione na string z pojedynczą interpretacją. w efekcie powstanie zwykły regex [widać wyescapeowane spacje]:

w efekcie wykonywane jest proste porównanie – „jeśli w distinguishedName znajdziesz którąkolwiek z wartości w $ouRX to…” i pozamiatane. warto zwrócić uwagę, że taka odwrócona logika jest bardziej ludzka, bo przedstawioną pętlę można przeczytać jako: „dla każdego elementu z $ouToSkip sprawdź, czy nie występuje gdzieś w distinguishedName. jeśli tak to…”, co nie jest po naszemu.

każda opowieść ma swój finał. ta kończy się w ten sposób:

download: find-UnusedADObjects

eN.

 

 

 

 

 

PowerShell – nauka na błędach cz.III.

Windows_PowerShell_icondziś ‚jeśli jakiś kod się powtarza – to najprawdopodobniej da się to zoptymalizować’. czyli funkcje.

w wyjściowym skrypcie szybko można zauważyć, że zarówno dla obiektu user oraz computer operacje są niemal identyczne. oczywiście są niektóre parametry w AD, które są dla tych obiektów bardzo różne, jednak albo nie są tu potrzebne albo można przeżyć jeśli będzie zwrócony null. a zatem można utworzyć pojedyncze zapytanie i wykorzystać je kilka razy.

samo query można by zrobić przy pomocy uniwersalnego get-ADObject… jednak z jakiegoś powodu nie przyjmowało wybranych atrybutów [$properties]. zamiast debugować zastosowane zostało obejście problemu. polecenie jest złożone jako string a następnie wywołane. funkcja przyjmuje trzy parametry, m.in. $type. czyli wykonanie „get-ad$type” rozwiązuje problem. aby wykonać ciąg jako polecenie należy skorzystać z ‚invoke-Expression’.
get-ad* zwraca kolekcję obiektów. każdy taki obiekt będzie obrobiony przy pomocy funkcji ‚prepareADObject’ przedstawionej za chwilę i wrzucony do tablicy $resultList. taki sposób ma dwie zalety – przenosi obróbkę obiektu do oddzielnego bloq, dzięki czemu w przyszłości łatwo będzie coś sobie zmodyfikować, natomiast listę na koniec łatwo będzie wyeksportować… albo jeśli zajdzie potrzeba – zastosować dodatkowe filtry. co się zresztą za chwilę dzieje.

jeśli zmusiliśmy skrypt przełącznikiem ‚$toScreen’ do tego, aby od razu wypisać na ekran zamiast do pliq, to w tym momencie zostanie wypluta na standardowe wyjście lista. na tej liście, co będzie widoczne po obejrzeniu funkcji ‚prepareADObject’, są obiekty. jest to istotne ze względu na, nomen omen, istotę całego PowerShell. jego potęga tkwi w tym, że [niemal] wszystko co wypluwa i przyjmuje jest obiektem. dzięki temu można tworzyć wielkie rurociągi aka oneliners – przekazując obiekty do obróbki do następnego polecenia|do obróbki do następnego|do obróbki… | aż na zdefiniowane wyjście. dla tego dobrą manierą pisania skryptów, jest definiowanie i wypluwanie obiektów, dzięki czemu wyjście naszych własnych skryptów również może być dalej obrabiane standardowymi narzędziami:

kolejną rzeczą jest plik wyjściowy. od wieków ‚comma delimited’ jest przez Excel rozumiany jako ‚semicolon delimited’, więc aby plik wyjściowy był automatycznie raportem Excel, wystarczy wypluć go jako csv oddzielany średnikiem:

można bawić się oczywiście w obiekty COM i bezpośrednie tworzenie xlsx … ale po co? formatowanie tabeli w Excelu robi się w 3 sekundy. największym problemem byłoby to, że taki obiekt musi istnieć w systemie, w którym uruchamia się skrypt – a na serwerach instalacja Excel… słabe wymaganie, do uruchomienia małego skryptu. csv zamyka temat tworzenia raportu.

dalej widać zaletę utworzenia własnej listy, co było wspominane. ponieważ jest przetrzymywana w zmiennej można ją kilqkrotnie wykorzystać. jeśli raport ma być rozbity na kilka pliqw – proszę bardzo. kilka linijek kodu i zostanie przefiltrowany – zrobienie dodatkowych zapytań do AD byłoby dużo wolniejsze.

ostatnią rzeczą na jaką warto zwrócić uwagę jest specyficzne wykorzystanie zmiennej – $script:usedFiles. sama zmienna posłuży do qlturalnego wyświetlenia na koniec wszystkich wyplutych  pliqw. wykorzystanie słowa kluczowego ‚$script:’ zmusza/informuje interpreter, że zmiany mają być zapisywane w zmiennej globalnej dla skryptu – jak zajrzycie do poprzedniego odcinka zobaczycie, że gdzieś tam, na początq była deklaracja $usedFiles=”” . przy pewnych zagnieżdżeniach, w szczególności przy rekursywnych wywołaniach, kontext zmiennej jest gubiony więc trzeba go usztywnić.
można również odwołać się do zmiennej globalnej dla środowiska [czyli z poza skryptu] poprzez wykorzystanie ‚$global:’

teraz chwilę o własnych obiektach. jest to istną tajemnicą, czemu w języq tak silnie obiektowym, nie ma klas. są dwie protezy – jednej nie będę opisywał, ponieważ umrze wraz PS5.o, a najczęściej stosuje się po prostu tworzenie obiektu bez klasy. potwornie niewygodne i mało intuicyjne… ale cóż. jak się nie ma co się lubi to:

 

skoro get-ad<typ> wypluwa obiekty, to czemu męczę się ze zrobieniem własnego obiektu, zamiast zastosować select albo inny natywny dla języka sposób? odp: ponieważ daje to potężne narzędzie obróbki – ot choćby zmianę daty na zrozumiałą przez istotę gatunq homo sapiens. mogę też dodawać własne atrybuty, których nie ma w oryginale – np. ‚skip’. ten atrybut jest istotny dla raportu oraz wszelakiego filtrowania. w założeniach skryptu była informacja, aby obiekty ze zdefiniowanych OU były wyszukiwane, ale oznaczone. w pierwotnej wersji dostawiana była na początq linii ‚*’ [fujć!]. dzięki dodaniu kolumny ‚skip’ można po otwarciu pliq w excelu bardzo łatwo zrobić filtrowanie… a nie jakieś tam gwiazdki i operacje na stringach… tu się, psze państwa, pracuje na obiektach q:

samo ustawienie atrybutu skip na $true jest lekko zagmatwane… pozostawię sobie pełne tłumaczenie na następny, ostatni wpis cyklu, gdzie postaram się dokładnie wyjaśnić to wyrażenie regularne i jak powstało.

w poprzedniej części była deklaracja zmiennych i komentarze, w tej – funkcje wspierające. pozostało opisanie ‚ciała’ skryptu. jak sądzicie – jak dużo będzie tego ciała? (;

eN.

 

PowerShell – nauka na błędach cz.II

Windows_PowerShell_iconna początek zaprezentuję… początek. całkiem logicznie q:

find-UnusedADObjects.ps1

po pierwsze nazwa skryptu z przyjętą w PS notacją. korzyść – bardziej intuicyjne wykorzystanie.

po drugie bardziej rozbudowane komentarze. odpowiednio zrobione są bardzo wygodne – korzystając z polecenia get-help wyświetli się pełny opis. każda wersja PS wprowadza coraz więcej obsługiwanych słów kluczowych, a żeby dowiedzieć się o całości należy poszukać ‚comment based help‚. niektórzy mogą powiedzieć – ‚eeee, jestem zbyt leniwy na takie szlaczki’.  zatem zwróćcie uwagę na to, jak opisany jest parametr ‚scope’ a jak ‚splitFiles’:

  • ‚scope’ jest wyniesiony na początek , do ‚comment based help’
  • ‚splitFiles’ jest opisany ‚na lenia’ jako komentarze tuż pod opcją

obie wersje są obsługiwane przez get-help, więc jak się okazuje – nawet nie trzeba rysować szlaczków. wystarczy minimum wysiłq aby na szybko opisać po co jest dany parametr – z korzyścią dla twórcy jak i dla end-usera.

jest jeszcze jedna metoda tworzenia komentarzy, ale wydaje mi się, że to jeden z pomysłów, który się nie przyjął i został porzucony. jego zastosowanie jest, delikatnie mówiąc, niszowe:

wiadomość można zobaczyć na dwa sposoby – badając kod źródłowy skryptu, lub:

jeśli wartość zdefiniowana jest jako obligatoryjna ORAZ nie wprowadzimy jej ORAZ po wyświetleniu komunikatu wpiszemy ‚!?’ [SIC!]:

wygląda na to, że ktoś miał pomysł… tylko inni go nie podzielili (;

„#Required -version 3” zapewnia kompatybilność. nie bawiłem się w ładowanie modułów bo zakładam, że zostaną załadowane automatycznie [od ver. PS3.o] oraz wykorzystane jest kilka technik zapisu, które nie jestem pewien czy zadziałają w PS2.o. to zabezpieczy przed przypadkowym odpaleniem na starej wersji.

następnie parametry. nie tylko są, ale są zdefiniowane w bardziej rozbudowany sposób – część z nich ma określone ograniczenia poprzez validateSet i validateRange. to kolejna rzecz, która nie służy wyłącznie dla zaspokojenia puryzmu i widzi-mi-się. jedną z najwygodniejszych cech PS jest dokończanie TABem. jeśli zdefiniowany jest validateSet, to szybko można całe polecenie wpisać: „find-u<TAB dokończy nazwę skryptu> –s<TAB dokończy nazwę parametru> <TAB będzie przerzucał pomiędzy zdefiniowanymi wartościami>”. takie niuanse są prawdziwą SiłąPowłoki (;

inną ciekawostką jest zdefiniowane zmiennej, której standardowa deklaracja jest kawałkiem kodu:

zacznę od tego, że jestem przeciwnikiem takiego pisania – braqje tu obsługi błędów. ale w całym skrypcie darowałem sobie obsługę błędów – zupełnie nieedukacyjnie… ale to na inny wpis, kiedyś. drugi błąd popełniony w tej linijce to wykorzystanie aliasu ‚gc’. aliasy mogą być globalnie przedefiniowane więc dla pewności w skryptach powinno się ładnie używać pełnych, prawidłowych nazw commandletów. trzecią ‚głupią’ rzeczą, której w praktyce nie robię i jest tutaj bardziej do celów edukacyjnych, jest wyniesienie zmiennych do oddzielnego pliq.

find-UnusedADObjects.OUsToSkip

w starej wersji pliq było wewnątrz: $OUsToSkip=”Servers”,”_UnusedObjects”,”Service Accounts”  . kiedy należy wynieść wartości do zewnętrznego pliq? kiedy skrypt będzie zaszyfrowany lub podpisany certyfikatem. czyli nie będzie można w nim dokonać żadnej modyfikacji. należy wtedy jednak dobrze opisać w helpie jak taki plik ma się nazywać, co ma zawierać itd. sporo problemu. a ponieważ zazwyczaj celowo oddaję źródła, zależy mi na ‚kompaktowości’ rozwiązania – potęga skryptów to często fakt,  że jest to *pojedynczy*, mały plik.  niemniej warto wiedzieć, że tak również można zrobić, i to w całkiem prosty sposób.
oczywiście oprócz pliq można po prostu podać tablicę stringów jako parametr… ale niezbyt to wygodne w codziennym użyciu.

kolejne drobiazgi w deklaracjach to np. fakt, że pliki będą się odkładać a nie nadpisywać, ponieważ zawierają datę w nazwie.

dalej widać regex który omówię w późniejszych częściach, deklaracje filtrów wyszukiwania, $searchProperties – które, jak się finalnie okaże, wyniesione w tym miejscu pozwoli w bardzo łatwy i szybki sposób poszerzyć funkcjonalność, jeśli klient nagle zażyczy sobie w raporcie dodatkowych danych.

i to na tyle w tej części. niby tylko ‚komentarze i deklaracja zmiennych’ a okazuje się, że już w tej fazie, jest wiele istotnych detali na które należy zwrócić uwagę aby skrypt był wygodny w użyciu i przejrzysty.

eN.

 

PowerShell – nauka na błędach cz.I.

Windows_PowerShell_iconmoje skrypty gdzieś tam sobie żyją u różnych klientów. dostałem ostatnio prośbę, aby coś tam w jednym takim skrypcie zmienić. otworzyłem, popatrzyłem.. popłakałem się i napisałem go od nowa.

skrypt był z 2o11 – kiedy uczyłem się PS. na pierwszy rzut oka można stwierdzić, że jest napisany przez kogoś, kto pisał w VBSie i właśnie zaczyna się uczyć się składni PS i daleko jeszcze do Zrozumienia tego języka. skrypt działał i był regularnie wykorzystywany przez kilka lat – ok. pod tym względem ok. ale to, w jaki sposób jest napisany… po prostu musiałem napisać go od nowa.

przypatrzmy się temu… temu.. tej atrapie skryptu. tak na prawdę to trzem skryptom, stanowiącym mechanizm pozwalający robić regularny przegląd AD – nieużywane konta użytkowników, komputerów oraz konta z niewygasającymi hasłami. całość ma pozwolić na:

  • znalezienie nieużywanych obiektów
  • możliwość przejrzenia ich tak, aby admin mógł ręcznie odfiltrować co jest potrzebne a co nie
  • przygotowanie danych do raportu (to właśnie był nowy request po którym postanowiłem napisać całość od nowa)
  • łatwe zablokowanie takich obiektów.

zacznę od tego, co było zrobione dobrze. pewne nawyki można wynieść nawet z VBSa q:

  • skrypt jest *w miarę* uniwersalny. i faktycznie wiem, że był/jest wykorzystywany u co najmniej 3 klientów bez większych przeróbek [przynajmniej kiedy go oddawałem]
  • kod jest opisany
  • są informacje o wersjach – wbrew pozorom wielokrotnie był to istotny niuans pozwalający szybko ustalić której wersji ktoś używa, a więc co może nie działać.

w dużym skrócie – ponieważ skrypty piszę od bardzo dawna, trochę dobrych nawyków widać. jednak tu, gdzie zaczyna się znajomość języka… jakie zatem widać wady:

  • skrypt może i jest *w miarę* uniwersalny, ale to mało. zmienne powinny być wyrzucone do parametrów [których wtedy nie umiałem jeszcze używać] tak, aby nie trzeba modyfikować samego kodu.
  • już sama nazwa pliq nie jest zgodna z przyjętą przez PS notacją czasownik-rzeczownik
  • wyjściem jest plik textowy… niby ładny, bo jakieś komentarze… ale nauczyłem się, że dobry plik, to uniwersalny plik. czyli taki, który można otworzyć np. w excelu i dowolnie go obrobić. dzięki temu format staje się przenośny i pozwala wykorzystywać różne wbudowane w język mechanizmy, zamiast kombinować z pisaniem własnej ‚obsługi’. np. jest zmienna, definiująca OU, które mają być wyszukane, ale pominięte przy późniejszym blokowaniu. wymyśliłem więc, że będę umieszczał asteriska ‚*’ na początq linii. fujć! jakie to… VBSowe.
  • pliki wyjściowe mają zawsze tą nazwę. to oznacza, że wejściowe dla skryptu, który będzie je obrabiał, również ma ‚zahardcodowane’ nazwy. brzydka maniera, z różnych powodów [np. brak historii].
  • wykorzystywanie mechanizmów o statusie ‚obsolete’ – ADSI to stary interfejs COM… [na usprawiedliwienie mogę powiedzieć, że wtedy nie było jeszcze tak rozbudowanego modułu ActiveDirectory i wszyscy używali commandletów questa. nie jestem pewien czy pierwsze commandlety AD nie wykorzystywały ADSI?]
  • duża ilość powtórzonego kodu – zarówno dla obiektu typu user jak computer jest praktycznie ten sam kod.
  • nie są wykorzystywane dobrodziejstwa języka. kod jest mówiąc oględnie – prymitywny.

widać, że jakieś tam drobne zmiany były wprowadzane – w końcu najważniejsze jest, że działa. jednak przychodzi moment, w którym pojawia się nowe żądanie zmiany i przerobienie kodu nagle staje się zbyt pracochłonne albo po prostu niewygodne. tak też zrobiłem wiosenne porządki i napisałem skrypt od nowa…

w kolejnych częściach będę prezentował po kawałq nową wersję komentując zastosowane techniki.

eN.

 

Powershell i dyski maszyn wirtualnych w klastrze – kontynuacja

druga część o raportowaniu dysków na Technet

eN.

Co teraz?

Czasami zapominam, że gdzieś tam w szklanych biurowcach siedzi armia ludzi, która analizuje wszystko i wszystkich, potem wychodzą takie schematy.
Warto zerknąć.

HC_ET_2014.jpg;pv4cc7877f7de80268

Pełen artykuł tutaj:
http://www.gartner.com/newsroom/id/2819918

kopiowanie plików na VM

nie qmam polityki eMeSa, który zdając sobie sprawę z wagi wirtualizacji, ubił środowiska wirtualizacyjne na stacjach roboczych. Hv na lapq ma wiele wad, ale jedna z nich została usunięta. w końcu można kopiować pliki bezpośrednio na maszynę… szkoda, że nie w drugą stronę, ale od czegoś trzeba zacząć q:

pełny opis zamieściłem tutaj.

eN.