Skip to Content

IT nieuczesane.
archive

> Daily Archives: 18 stycznia 2013

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.

zmiana membership dla konta komputera bez restartu

podręcznikowo:
bilet sesyjny jest tworzony podczas logowania się [user]/startu [komputer]. wtedy też sprawdzane i zapisywane są informacje o przynależności do grup. w efekcie po modyfikacji przynależności do grupy trzeba przelogować [users]/zrestartować system [komp].
to oczywista oczywistość wykładana na podstawowym kursie. o ile w przypadku usera operacja logon/logoff zazwyczaj nie jest krytyczna o tyle restart serwera zazwyczaj boli. czy zatem da się zmienić przynależność do grupy konta serwera i go nie restartować? owszem.
wykonuje się to przy pomocy polecenia klist a dokładny opis z testem znalzlem na blogu terriego L@U – tak jakoś podobnie do mojego LU (;

dodatkowym przydatnym narzędziem w całym zadaniu może być sysinternalsowe logonsessions. klist jest od wersji 7/2k8 standardowo w systemie. operacja sprowadza się do wyczyszczenia listy biletów i zmuszenia przez to serwera to ich odświeżenia:
klist -li <nrsesji> purge

eN.

%d bloggers like this: