Skip to Content

IT nieuczesane.

ruszamy! ITechDay i WGUiSW

koniec sezonu ogórkowego, czas wrócić do nauki!

już jutro 112 WGUiSW – i wracamy do Microsoft, po remoncie siedziby. jak zwykle ciekawi ludzie i tematy – tym razem o Citrix i konfiguracji Windows 1o.

jednak większy ‚news’ dotyczy ITechDay 2o19. tym razem po prostu zacytuję:

*************

Warszawska Grupa Użytkowników i Specjalistów Windows (WGUiSW) wraz z Partnerami gorąco zapraszają na kolejną konferencję z cyklu ITechDay.

Tematami wiodącymi będą:

  • rozwiązania chmury publicznej i prywatnej,
  • aspekty gromadzenia i bezpiecznego przechowywania danych,
  • zapewnienie wysokiej dostępności,
  • automatyzacja zadań w środowiskach IT,
  • analiza i ocena zabezpieczeń infrastruktury IT.

Sesje będą odbywały się równolegle na czterech ścieżkach technicznych i poprowadzą je znani prelegenci posiadający bardzo bogate doświadczenie praktyczne poparte wieloma certyfikatami zawodowym.

Patronat honorowy nad wydarzeniem objęło Ministerstwo Obrony Narodowej a Partnerami strategicznymi konferencji są Aruba Cloud, CBSG Polska, CodeTwo, Dell, Eversys, HP Enterprise, GreyCortex, IT Solution Factor, Kingston, Microsoft, Mine Master, MWT Solutions, Narodowe Centrum Bezpieczeństwa Cyberprzestrzeni, QNAP, Palo Alto Networks, Tech Data, Veeam.

Konferencja odbędzie się 17 września 2019r. w siedzibie Wyższej Szkoły Menedżerskiej na warszawskiej Pradze. Udział w konferencji ITechDay będzie bezpłatny.

Informacje o ITechDay dostępne są na stronie internetowej www.ITechDay.pl a aktualności można śledzić na tablicy www.facebook.com/ITechDay.

***********

od siebie dodam, że będę miał zaszczyt prezentować podczas ITD – i to wraz z Pawłem Pławiakiem! ciekawy eksperyment, ponieważ takie sesje we dwóch raczej robi się rzadko i ich przygotowanie jest trudniejsze. jak wyszło – mam nadzieję, ocenicie sami.

eN.

OneLiner vs Script, stopki i gorączka

OneLiner nie jest skryptem

pasqdny dzień. migrena, potem gorączka, a jak mam gorączkę to muszę coś napisać. czasem głupoty, ale dziś może coś sensownego. i pisząc skrypt wstrzyqjący stopki dla OWA i mobile w EXO dla paru tysięcy userów, pomyślałem o tym czemu z OneLinera zrobiło się ponad 4oo linii kodu w dwóch skryptach. nie wszyscy to rozumieją, a jeśli ktoś skrypty pisać musi, lub lubi, to powinien to bardzo dobrze (z)rozumieć. dla tego wpis, poświęcony klepaczom kodu, którzy chcą robić to lepiej.

pisanie skryptów to praca dość niewdzięczna i mało opłacalna. kiedyś sądziłem, że jak powymiatam w pisaniu PS to będę mógł na tym sensownie zarobić. fakty są takie, że za skrypty rzadko ktoś chce płacić. „bo przecież to jedno polecenie”, albo że tego się nie da używać. no i w sumie… muszę się zgodzić. skrypty na zlecenie zdarzają się, ale rzadko.

w zasadzie robię już trochę inne rzeczy, ale czasem wspieram 2gą i 3cią linię. PowerShell to moje hobby, ale w pracy oczywiście czasem się przydaje. skrypty rzadko bo:

  • 1sza linia wsparcia boi się literek. jak coś nie ma GUI, to jest nie-do-użycia. nie ma znaczenia czy jest dokumentacja, i czy to w ogóle robi coś skomplikowanego, ale klawiatura dla pierwszej linii służy do logowania. też pewnie już niedługo, bo będą się logować biometrią a w dużej mierze zostaną zastąpieni chatbotami. a więc pisanie automatyzacji w postaci skryptu dla nich – nie ma sensu.
  • 2ga linia wsparcia owszem, uruchomi skrypt. ale jeśli coś się wysypie, pokaże się jakiś błąd… koniec. skrypt do śmieci, strach, nie chcemy. oczywiście tutaj jest już sporo wyjątqw, osób które po prostu *potrzebują* automatyzacji, więc się uczą. a czasem nawet lubią.
  • 3cia linia wsparcia… jest nieliczna i dość samowystarczalna. ale zazwyczaj wolą zassać jakiś skrypt z netu a potem szukać 1oo łorkeraundów jak go użyć do swoich potrzeb, niż coś napisać. ludzie wiedzą jak ‚coś osiągnąć’ – ale napisanie skryptu to inna para kaloszy.

to oczywiście subiektywna ocena, na podstawie doświadczeń własnych. wniosek jednak nasuwa się prosty – chcesz zarobić na kodowaniu, to weź się za coś, co ma interfejs, bo linia poleceń nadal straszy. jest dla nerdów, geeków i popraprańców. ewentualnie – ostatnia deska ratunq.

OneLiner nie jest skryptem. jest… łanlajnerem. nie będę wchodził w filozoficzno-semantyczne dywagacje i definicje – dla mnie nie jest to skrypt. zastosowanie onelinera jest wtedy, kiedy robi się coś bieżącego, trzeba zrobić raz i na szybko, i samemu kontroluje się przebieg. zazwyczaj to tylko jeden w wielu kroqw w długiej pracy. skrypt dla odmiany – to coś co pisze się, żeby było. żeby zostało i żeby można było tego użyć wiele razy i wielu warunkach… a co najważniejsze – żeby użyć tego mogli inni.

taka jest moja definicja.

to samo inaczej

dostałem skrypt mailem – nawet nie oneliner, miał ponad 1oo linii kodu. i prośba „weź tu tylko braqje takiego dyngsa i już. easypeasy… aaa i to ma być uruchamiane przez adminów potem”. oj. czyli celem nie jest to, co robi skrypt, tylko automatyzacja powtarzalnego zadania, przez osoby z 2giej linii. to zmienia wszystko.

zajrzałem do środka – jak na robotę admina, spoko. co prawda z ‚dyngsem’ by sobie nie poradził i zrobił zapętloną enumerację – czyli wydłużył przebieg do kwadratu, co przy tysiącach elementów i przebiegu w okolicy 3-4h, nagle zrobiłoby się 3-4 dni (; … ale widać, że ogólnie ogarnia. a jak zatem powinien wyglądać skrypt ‚dla kogoś’, dla 2giej linii? kilka wskazówek:

  • włącz cmdletbinding – proste, a daje dodatkowe możliwości np. tryb verbose i pełną obsługę parametrów.
  • zrób dobre opisy! wykorzystaj to, co daje PS i dobrze udoqmentuj skrypt. przyda się zarówno innym jak i Tobie
  • nie nadawaj nazw zmiennych typu ‚$a’ czy ‚$tmp’ – każdy normalny edytor ma intellisense, więc nie bój się wpisać ‚$tymczasowyImportDanych’ – przecież edytor to sam dokończy, a kod staje się czytelniejszy
  • jeśli niezbędny jest import danych – musisz założyć, że ktoś zamiast pliq tekstowego spróbuje załadować obrazek, że csv będzie miał złe kolumny albo że ktoś w ogóle go ominie. weryfikacja danych jest jednym z najpracochłonniejszych elementów – a ludzie są leniwi. dobra weryfikacja danych wejściowych to mniej błędów
  • OBSŁUGA BŁĘDÓW. to jedna z najtrudniejszych rzeczy – nie tylko przy skryptach. ale w przypadq skryptów, istnieje przesąd, że obsługa błędów jest niepotrzebna albo że w ogóle jej nie ma. jeśli oddajesz skrypt komuś, to niemal każda operacja powinna być otoczona try/catch lub weryfikacją zmiennej wyjściowej działania. inaczej skrypt będzie się sypał i nikt nie będzie widział czemu, albo nawet, że się sypie. to powoduje, że kod puchnie niebotycznie bo zamiast jednej, prostej linijki nagle robi się dziesięć, ale bez tego będzie scenariusz: nie zadziałało, nie wiem, boję się, kasuję.

oczywiście takich przykazań można by mnożyć i wypisywać przez pół nocy, ale wybrałem te, których zazwyczaj nie znajduję nawet w skryptach zassanych z technet/codeplex/github czy innych repo – teoretycznie stworzonych do konsumpcji przez innych. tak jak zasadą House MD dla wsparcia jest ‚użytkownik zawsze kłamie’, tak dla skypciarzy (a w zasadzie i w ogóle ogólnie) jest ‚ludzie są leniwi’. robią minimum. chcesz napisać skrypt dobrze – napisz tak, jak byś sam chciał go użyć, pierwszy raz go widząc, nie bądź leniwy.

przykładowy szkielet skryptu, który może posłużyć jako szablon:

nie ma tu żadnego try/catch… ale jest przykład jak obsłużyć dane wejściowe i nie oszczędzać na opisach i nazwach parametrów.

jedni biegają albo chodzą na imprezy, ja sobie skrobię skrypty (; a jeśli chcesz programować zawodowo – to raczej sięgnij po VS i zacznij ogarniać jakieś .NETy, pytongi czy inne duże frameworki.

gorączka spadła, czas usnąć. miłego kodowania!

eN.

PS. contains nie jest tym, czym się wydaje.

Migracja w hybrydzie – zakończenie pojedynczej skrzynki w zadaniu synchronizacji

ciekawostka, bo wszyscy piszą, że się nie da… a się da.

jeśli założy się zadanie migracyjne Ex-EXO w którym jest wiele kont, to można potem usunąć pojedynczą skrzynkę użytkownika, ale nie bardzo jest sposób na to, żeby tylko jedną skończyć. jeśli jednak się przyjrzeć w jaki sposób działa parametr ‚AutoComplete’ dla wsadu migracji, sprawa okazuje się oczywista.

korzystając z PowerShell, jeśli chcemy zsynchronizować skrzynki ale ręcznie ustalić kiedy mają się przełączyć wygląda to np tak:

gdzie opisywanym parametrem jest oczywiście ‚AutoComplete’. ale kiedy podejrzy się potem takie zadanie – gdzie to sobie siedzi? jeśli posłużymy się get-migrationUser żeby to znaleźć – nie bardzo się uda. parametr jest dziedziczony z całego wsadu, stąd może wydawać się niemożliwe ukończenie pojedynczej skrzynki. jeśli jednak wyświetli się i sprawdzi w jaki sposób jest to de facto zrealizowane, to rozwiązanie nasuwa się samo. tak na prawdę dla całego zadania ustawiany jest atrybut ‚completeAfter’ na jakąś chorą datę – w tym przypadq wyjątkowo szybko:

wyjątkowo szybko, bo zazwyczaj widzę 31.12.9999 . z jakiegoś powodu tym razem czas został kapkę skrócony, ale i tak jestem zbyt niecierpliwy, żeby czekać tyle czasu (;

…a zatem aby skończyć pojedynczą synchronizację wystarczy ustawić jej czas ‚completeAfter’ na obecny. korzystam z jednej z dwóch metod:

lub

ustawiając datę z przeszłości – jeśli chcę mieć 1oo%, że to nie chodzi o UTC. nie porównywałem czy efekt jest identyczny. przez jakiś czas nic się nie dzieje (statystyki nie pokazują statusu jako ‚completing’), ale po ok 1h skrzynka jest ‚completed’.

eN.

Uruchamianie usług chmurowych w hybrydzie

Usługi czyli EXO (Exchange Online) i SOL (Skype for Business Online). Problem w hybrydzie polega na tym, że nie można skorzystać z interfejsu portal.office.com – należy konta założyć w środowisq onprem. i oczywiście prostą odpowiedzią byłoby skierowanie do commandletów Exchange i SfB w onprem… ale po co wtedy byłby wpis?

Scenariusz

zakładamy konto użytkownika i chcemy aby od razu miał skrzynkę w EXO i uruchomione usługi SOL. można założyć całość w onprem a potem migrować… ale to straszna strata czasu i wysiłq.

Standardowo

niemniej zacznę od standardowej metody, ponieważ tak to się robi oficjalnie.

po założeniu konta w AD, należy wykonać enable-RemoteMailbox – opis polecenia oraz doqmentacja do hybrydy. następnie trzeba włączyć konto SOL poleceniem enable-CSUser, a sztuczka polega na dodaniu parametru  „-HostingProviderProxyFqdn sipfed.online.lync.com”.

problem z tym rozwiązaniem jest taki, że żeby założyć konto potrzebne są aż trzy różne moduły: Active Directory, Exchange oraz Skype for Business. Prawidłowo administracja powinna być tak zorganizowana, że administratorzy logują się na stację zarządzającą, gdzie mają wszystkie narzędzia zainstalowane – w szczególności te wymienione. i oczywiście sugerowałbym aby tak to się odbywało. jednak… życie pisze własne scenariusze, np. taki, że jest sobie system HR, z którego wypływają dane o użytkownikach. i jak developer ma sobie z tym poradzić? do LDAP dość łatwo się dostać i są do tego standardowe biblioteki w samym frameworq, a do Ex czy SfB już tak różowo nie jest.

HACKED

….podam sposób, jak można założyć mailbox i włączyć SIP, wyłącznie przy pomocy modułu Active Directory/dostępu do LDAP. zaletą takiego rozwiązania jest brak konieczności instalacji pozostałych – i to właśnie był czynnik, który zmusił mnie do zrobienia takiego rozwiązania. zacznę od przestrogi:

zaprezentowane rozwiązanie nie jest wspierane, a konsekwencje użycia mogą być ciężkie do przewidzenia – dla tego przetestuj dokładnie, upewnij się, że rozumiesz co robisz i jak to działa tak, aby w razie co być w stanie naprawić. pełne commandlety wykorzystują mechanizmy sprawdzające poprawność ustawianych wartości, czy nie występują duplikaty w domenie, i wiele innych, których tutaj nie ma – a więc można namieszać. korzystasz na własną odpowiedzialność.

no to jak już się przestraszył[ae]ś, to teraz rozwiązanie.

w zasadzie najważniejszym trikiem jest zrozumienie jak działa hybryda – wszystkie zmiany wprowadzane są w onprem i synchronizowane do chmury. czyli wskazane polecenia – enable-RemoteMailbox czy enable-CSUser – wbrew temu co możesz sądzić, w żaden sposób nie łączą się z Office365. jedyne co robią, to modyfiqją wartości atrybutów w AD. w związq z tym można napisać skrypt, który dokładnie to zrobi.

nie będę zamieszczał całego skryptu – są w nim elementy specyficzne dla konkretnego klienta – ale wszystko co niezbędne znajdziesz poniżej.

Exchange

atrybuty, które należy zmodyfikować mogą się różnić, zależnie od klienta – wiadomo, różne firmy mają różne wymagania. poniżej zestaw atrybutów ‚podstawowych’:

to, co widać powyżej, to oczywiście zestaw atrybutów obiektu User w AD, niezbędnych do założenia skrzynki.

  • mail: $oUser to obiekt użytkownika, pobrany wcześniej jako „$oUser=get-aduser <name> -properties *”. tutaj założenie jest, że podstawowy email jest taki sam jak UPN
  • mailNickname: standardowo jest taki sam jak SAM
  • msExchPoliciesExcluded: jeśli chcę ustawiać adresy email ręcznie to wskazana polisa (GUID taki sam dla każdego Ex) jest odpowiednikiem odznaczenia ‚Automatically update email addresses…’ . jeśli adresy będą się wypełniały standardowymi polisami, to można pominąć
  • msExchangeRecipient*: wskazują na typ skrzynki. szczegóły tutaj. ogólnie – wskazuje, że skrzynka typu RemoteUserMailbox ma być założona
  • msExchUMDtmfMap: będzie za chwilę wypełnione – funkcja poniżej. de facto chodzi o konwersję na cyferki z cyferblatu telefonu, fragment UC.
  • msExchVersion: jest zawsze taka sama, i pochodzi z onpremowego Exchange. można sobie zweryfikować z jakimś lokalnym kontem
  • proxyAddresses: to oczywiście aliasy. jeśli ustawiamy inne niż podstawowy, warto nie zapomnieć wyłączyć polisy msExchPoliciesExcluded…
  • showInAddressBook: to CN list adresowych, w których ma się pojawić. tutaj standardowa lista globalna. ten CN można odczytać z innego użytkownika.
  • targetAddress: bardzo ważne pole, wskazujące na przekierowanie do chmury. na jego podstawie robiony jest routing do chmury na connectorze.

zmienna jest typu hashtable, można więc sobie powyliczać np. proxyaddresses, poustawiać co potrzeba. np. DTMF. funkcja, która konwertuje ciągi do DTMF:

i fragment kodu, który ustawia DTMF:

zmienna jest tablicą zawierającą zazwyczaj trzy elementy w zapisie DTMF – adres email [a w zasadzie nazwa użytkownika – bez domeny], nazwa użytkownika ‚lastNameFirstName’ oraz ‚firstNameLastName’. a więc wyliczam przy pomocy funkcji konwertującej i paqję do zmiennej $EXOattributes.

kiedy $EXOAttributes zawiera wszystko to, co potrzebne, pozostaje pchnięcie tego do AD. i tutaj piękno i prostota PS:

i już. atrybuty są wypełniane, zsynchronizuje się do o365, a ten podejmie odpowiednie działania – czyli założy skrzynkę.

SOL

całość wykonuje się analogicznie – buduję hashtable, który potem pchnę do AD, a poniżej niezbędne atrybuty dla Skype for Business Online:

te zbudowane są dla środowiska sfederowanego, gdzie po stronie OnPrem stoi Lync 2o13. to może mieć znaczenie dla atrybutu msRTCSIP-PrimaryHomeServer – ponieważ nie wiem czy tak samo wygląda CN usługi SfB.

dla ‚OptionFlags’ link z wyjaśnieniem wartości można znaleźć tutaj.

zakończenie

jak wspomniałem, nie publiqję całego skryptu, ponieważ logika wyliczania czy to proxyaddresses czy innych elementów jest dla konkretnego środowiska i każdy musi sam to oprogramować. celem wpisu jest tak na prawdę pokazanie na czym polega ‚od spodu’ założenie konta w EXO czy SOL w środowisq hybrydowym. niby każdy wie, że zmiany synchronizują się w jedną stronę, a jednak podczas rozmów, okazuje się, że wszyscy spodziewają się jakiejś dodatkowej komunikacji pomiędzy systemami. a tu nic takiego nie ma – jest tylko synchronizacja i tyle.

nie jest to zalecany sposób tworzenia… ale na pewno fajna zabawa (;

eN.

1o9. WGUiSW

już jutro, o2.o4, zapraszam na kolejne, 1o9 spotkanie WGUiSW . w tym miesiącu (i następnym) jeszcze nietypowo, bo zamiast tradycyjnie, w Microsoft, spotykamy się na uczelni WSIZiS na Newelskiej.

eN.

1o8 WGUiSW

…ostatnio obrodziło w spotkania. remont w Microsoft przesunął ostatnie, lutowe spotkanie, dodatkowo 7go jest ITD… nie mniej serdecznie zapraszam na 1o8 WGUiSW we wtorek, o5.o3. ten będzie nieco odmienny – bo poza MS – w Wyższej Szkole Informatyki Stosowanej i Zarządzania przy ulicy Newelskiej 6 (sala nr 2). domyślam się, że ze względu na natłok ostatnich spotkań i lokalizację będzie kameralnie.

na agendzie zamykająca, II cz. ‚wszystko co musisz wiedzieć o grupach Office365’, prowadzone przeze mnie, oraz ‚AZ CLI i kopie zapasowe’ prowadzone przez Aleksandrę Frączek.

eN.

SSPR vs contact info

ciekawy case dotyczący uruchamiania Self-Service Password Reset (SSPR) i zarazem lekcja – workaround to nie solution q:

zgłosił się do mnie zapłakany klient, że uruchamiają SSPR i muszą jakoś dostarczyć dane użytkowników do portalu. do niedawna nie było to możliwe (uservoice z 2o18), ale od jakiegoś czasu Microsoft w swojej wielkości dostarczył… no właśnie, co dostarczył? obejście problemu opisane tutaj. ‚czemu obejście?’ zapyta ktoś, kto uważnie przestudiuje, sprawdzi i stwierdzi że działa…

…ano problem polega na tym, że informacje do SSPR brane są z atrybuty ‚StrongAuthenticationUserDetails’. ten atrybut ma kilka cech odróżniających go od zwykłego atrybutu np. ‚telephoneNumber’ a jednym z nich jest fakt… że nie wypełnia wizytówki użytkownika. jest niewidzialny.

i teraz taki myk…

tak wygląda użytkownik, który wszedł na portal i wypełnił sobie dane do MFA/SSPR:

i wyświetlmy sobie właściwości w AAD:

a teraz, za artykułem, prepopuluję (dziś super po polsq) atrybuty:

no i output takiej operacji:

co się dzieje dalej? hasło dla testuser02 resetuję i działa. kiedy próbuję dostać się do portalu o365, dostaję standardowe pytanie o uzupełnienie obligatoryjnych pól do zabezpieczenia konta (czyli te do MFA, które zapisują się w StrongAuthenticationUserDetails).

a więc to …’rozwiązanie’ nie działa dla MFA, jest obejściem dla SSPR, i dane ‚zabezpieczające’ stają się *publicznie* dostępne dla wszystkich w organizacji ROTFLMAO.

eN.

ITechDay 2o19

już wkrótce, 7.o3.19, wyczekiwany ITechDay. organizator zgodził się na zwiększenie liczby uczestników do 8oo osób, w związq z czym dostępna jest dodatkowa pula wejściówek (:

polecam do zapoznania się z agendą i szybką decyzje, bo wejściówki zazwyczaj rozchodzą się w mgnieniu oka – niemal z dosłownością tego powiedzenia. zasługa oczywiście i doborowych prelegentów, organizacji, atmosfery i oczywiście faktu, że jest to impreza bezpłatna.

serdecznie zapraszam!

eN.

społecznie – WGUiSW i o365 User Group

już w najbliższy wtorek, 19.o2, 1o7 WGUiSW – na nim kontynuacja serii Marka dot. office 365, sesja Kamila o Microsoft Graph oraz Mariusza o tym, jak przenieść małą firmę do Azure. jak widać tematyka przenosi się do chmury…

a w następny wtorek, 26.o2, pierwsze (SIC! #1spotkanie grupy O365 User Group. grupę prowadzi wspomniany Kamil oraz Michał – znani ze świetnych konferencji ShareCon365. tematy ciekawe – Teams i PowerApps. trzymam kciuki (:

eN.

Oneliner wyświetlający administratorów AAD/o365

trochę zabawa żeby udowodnić co może PS, bo można łatwiej, ale na pewno w większej ilości kroqw.

scenariusz: wyświetlić wszystkich adminów i ich role w AAD. niby proste, mamy do dyspozycji get-AzureADDirectoryRole i get-AzureADDirectoryRoleMember. a więc we w miarę prostej postaci można to zrobić tak:

już tutaj zapytanie jest dość złożone. z ciekawych elementów, które warto wyjaśnić:

  • $rn=$_.displayname jest ściśle powiązane z faktem, żeby potem wykorzystać je w selekcie. bez tego utracona by została informacja dotycząca roli – a więc byłaby lista użytkowników, bez informacji o tym, o którą rolę chodzi.
  • ..i tak w selekcie następuje ‚wstrzyknięcie’ tej informacji poprzez @{N=’role’;E={$rn}} – utworzona zostaje dodatkowa kolumna o nazwie ‚role’.

niemniej to nie koniec ‚zabawy’ bo otrzymamy płaską listę, na której jeden login może występować wiele razy – dla każdej roli w której się pojawia. mamy oczywiście ‚group-object’ które pozwoli połączyć to w jedną całość… tylko co ukaże się naszym oczom nie będzie przyjemne.

problem, który się pojawia – jak sformatować to, co wypluwa ‚group-object’? w dużym skrócie – należy się przyjrzeć temu, co ten zwraca, i potraktować go… jak każdy inny obiekt. przyjmując, że wyniki poprzedniego polecenia mam w zmiennej ‚$admins’, przyjrzyjmy się co będzie po zgrupowaniu:

a więc ‚grupa’, trzyma dla każdego wpisu, wszystkie informacje o zgrupowanych obiektach (jako kolekcja obiektów) – ze względu na to zagnieżdżenie, nie jest to zbyt proste do pracy. do tego trzeba będzie pracować na kolekcji – bo jeśli ktoś występuje w kilq rolach, to mamy liczbę mnogą. finalnie odpowiedź jest taka:

można teraz całość wypluć do CSV [ |export-csv c:\temp\admins.csv -nti -deli ‚;’ ] i zrobić raport w Excelu (:

eN.