Skip to Content

IT nieuczesane.
category

Category: tips’n’tricks

Praca po nocy

Dziś wpis o niskim współczynniku zawartości power shella i twardej administracji, ale mam nadzieje, że nie mniej pomocny.
Po nocy przed monitorem siedzi każdy z nas, może nie z taką częstotliwością jak na studiach #goodoldtimes, ale przynajmniej okna serwisowe wypadają gdy słońce już dawno zaszło. Kiedyś, pisząc kolejne projekty na zaliczenie zwracałem uwagę na zbyt jasne oświetlenie monitora, szczególnie tła kartki w Wordzie. W nowych Windowsach, (tak gdzieś od 7) nie mogłem znaleźć tego ustawienia, a tu z pomocą przychodzi dedykowany program F.lux.
https://justgetflux.com/
Narzędzie automatycznie dostosowuje temperaturę kolorów monitora po zachodzie słońca. Sprawdziłem wczoraj w nocy – działa perfekcyjnie. Małe, proste, łatwo w razie czego wyłączyć na chwilę.
Polecam.

Dodatkowo jak już siedzimy po nocy, można zajrzeć na stronę o zdrowym śnie, sygnowaną przez Uniwersytet Harwarda: http://healthysleep.med.harvard.edu/portal/.

zmiana hasła użytkownika w kontexcie innego użytkownika

repairprzykładowy scenariusz:

dostęp do sieci klienta via VPN. nie ma możliwości zmiany hasła podczas połączenia VPN, ponieważ to niekoszerne rozwiązanie. hasło wygasło. inny pracownik ma swoje konto nadal aktywne – czy da się zmienić szybko hasło, zamiast czekać aż helpdesk przetrawi ticket?

dostępne opcje(, które raczej nie zadziałają):

  • połączyć się RDP do DC. w przeciwieństwie do połączenia do member servera, podczas połączenia do DC jest możliwość zmiany wygasłego hasła. warunek jest taki, że trzeba mieć uprawnienia do logowania na DC, czyli zazwyczaj – być Domain Adminem.
  • w starym wpisie na stronach Technet znajdujemy opis, że można zmienić hasło przy pomocy ‚net user * /domain’. jest to niekompetencja osoby piszącej KB, ponieważ nie odróżnia ona ‚reset password’ od ‚change password’. przy pomocy net user można hasło wyłącznie zresetować, co wiąże się z posiadaniem odpowiednich uprawnień do konta, na którym wykonuje się operację. dalszy opis w tym KB jest również bzdurą, ponieważ uprawnienia domain admina nie są wymagane – można to skonfigurować nawet dla pojedynczych kont.

rozwiązanie

jest oczywiście sposób skuteczny, działający i niewymagający żadnych specjalnych uprawnień. i oczywiście przy pomocy PowerShell, a konkretnie commandleta Set-ADAccountPassword:

sprawdzałem dla PS 2.o i wystarczy.

eN.

default output

Windows_PowerShell_icondefault output

po napisaniu skryptu dobrze jest móc z niego korzystać zarówno z konsoli jak dodać go do np. do schedulera. w końcu to automatyzacja. taka uniwersalność wiąże się z odpowiednim oprogramowaniem tego, gdzie trafia output. PS daje wiele możliwości tego gdzie możemy wysłać dane… ale nie na przedefiniowanie ‚output-default’. w związq z tym pisze się nadmiarowy kod ‚jeśli ekran to wywal na ekran, jeśli log, to wywal do logu’. zazwyczaj pisałem funkcję wspierającą, która to załatwia. coś w tym rodzaju:

to nie jest w pełni działający kod i ma tyle wad, że ciężko zliczyć. zależnie od przekazywanej zmiennej zachowa się inaczej w porywach do ‚nie zadziała’.

jak to zrobić PowerShell-way

są dwa mechanizmy, które pozwalają na uproszczenie całej procedury: aliasy oraz możliwość przedefiniowania standardowej wartości parametru dla commandletu. sam alias nie wystarczy bo o ile out-host nic nie potrzebuje o tyle przekierowanie do pliq wymaga co najmniej nazwy tego pliq…

w skrócie:

w zależności od przełącznika ‚log’ tworzony jest alias ‚out-my’ wskazujący albo na out-host albo na out-file. ponieważ out-file wymaga podania nazwy pliq, aby można było użyć aliasu bez parametru, ustawiona jest standardowa wartość poprzez $PSDefaultParameterValue

eN.

 

WMI vs CIM w praktyce

Windows_PowerShell_iconzakładam, że wszyscy wiedzą czym jest WMI i CIM – to jest abecadło dla każdego inżyniera systemowego. a [IMHO] podstawowa różnica w implementacji to możliwość tworzenia sesji CIM. czego dla WMI zrobić się nie dało. daje to niesamowite możliwości w przypadq hurtowych zapytań. podam trywialny przykład, gdzie zysk z zastosowania sesji nie jest wielki, ale osoby z wyobraźnią powinny poczuć moc, drzemiącą w takim zastosowaniu.

założeniem przykładu jest sztywna notacja nazewnicza dla hostów: ta sama nazwa ‚HOST’, zakończona inkrementowaną liczbą. ale równie dobrze można użyć ‚cat lista.txt | %‚ . niemniej chciałem przy okazji przemycić jeszcze jedną sztuczkę – w jaki sposób dopełniać liczby z dopełnieniem zerami.

cel: odpytanie 2o hostów o podstawowe informacje o BIOS – np. numer seryjny – oraz volumeny.

dla WMI

teraz zmierzmy czas dla wykonania tej sekwencji [ja robiłem dla siedmiu hostów]:

 

dla CIM

wydaje się być bardziej skomplikowane. odrobinę jest – trzeba najpierw założyć sesje, a następnie wykonać zapytanie wskazując na nie. sprawdźmy ekonomiczność zapytania [również dla 7 hostów]:

1331 vs 263  ms czyli 5cio krotnie szybciej [SIC!]. oczywiście można się przyczepić, że nie wliczyłem czasu utworzenia samej sesji ale…

wnioski

przy pojedynczym zapytaniu lub do niewielkiej ilości hostów – nie ma znaczenia czego użyjemy, bo czy co się wykona w 4oms czy w 1ooms jest dla człowieka pomijalne. jednak możliwość tworzenia sesji zwraca się przy seryjnych odpytaniach oraz jeśli do odpytania jest wiele hostów.

warto zauważyć, że przy dłuższej pracy zapis się upraszcza – ponieważ zamiast na iteracjach czy listingach, pracujemy na liście sesji.

eN.

 

 

Hyper-v replication – Critical

repairHyper-v Replica – problemy

Hv Replica jest dobrą ideą – jednak wykonanie szwanqje. wiele operacji, jakie jest wykonywane w ramach HvR jest zabójcze dla niego samego. do tego zachowanie jest bardzo nieprzejrzyste – do powodu błędów trzeba mocno dociekać, opisy są zwodnicze, braqje narzędzi do bezpośredniego debugowania. mówiąc w skrócie – mechanizm zaprojektowany jest jako samograj, a niestety jest na tyle niestabilny, że ciągle trzeba przy nim grzebać i jest to ciężka systemówka.

replikacja przerzuca pliki wektorów zmian [.hrl]. kiedy zostanie przerzucony plik, następuje… łączenie [merge] plików vhd. o ile w przypadq małej zmiany i małego pliq wszystko sobie działa dobrze, o tyle przewalenie kilq GB pliq do zmerdżowania z np. 1TB dyskiem, jest operacją zabijającą mechanizm – nie ma możliwości skończyć się ani w 5min [standardowy czas przerzucania zmian HvR] ani w 15min [max. jaki można ustawić] a zdarza się, że i godzina byłoby za mało, jeśli dyski są na prawdę duże. operacja jest wykonywana po stronie odbiorcy i jest to operacja bloqjąca – w czasie, kiedy jest wykonywana, z maszyną nie da się nic zrobić, a nadawca dostaje informację, że replikacji nie można wykonać.

dodatkowym problemem jest fakt, iż operacja łączenia dysków nie jest w żaden sposób pokazywana przez interfejs. błędy wyglądają następująco:

serwer wysyłający

log Hyper-V-VMMS/Admin, Event ID: 32552,

 

log Hyper-V-VMMS/Admin, Event ID: 32315,

 

serwer odbierający

log Hyper-V-VMMS/Admin, Event ID: 15268 [nie występuje zawsze]

log Hyper-V-VMMS/Storage, Event ID: 27000,

ponadto jest możliwość szybkiej weryfikacji przy pomocy PowerShell, weryfiqjąc status maszyny na serwerze odbierającym:

statusy wyraźnie pokazują – ‚InService’ oraz ‚ModifyingUpVirtualMachine’ – być może taki status jest również w innych scenariuszach, ale regularnie powtarzający się – może oznaczać tylko jedno. dyski się łączą.

dalsze konsekwencje

to za chwilę prowadzi to zmiany statusu repliki na ‚critical’ i ustawienia wymuszenia resynchronizacji w następnym cyklu [standardowo chyba raz dziennie o 18.oo – godzinę można sobie ustawić]. jeśli ręcznie wymusi się powtórną próbę replikacji po zakończeniu operacji ‚merge’, to wszystko powinno być ok i maszyna powinna się zacząć replikować. jeśli jednak zostawi się na automat, to do cyklu resync może minąć zbyt wiele czasu, a to będzie oznaczało faktyczny resync.

i tu dochodzimy do kolejnej maskrycznej operacji – resynchronizacja. jest to kolejna operacja bloqjąca, podczas trwania której sypią się backupy [lockowany jest VSS], a biorąc pod uwagą ile trwa czasu dla dużych dysqw, potrafi spowodować lawinowe błędy.

jak uniknąć części błędów

różnymi automatami – trzeba monitorować replikację i oskryptować całe rozwiązanie. można to zrobić w bardziej wyrafinowany sposób, można po prostu co jakiś czas wymuszać resync dla wszystkich maszyn.

jest też ciekawostka, która nigdzie nie jest opisana – w każdym razie nie trafiłem – podeślijcie linka, jeśli się mylę. póki co – wisienka na torcie, exclusive dla w-filesowiczów (;

kiedy poobserwuje się replikację, można zauważyć, że w pewnym momencie taski ‚zawisają’. jeśli z powodów opisanych powyżej wykonuje się kilka resynchronizacji, nagle okazuje się, że pozostałe maszyny co i rusz, również wchodzą w stan ‚critical’. ograniczeniem jest opcja definiująca ilość równoczesnych ‚storage migration’, ustawiana we właściwościach Hyper-V. standardowo są to dwie operacje. nawet jeśli maszyny rozłożone są na kilq węzłach klastra, może okazać się, że jakieś dwie długie synchronizacje lub resynchronizacje, będą blokować pozostałe maszyny. dla tego warto ten parametr zwiększyć. to znacząco obniża ilość problemów!

ponoć w Windows 1o Server, mechanizm replikacji ma być wymieniony – ale również nie mogę znaleźć artykułu potwierdzającego ten fakt /:

będę wdzięczny za linki (:

eN.

 

strach wyłączać – UEFI boot

repairdwa nowe serwery ProLiant DL360 Gen9… UEFI. po wyłączeniu serwerów nie wiedzieć czemu, rozwala rekord startowy. nie chce mi się opisywać hec jakie są z tymi złomami, ale przynajmniej ręczne rozwiązanie w przypadq wystąpienia problemu:

  1. jeśli jesteś szczęściarzem – płyta instalacyjna będzie widziała kontroler dysków. jednak w przypadq serwerów jest olbrzymie prawdopodobieństwo, że sterów do kontrolera RAID nie będzie. zatem pierwszy krok: przygotuj rozpakowane sterowniki dla kontrolera storage w wersji rozpakowanej – „.inf”.
  2. uruchom winPE – może być zwykła płyta instalacyjna Windows Server – uruchom konsolę [shift-F1o]
  3. sprawdź jakie są widoczne w systemie dyski. jeśli nie widać tego z systemem – załaduj sterowniki z pkt.1. dwie ciekawostki: instalacja z GUI nie powiedzie się [jeśli ktoś będzie próbował przez cześć recovery]. a druga to taka, że po załadowaniu z konsoli system krzyczy, że wymagany jest restart… ale powinno działać.
    • drvload <usb:>\<plik.inf>
  4. przypisz literę dla partycji EFI – łatwo ją rozpoznać, bo to mała partycja FAT32.
    • Diskpart
    • List vol [zapamiętaj oznaczenie dla OS]
    • Sel vol <EFI>
    • Assign letter=v:
    • Exit
  5. nadpisz sekwencję bootowania
    • cd /v v:\EFI\Microsoft\Boot
    • bootrec /fixboot
    • bcdboot <OS:>\windows /s v: /f ALL
  6. dla systemu z Hyper-v należy włączyć obsługę Hv. tu też ciekawostka – bez tej opcji usługi wstaną, ale przy próbie uruchomienia maszyny, będzie drzeć ryja. a wedle doq technetu to opcja służąca do debugowania. trochę zatem zaskaqjące to jest obligatoryjne a nie opcja /:

    hypervisorlaunchtype [ Off | Auto ]Controls the hypervisor launch options. If you are setting up a debugger to debug Hyper-V on a target computer, set this option to Auto on the target computer.

    • bcdedit /set {default} hypervisorlaunchtype Auto

po tej operacji system powinien prawidłowo się zbootować.

eN.

PS ISE – cudowny trick

windows-powershell-ise-iconostatnio odkryłem cudowny trick w PowerShell Integrated Scripting Environment:

przytrzymać shift+alt i teraz:

  • poruszając się strzałkami góra/dół oraz lewo/prawo można zaznaczyć blok
  • a teraz jeszcze lepszy: poruszając się strzałkami góra/dół rysuje się pionowa linia. i teraz kiedy zaczyna się pisać we wszystkich liniach pojawiają się znaki =^.^’=  tak samo można kasować.

przydatne w wielu scenariuszach – np. w hurtowym komentowaniu fragmentu kodu.

eN.

wymiana certyfikatu dla hyper-v replica

informacji o tym jak skonfigurować – od groma. ale jak wymienić certyfikat… no więc proszę:

po wymianie certyfikatu na serwerze źródłowym Hyper-v Replica trzeba jeszcze zmusić go do korzystania z niego. okazuje się, że używany cert jest właściwością replikowanej maszyny. oznacza to, że zmianę trzeba wprowadzić dla każdej VMki. można klikać – jak się ma dwie-trzy maszyny może i się da. ale jak się ma ich *dziesiąt to trochę mało fajne. szczęśliwie jest … PowerShell (: jakże by inaczej.

  • zaloguj się na którymś z Hv [np. enter-pssession]
  • skopiuj thumbprint certyfikatu

  •  potem można myszką skopiować ‚thumbprint’ tego, o który chodzi.
  • następnie trzeba wprowadzić zmianę dla maszyn. dla całego clustra sobie daruję, ale dla wszystkich VMek na pojedynczym hoście:

a potem można zrestartować usługę ‚vmms’ żeby odświeżyć replikację.

i już

 

 

VSS EventID 8194 na klastrze Hyper-v

po wstawieniu nowej macierzy EqualLogic i zaktualizowaniu HIT [Host Integration Tools] na węzłach, w eventlogu zaczęły się masowo pojawiać wpisy Event ID 8194 :

różne dziwne rozwiązania testowałem, przeszuqjąc Internet. większość sugestii dotyczyła dodania odpowiednich uprawnień na DCOM dla NT Authority\Network, odrejestrowanie hardwareowego requestora EQL, wyłączenie wykorzystania MPIO dla hardwareowych snapshotów i kilka innych pomysłów, większość artów wskazywała również na DPM…

finalnie trzeba było poskładać to do qpy, bo odpowiedź tkwiła w pomiędzy i kilka najważniejszych uwag, które mogą być przydatne przy takim debugowaniu:

  • to, co było najbardziej zwodnicze i spowodowało wydłużenie czasu debugowania, to założenie, że jak zrobię coś na jednym węźle i zadziała, to potem będę mógł wprowadzić na pozostałych węzłach. błąd logiczny w tym myśleniu polega na tym, że żądanie wysłane przez DPM do dowolnego węzła, generowało błędy na wszystkich. czyli nie widziałem poprawy po swoich zmianach, ponieważ błędy pojawiały się w wyniq akcji na innym węźle.
  • podstawą rozwiązania i zrozumienia całego problemu było znalezienie procesu, który wywołuje ten błąd. po sprawdzeniu szczegółów [details] dla tych wpisów w eventlogu, można znaleźć PID procesu, który go wywołuje. wskazało to na proces svhost, który zawierał kilka usług – m.in. usługę „Cryptographic Service”. trochę mnie to ździwiło, ale pozwoliło wyszukać właściwy wątek, w którym można przeczytać:

This problem appears only as part of a cluster ; This event is visible on nodes other than the one who initiated the call to VSS.

During a VSS call, the Cluster service sends requests to all nodes through the GUM (Global Update Manager). Because the „System Writer” is hosted by the encryption service (cryptographic service or cryptsvc) and that it is executed in a context „Network Service” instead of „System”, the return of COM calls a meeting Denied Access because different impersonnations on other cluster nodes

The problem will not be fixed as it has no functional involvement

dalej niestety jest info, że ten błąd nie wpływa na nic i nie będzie poprawiany. ciekawe, bo wpływa – bakcupy DPM nie bardzo chcą się robić…

  • ostatecznym rozwiązaniem było wykonanie *na wszystkich węzłach*:
    • zmuszenie DPM do korzystania z software providerów – tworzy się pusty klucz [nie wartość] na kliencie DPM [Software\Microsoft\Microsoft Data Protection Manager\Agent\UseSystemSoftwareProvider]
    • wyłączenie hardware providera EQL

eN.

Windows Updates z linii poleceń

jakoś ostatnio zauważam coraz więcej problemów z Windows Updates po stronie klienta – a to nic nie wyświetla, a to nie działa w ogóle ‚wejście’ do listy update’ów – jakby link był martwy… no i oczywiście dochodzą serwery bez GUI.

a przecież po zainstalowaniu wersji Core dostępna jest commandline’owa wersja instalacji poprawek. wystarczy więc zajrzeć gdzie to sobie leży … i:

warto zapamiętać: C:\Windows\System32\en-US\WUA_SearchDownloadInstall.vbs. w razie co, łatwo znaleźć:

nie wiem czemu to jest w vbs, tak samo jak nie rozumiem czemu serwery w2k12 bez GUI otwierają cmd, ale wewnątrz widać proste polecania, które można łatwo przepisać na jakiś ludzki język (:

eN.