Skip to Content

IT nieuczesane.
category

Category: tips’n’tricks

Najlepszy skrót w Windows 8

Właśnie walczę drugi dzień z interfejsem W8 i naciskając po kolei wszystkie kombinacje Windows+… trafiłem na Windows+X
Może i lamerski wpis, ale mi ułatwił życie… może innym się przyda. Poniżej wynik tej kombinacji:

zarządzanie VM z hosta Hv

środowiskiem zarządza się z jakichś narzędzi infrastrukturalnych typu System Center – to oczywiście najlepszy sposób ale w pewnych warunkach mało przydatny lub niemożliwy. zarządzanie w tej warstwie jest niemal niemożliwe/totalnie skomplikowane w środowisq hostowanym – wiele domen nie powiązanych ze sobą, maszyny w podsieciach porozdzielanych VLANami, inne przestrzenie nazewnicze i tak dalej… efekt jest taki, że nawet jeśli dla narzędzi uwierzytelnienie w wielu domenach nie jest problemem, pozostaje bardzo skomplikowany schemat sieci i bezpieczeństwa – często niezależny od administratora i zarządzany przez klienta.

fajnie byłoby móc to wszystko ogarnąć z jednego, centralnego punktu – klastra Hyper-V, gdzie te wszystkie hosty sobie działają. skoro mam je w jednym miejscu logicznym się wydaje, aby z niego wykonywać pewne operacje maintenancowe czy administracyjne [oczywiście jeśli taka jest umowa z klientem]. na każdym guescie powinny być Integration Services, Hv komuniqje się z IS i … co możemy dzięki temu zrobić?

nic. w każdym razie bardzo niewiele. powód jest prosty – z założenia całość musi być bezpieczna a Hv ma być warstwą izolującą. nie bez powodu w Hv w konsoli zdalnej nie ma możliwości mountowania dysków czy nawet schowka. Hv ma pozostać możliwie najcieńszą i najbezpieczniejszą warstwą.

co zatem jednak można oraz jak sobie z takim środowiskiem poradzić?

root\virtualization

popatrzmy co nam daje WMI z poziomu hosta. skoro można coś zrobić z poziomu SCVMM to znaczy, że da się z konsoli w postaci skryptu. obszerna lista klas pozwala na pełną konfigurację i odpytanie maszyny – oczywiście od strony ‚wirtualnego hardwareu’ – czyli nadal nie to, co mnie w tej chwili interesuje, ponieważ chciałbym dostać się do OSa. i tutaj z ciekawszych klas można znaleźć:

  • MSVM_ComputerSystem – podstawowa klasa, pozwalająca dowiedzieć się czegoś o samym OS. informacje nie są jednak dostępne bezpośrednio z tego obiektu – trzeba informacje ‚wymienić’ między hostem a guestem, a robi się przy pomocy klasy…
  • Msvm_KvpExchangeComponent – to podstawowy komponent służący do wymiany informacji między hostem i guestem. dzięki kombinacji tych dwóch klas można m.in. sprawdzić: FQDN systemu, skonfigurowane adresy IP, wersję systemu i SP itp. to podstawowa klasa pozwalająca na dalszą automatyzację – nazwa maszyny wirtualnej jest zupełnie nie przydatna poza kontextem samego SCVMM/HvM. aby połączyć się czymś do VM trzeba będzie to zrobić ‚oficjalnie’ czyli via sieć. a do tego potrzebny jest IP, który można uzyskać właśnie z tej klasy.
  • kilka innych klas ‚Integration Services’ pozwalających na interakcję z wewnętrznym OSem – shutdown, timesync i VSS. szczególną uwagę zwraca – Msvm_GuestFileService i Msvm_CopyFileToGuestJob – dostępne od wersji Windows 8.1. zdaje się, że wraz z R2 będzie można w końcu normalnie kopiować pliki q: pojawia się też inne klasy sugerujące, iż ilość operacji jakie będzie można wykonać z hosta będzie się rozszerzać.

praktyka

jednym z przydatniejszych skryptów jaki często wykorzystuje jest Get-VMDetails wykorzystujący powyżej opisane klasy. importuję go jako funkcję dzięki temu na stacji zarządzającej jest zawsze dostępny:

funkcja wypluwa obiekt dzięki czemu łatwo jest potem dalej odpytywać o poszczególne atrybuty. przykładowe użycie:

środowisko

ostatecznie daje to tylko podstawowe informacje pozwalające na dalsze podłączanie się do maszyn. z samym system z tego poziomu nie zrobi się wiele więcej. nic zatem nie zastąpi odpowiednio przygotowanego środowiska tak, aby z centralnego punktu można było do maszyn się podłączyć.

można by poudostępniać sieci guest-VLAN dla hosta aby z jego poziomu dostawać się VMek. ale uważam, że to nie jest najlepszy sposób… izolację lepiej pozostawić. zależnie od polityki być może da się utworzyć stację, która będzie miała dostęp do wszystkich VLANów będące punktem styq. takim punktem mogą być  np.:

  • stacje monitorujące. np. nagios, open manage czy inne wynalazki. zależnie od polityki być może da się utworzyć stację, która będzie miała dostęp do wszystkich VLANów
  • system AV
  • system backupów
  • system dystrybucji poprawek

ponieważ klienci mogą nie wyrazić takiej zgody lub środowiska muszą być odizolowane w 1oo% z jakiś względów – pozostaje utworzenie kilq stacji w różnych sieciach, nawet jeśli wszystkie VM są na pojedynczym klastrze. fajnie byłoby mieć możliwość instalacji ‚superagenta’ – który pozwoliłby na pełny dostęp do VM z hosta po uwierzytelnieniu – IMHO jeśli ktoś ma uprawnienia/zalecenia do maintenancu maszyny, security nie powinno cierpieć szczególnie pozwalając na dodatkową metodę dostępu…

refs

suma wszystkich pestek

odwieczny problem – archiva maili. nieużywane, ale nie wolno tknąć, broń Cię Panie Wielki Kalqlatorze! bo może ktoś-kiedyś-coś-jakoś i co wtedy??

no więc serwery są zawalone pestkami. oczywiście nikt nie kontroluje co gdzie jest zbackupowane – leży więc po kilka kopii w różnych miejscach. ogrom. jak policzyć ile to zajmuje, żeby pokazać klientowi skalę problemu w cyferkach?

polecam w pierwszej kolejności sięgnąć po raporty FSRM. narzędzie jest od dawna w systemie i warto sobie o nim czasem przypomnieć. raporty/statystyki – trzeba to pamiętać – są łatwe w generowaniu, trochę trudniejsze w interpretacji.

jako przykład proponuję takie statsy:

  • „file by filegroup” i w opcjach zaawansowanych ‚Email Files’
  • oraz „least used” co by pokazać, że są to równocześnie nieużywane pliki.

nie daje to 1oo% aqracji ale na pewno są ‚na szybko’ i ‚wyglądają’ czyli dwie ważne rzeczy aby raport pokazać np. managementowi [czy adminom].

bardziej geekowe/administracyjne podejście to oczywiście powershell. najpierw łanlajner żeby zliczyć wielkość wszystkich plików typu XXX:

bardziej rozbudowane statsy pokazujące ilość plików, sumaryczną wielkość oraz ile z nich nie było używane przez ostatni rok:

Filter or Include?

i na koniec jeszcze ciekawostka. filtrować listę plików [i nie tylko] można na trzy sposoby: filter, include i late-filtering. bardziej po polsq: można zdefiniować filtr bezpośredni, można zdefiniować co ma zawierać lista [wbrew pozorom to co innego niż filtrowanie] i można zrobić listę a potem ją filtrować – której metody używać?

mi się nie chciało tego mierzyć q: ale komuś się chciało: http://tfl09.blogspot.com/2012/02/get-childitem-and-theinclude-and-filter.html . wynik: najszybszy jest filtr i to dość znacząco.

eN.

 

 

Hyper-v replication v1.o?

znaczenie wersji produktów/ficzerów w Microsoft:

  • v1.o – marketing czyli ‘mamy taki produkt, jesteśmy na rynq!’. w rzeczywistości nie zdatny do użytq – po prostu ładnie wygląda na reklamie i informuje, że eMeS wyraża zainteresowanie tym fragmentem rynku
  • v2.o – początek, czyli – ‘mamy taki a taki produkt, potrafi to i to, nie potrafi jeszcze tego i tego, ale SOHO/SMB ma już pewne funkcjonalności za free’. w rzeczywistości – hmmm.. faktycznie działa.
  • v3.o – wdrażamy w ENT. w rzeczywistości – można wdrażać w ENT, bo faktycznie już jest skalowalny i większość funkcji nie dość że jest, to działa dobrze.

w w12 jest PowerShell v3.o oraz Hyper-v v3.o – oba naprawdę fajne i dojrzałe. a do Hv dodano nową, świetną funkcjonalność – Hv Replication… i jest ona ewidentnie w v1.o.. no może v2.o. o samej konfiguracji już trochę pisałem. czas na opis samej funkcjonalności.

co można o niej powiedzieć – jest. pomysł zaiste przedni – na miarę VMWare SRM. do tego stopnia fajnie pomyślane, że pozwala na wykorzystanie w scenariuszu hostingowym, gdzie stacje nie są w tej samej domenie. zacnie. skoro backup na hostingu – to znaczy łącze jakieś-takie. w sensie, że nie LAN 1GB. i teraz dochodzimy do clue, czyli to, co w całej świetności zostało spartaczone do stopnia nieużywalności. a są to dwa podstawowe ‘mankamenty’ + jeszcze trochę:

  • miejsce docelowe replikacji ustawiane jest per cały cluster a nie per replikowana maszyna wirtualna.
  • replikacja wykonywana jest co 5 min. i nie inaczej.

konsekwencje:

– jeśli chce się zrobić replikę całego clustra Hv, to wszystkie maszyny pchane są na pojedynczy storage. nawet jeśli maszyny-źródła są rozlokowane na wielu CSV dla zwiększenia wydajności, to docelowo będą przechowywane na pojedynczym. czyli jeśli strzeli podstawowa serwerownia, to zapasowa i tak może nie unieść takiego obciążenia. w efekcie można stosować albo dla bardzo małych środowisk – jedna, dwie maszyny, albo dla bardzo bogatych – gdzie jest się w stanie dostarczyć infrastrukturę [macierz, switche, NIC etc] potrafiącą unieść ‘takie’ obciążenie na jedym CSV. ‘takie’ – testowaliśmy to myśląc o redundancji dla klienta, gdzie na źródlanym klastrze stoi ok. 4o produkcyjnych maszyn. jedynym ratunkiem jest dodatnie do naszego DRP kroku pod tytułem ‘storage migration’ – czyli w trakcie uruchamiania maszyn w naszej lokalizacji offsite, równolegle migrujemy je na inne/docelowe CSV. odpalenie 4o wirtualek na jednym CSV po prostu się nie uda.

– no i najgorsze z najgorszych – czyli te nieszczęsne 5 min. ktoś, kto to zaharcodował musiał być po ciężkiej nocy – nie wnikając czy chodzi o pracę, czy zabawę, ale na pewno miał zaćmienie. replikowane są oczywiście delty – super. Mierzyliśmy je i nawet przy produkcyjnej maszynie nie są to *standardowo* duże zmiany – ot, 2-4MB. nawet dla 4o maszyn, przy 1oMbps łączu – 5min [teoretycznie i przy pełnej przepustowości] powinno wystarczyć. ale często, zbyt często, na maszynach produkcyjnych pojawiają się zmiany dużo większe – transakcje sql przy operacjach maintenancowych, operacje na serwerze plików, gdzie wrzuca się duże wielości czy tymczasowe pliki zrzucane przez aplikacje. nieszczęsny DPM potrafi na chwilę wrzucić 5GB plik. nie ma niestety możliwości utworzenia wykluczenia dla katalogu czy typu pliq – co w jakiś sposób by zminimalizowało problem w związq z czym trochę matematyki:

  • załóżmy, że aplikacja utworzyła tempa 5GB. w sumie to bez większej różnicy czy jest to temp czy nie, ale ten scenariusz jest bardziej absurdalny i pokazuje nonsens w jaki się wpada, bo plik za chwilę znika. 5GB=4o96oMb. przy teoretycznym 1oo% dostępności, dajmy na to na 5oMb łączu, taki plik repliqje się 4o96o/5o/6o=13,65 minuty. tylko ta jedna zmiana i na naprawdę fajnym łączu i przy 1oo% dostępności – czyli warunki bardzo optymistyczne [czyt. mało realne]. dla 1oMb łącza ta liczba to już ponad 1h.
    co się dzieje w tym czasie? oczywiście uruchamiają się kolejne wyliczenia delty, ponieważ w ciągu tego czasu minęło kilka/wiele 5minutówek. w praktyce może się okazać, że za nim zreplikujemy naszą pierwszą zmianę (5GB) to przestanie ona być aktualna, ponieważ za chwile nadpisze ją kolejna zmiana. czyli w praktyce hv wysyła coś, co za chwilę zostanie nadpisane kolejną zmianą. zamiast się połapać i od razu wysłać ostatnią wersję naszych zmian. mały schemat:

image

jakieś tam obejście to zpauzowanie replikacji i uruchomienie z opcją resynchronizacji [koniecznie run as admin, inaczej krzyczy, że takiej maszyny nie ma]

  • Suspend-VMReplication –vmname <VNAME>
  • Resume-VMReplication –vmname <VNAME> -resynchronize

dzięki opcji resynchronize hv idzie po rozum do głowy i porównuje stan maszyny replikowanej na chwilę obecną z maszyną kopią, ergo tworzy nową deltę jedynie z ostatnimi zmianami. oszczędza nam to replikowanie ‘stanów pośrednich’. niestety resynchronizacja trochę zajmuje, dodatkowo została pisana z myślą o vhd/vhdx nie większych niż 500 GB. jeśli mamy takie trochę większe (np. dysk z danymi baz ponad 1TB), wtedy resynchronizacja zachowuje się mało wydajnie.

pojawia się wiele dodatkowych wątpliwości – bo trzeba nieźle się wstrzelić z czasem tegoż suspendu. w praktyce, wymagane jest małe dochodzenie, w jakich godzinach dochodzi do tworzenia ogromnych delt. osobiście pomogłem sobie małym skryptem, odpalanym ze schedulera co 5 minut

  • $time = "{0:yyyy-MM-dd_HH.mm.ss}" -f (get-date)
  • measure-vmreplication <VNAME> >> c:temp$time.txt

w prosty sposób mamy fajny obraz jak nasze delty rosną na przestrzeni czasu.

a rozwiązanie mogłoby być bardzo trywialne: zamiast nie-wiedzieć-skąd-wymuszone-5-min, wystarczyłoby, aby każda synchronizacja była wzbudzana – ot choćby przez scheduler. dzięki temu można byłoby w pełni kontrolować całą replikację, robić ją np. 2 razy dziennie, omijać okienka maintenancowe i backupowe i tak dalej…

z rzeczy na plus, które faktycznie działają i są miłym zaskoczeniem:

  • kompresja – pogłoski mówiły o superwydajnym rosyjskim algorytmie, ale nie wiadomo jak to jest w praktyce. wiadomo natomiast, że faktycznie działa. zależnie od pomyślności wiatrów skacze od 5o% do 7o%. przy wstępnych wyliczeniach można założyć, że mamy prędkość replikacji równą 1,5 przepustowości naszego łącza.
  • robienie pierwszej repliki na dysk USB – by zacząć replikację, musimy najpierw skopiować całą wirtualną maszynę do lokacji off-site. można to robić po WANie, ale można też tą pierwszą kopię zrobić na nośnik i przesłać go do serwerowni. kiedy nasza ‘initial replica’ zrobi się na dysk USB, po drugiej stronie powstaje replikowana maszyna z pustymi dyskami i snapshotem. Hv replikuje już zmiany do snapshota, mimo, że cała maszyna nie została jeszcze wgrana. replikacja działa, a kiedy kurier zawita do nas z nośnikiem, możemy w dowolnym momencie zaimportować sobie naszą pierwszą replikę.
  • wersjonowanie – czasami może się okazać,
    że replikujemy zmiany z już uszkodzonej wirtualnej maszyny. nasza replika jest odwzorowaniem oryginału 1:1, więc jeśli uszkodzi się OS w oryginalnej maszynie, to samo spotka naszą replikę. wersjonowanie umożliwia trzymanie kilku snapshotów replikowanej maszyny. gdyby okazało się, że coś nie hula, możemy cofnąć się o te kilka/kilkanaście godzin.

na chwilę obecną Hv replica jest i się uśmiecha, ale jest to jeszcze bardzo nieśmiały uśmiech. niemniej działa i przy świadomości ‘charakterystyki’ tego działania, można śmiało wdrożyć to dla klienta, który nie ma wyśrubowanych wymagań. w praktyce eMeS oferuje nam trzy opcje na stworzenia sobie taniego DRP:

  • Hv Replica
  • połączenie Hv Replica i Data Protection Manager Chain Backup – maszyny, których nie da się replikować Hv Replicą, replikujemy DPMem, który podobnie wylicza delty, ale w bardziej zarządzalny sposób.
  • DPM Chain Backp – wszystko replikowane za pomocą DPMa

każde podejście ma swoje zady i walety ale o tym… może kiedyś…

eN & Damian Skrzypiec

powershell – kiedy będzie standardem?

globalnie – nie prędko. z jednej strony możliwości PS się zwiększają z każdą wersją systemu, z drugiej strony – pozostają bez zmian dla wersji starych. potworny dualizm – jest wiele zapowiedzi, że będzie wycofane wsparcie konfiguracji TCP/IP z netsh, wmic – z drugiej strony po uruchomieniu w12 w wersji core nadal jesteśmy witani CMD – co jest zresztą dla mnie zupełnie niezrozumiałe /: . taki oto scenariusz, na który często trafiam:

trzeba coś zautomatyzować/zmienić u klienta. wersje serwerów – od W2k3R2 po w12. jakie mamy środowisko do tego?:

  • na w2k3R2 powershella nie ma w ogóle
  • na w2k8 jest, ale dla tej wersji była bardzo ograniczona liczna cmdletów
  • na w2k8R2 cmdletów jest więcej ale nadal są ograczniczone
  • na w12 jest ich na prawdę dużo, ale część operacji i tak trzeba wykonywać via stare commandlineowe toole.

i tak wybór jest pomiędzy:

  • zainstalować na wszystkich maszynach powershell. zadanie nietrywialne bo nie wszędzie jest v3, trzeba spełnic szereg wymagań, być może dograć jakieś moduły. sporo zachodu ale jeśli jest się adminem sieci to można się pobawić. jednak dla konsultanta – osoby z zewnątrz – jest to nieopłacalne.
  • być uniwersalnym – korzystać z VBS + CMD

finalnie – jeśli ma być uniwersalnie to trzeba sięgnąć do VBSa, co jest bolesne. po wygodzie i mozliwościach, jakie daje PS, grzebanie się w basicu jest ciężkim doznaniem.

niezrozumiałe dla mnie pozostaje:

  • czemu default shell w core to cmd
  • czemu PS nie jest poprawką obligatoryjną/sugerowaną dodatkową – w końcu to podstawowe środowisko zarządzania! na stronie opisującej WMF 3.o jest informacja iż nie jest kompatybilny z <tu całkiem spora lista>. niewątpliwie odpowiada to bezpośrednio na pytanie ‘czemu nie jest poprawką obligatoryjną’ ale rodzi pytanie – skąd te niekompatybilności?
  • czemu nie ma oficjalnych update’ów modułów do PS?

w efekcie, pomimo ostrego parcia w kierunq PS nie można mu zaufać – skrypty napisane na jeden system mogą nie działać na innym. brak jest spójności i jednego, porządnego środowiska.

Powershell basics mini-FAQ

  • jak sprawdzić wersję powershell:

$host.version

  • czy da się zupgradeować powershell do wersji 3 na wszystkich systemach?

po pierwsze to nie tylko PowerShell ale ‘Windows Management Framework’. na cały framework składa się kilka komponentów, wykorzystywanych na końcu łańcucha przez PS: BITS, WinRM i kilka innych komponentów, +oczywiście .NET framework. na staszych systemach trzeba więc zupdateować i pozostałe komponenty.

dla w2k8, w2k8R2 i w7 da się – można zaciągnąć z download center
dla wersji 2k3/XP SP3 jest tylko v2 i nowszej nie będzie

  • jak sprawdzić dostępne moduły

get-module –listAvailable

użytkownika: userdocumentswindowspowershellmodulesmymodule
systemowe: windowssystem32windowspowershellV1.0modulesmymodule

  • skąd wziąć moduły?

sporo jest na codeplexie. jedno z fajniejszych repozytoriów jest na technetowym wiki.

eN.

export/import maszyn wirtualnych hyper-v

takie proste… ale jak ja do czegoś siadam od razu staje się jakieś takie trudne… należę do grupy opisanej przez paradoks Wittgensteina na temat reguł ograniczonych. należę do tych, dla których najbardziej oczywiste rozwiązania wcale nie są najbardziej oczywiste…

jaki jest problem: nie ma SCVMM i trzeba sobie radzić narzedziami systemowymi. do wyboru mamy: Powershell [yeah!] i hyper-v manager. okazuje się, że export/import z HVmgmt działa zupełnie inaczej niż ten z PS. nie da się wexportować maszyny z GUI a zaimportować z PS – w każdym razie nie w prost. różnice:

GUI PS
EXPORT z GUI export-vm
generuje plik ‘config.xml’ znajdujący się w root katalogu exportu generuje plik <GUID>.xml znajdujący sie w katalogu Virtual Machines
plik xml zawiera tylko kilka podstawowych informacji. plik ma <1Kb plik xml zawiera pełny opis ma 33KB+
IMPORT z GUI import-vm
opcja ‘copy’ zostawia pliki w tym samym miejscu i generuje nowy ID opcja ‘-copy’ kopiuje pliki. standardowo zawsze zachowywany jest oryginalny GUID. aby wygenerować nowy trzeba dodać ‘-generateNewID’.
  nie da się użyć tych samych plików i zostawić GUID. operacja –register –generateNewId generuje błąd. nowy ID wymaga użycia opcji -copy
ładnie zakłda nowy katalog o nazwie maszyny wrzuca pliki do root katalogu maszyn wirtualnych

to tak w skrócie. ciekawostek jest jeszcze kilka – np. jak już się zaimportuje maszynę i przypadkiem zapomni się zmienić GUID to pupa. nie ma [bezpośredniej] mozliwości zmiany GUID – trzeba wywalić i zaimportować jeszcze raz. być może są jakies hardcore’owe możliwości z grzebaniem się w xml’kach ale to na pewno nie jest coś co zrobienia na szybko.

eMeSy chyba próbują zmusić ludzi do korzystania z SCVMM – nawet strona na technecie czy help dla poleceń systemowych hyper-v praktycznie nie istnieje. są parametry ale nie ma opisów jak je stosować i co robią ):

eN.

Hyper-v replication–konfiguracja

podczas konfiguracji Hyper-V replication można natrafić na wiele niespodzianek. teoretycznie jest to trywialne w konfiguracji – w praktyce artykuły są niepełne i wprowadzają w błąd. podstawowy jaki można znaleźć już zamieszczałem:

teraz testowałem konfigurację cluster-to-cluster i dwie ciekawostki:

  • teoretycznie usługa broker potrzebna jest na docelowym klastrze. niemniej trzeba ja zainstalować również na źródłowym – ponieważ jest tak dziwnie zaprojektowane, że będzie przedstawiać się FQDN’em CAP zasobu brokera [jego nazwą i IP]. żeby było ciekawiej – sam zasób brokera oraz obiekt CAP w AD można wyłączyć a nadal będzie działać /:
  • podczas generowania certyfikatu na replika-serwerze trzeba dodać SAN dla nazw obu węzłów klastra. czyli certyfikat musi mieć:
  • nazwę z CN dla brokera
  • nazwy wszystkich węzłów jako alternate name
  • takiego certyfikatu nie da się wygenerować makecertem – nie obsługuje alternate names. jedymym obejściem przy self-signed jest wygenerowanie certyfikatu wildcardowego.
  • jeśli na klastrze repliki będzie cert tylko z nazwą brokera, podczas konfiguracji Hyper-V replica pojawi się błąd:

    connection with the server could not be wstablished (0x00002EFD)

    HV connot connect to specified Replica server ‚<NODE-A>’. Error: A connection with the server could not be established (0x00002EFD). Verifiy that the specified server is enabled as a Replica server, allows inbound connection on port 443 and supports the same authentication scheme

    ten błąd jest dość mylący i dopiero rzut okiem do eventlogu wskazuje prawdziwy problem – brak obsługi na drugim węźle ze względu na certyfikat.

    eN.

    Replikacja Hyper-V – url revocation list check failed

    wraz z ws2o12 i nowym Hv v3 jest możliwość replikowania maszyny na zdalnego hosta. najbardziej interesujący scenariusz to replikacja hostingowa – jest sobie firma, która outsource’uje usługi IT i chce, aby ich maszyny były dodatkowo zabezpieczone. do tej pory wymagało to tworzenia całkiem wymyślnych struktur – VPNy, trusty, skomplikowane procedury recovery czy inne wynalazki. teraz scenariusz jest trywialny:

    • no owszem.. jakiś VPN czy inna komunikacja jest niezbędna
    • Hyper-v v3 u klienta i Hyper-v v3 w ośrodku hostującym
    • brak trustów, jakichkolwiek innych związqw między domenami. jedyny mechanizm uwierzytelniający to certyfikaty zdefiniowane po obu stronach. de facto cross-trust między rootCA choć wystarczy na wybranych serwerach

    jakie jest PKI każdy widzi (; CRLe często-gęsto są niedostępne. w labie z kolei łatwiej byłoby zrobić na selfsign’ach a nie bawić się w stawiania CA. a więc kilka tricków z pola walki:

    • do generowania certów można użyć makecert. niestety, pomimo że ma tylko 37kb nie ma go w systemie /: trzeba ściągnąć i zainstalować kilqGB SDK do Windows. LoL. albo sięgnąć po tego linka.
    • łatwo znaleźć art, w którym krok po korq opisana jest cała konfiguracja łącznie z poleceniami dla makecert – które są trudne i łatwo się pomylić. więc to bardzo ładnie, że ktoś to tak zacnie opisał
    • jest nawet polecenie w rejestrze wyłączające weryfikację CRLi. i tu się zaczyna problem, ponieważ on nie działa. ktoś zapomniał dopisać jeszcze jednego wpisu w rejestrze:

      ten wpis jest potrzebny zarówno przy clustrze jak i bez niego. kluczowa informacja
    • zmiany działają natychmiast i nie wymagają restartów – a więc jeśli nadal pojawia się błąd, to należy sprawdzić czy wartości są poprawnie wprowadzone do obu kluczy

    eN.

    instalacja systemu na po-DPMowej maszynie

    System Center Data Protection Manager to eMeSowy backup. mając do czynienia z kilkoma produktami do backupów śmiało mogę powiedzieć – ten jest najinniejszy ze wszystkich q: jedną z ciekawostek jest fakt, że dla każdego backupowanego systemu tworzona jest oddzielna partycja. taka partycja raz na jakiś czas się kończy. wtedy system tworzy kolejną partycję … i spanuje ją z poprzednią. wychodzi z tego straszny potwór. kiedy zajrzy się do diskmanagera na żywym systemie, gdzie backupowanych jest wiele serwerów – ilość ‘kreseczek’ jest nie do ogarnięcia. kreseczek – ponieważ nawet przy rozdzielności full hd ilość partycji jest zbyt duża, żeby starczyło miejsca na ich wyświetlenie (; zresztą – tam się raczej nie zagląda…

    niemniej może to stanowić problem. wedle zasady ‘jedno doświadczenie nie stanowi dowodu’ nie mogę powiedzieć, że to co opiszę poniżej jest zasadą, ale tak się stało ostatnio:

    padł serwer DPM i trzeba było przeinstalować system. po uruchomieniu instalacji windows, ta zawisała na 2o min do 2h zanim pokazał się ekran wyboru dysq dla systemu operacyjnego. instalacja działa jakoś wolno. dochodzi do ostatniego punktu i zawiesza się. czekaliśmy ok. dnia. drugi test – to samo. postanowiliśmy wyłączyć dyski, na których są backupy DPM. cała instalacja śmignęła i po nie całej godzinie system działał.

    być może winą były sterowniki dla RAID… jednak imho powodem było to, że system próbował skanować wszystkie partycje w poszukiwaniu jakiś danych i się gubił w labiryncie spanowanych dysków dynamicznych. jeśli ktoś miał podobne doświadczenie i potwierdzi lub obali będzie miło (:

    btw. jest opcja kolokacji danych na partycji. w nowym DPM 2o12 ponoć mocno poprawiona. póki co dopiero zaczynam swoją przygodę z tym produktem…

    eN.

    brak szablonów certyfikatów v2

    ha! tydzień rozwiązywania problemów (: wakacje to jednak piękna rzecz – to kolejna wyjaśniona tajemnica w krótkim czasie. tym razem trafił się serwer Enterprise RootCA. PKI to od jakiegoś czasu moje hobby [dzięki Pauli *] więc nie odpuściłem:

    • pojedyncze Ent root CA jako issuing. standardowa ‚zwalona’ instalacja u klienta czyli ‚wsadził-wyjął-PKI’. no co zrobić – tak jest i trzeba z tym póki co żyć
    • serwer w wersji w2k8 R2 standard
    • po utworzeniu nowych szablonów, których jakoś nikt do tej pory nie zrobił, nie można ich dodać do publikacji na CA

    podczas próby wyszukania jakiejś pomocy wszystkie linki dotyczyły podstawowego błędu – szablony w wersji v2 i v3 nie są obsługiwane przez wersję standard, wymagany jest enterprise. tyle, że od wersji w2k8 R2 ten limit zniesiono. żeby się upewnić postawiłem sobie wirtualkę w2k8r2std, na niej CA i na szybciorka upewniłem się, że spokojnie obsługuje v2 i v3. po długim debugowaniu w końcu znalazłem:

    • atrybut ‚flags’ dla obiektu ‚CN=MYCANAME,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=DOMAIN,DC=AD’ na partycji konfiguracji zawierał wartość ‚2’

    znaczenie tego atrybutu to:

    • 2„: Enterprise CA running on Standard Edition
    • 10„: Enterprise CA running on Enterprise Edition
    • 5„: Standalone CA running on Standard Edition
    • 9„: Standalone CA running on Enterprise Edition

    prawdopodobnie maszyna była upgradowana z wersji Windows 2oo8 std a instalator nie modyfiqje takich rzeczy. pomyślałem, że to on dyktuje dostępność szablonów i trafiłem – na wirtualce, pomimo wersji std, atrybut ustawiony był na ‚1o’. zmiana na produkcji, replikacja, restart usługi – voila! ^^

    refs:

    eN.