Wawszczak TechBlogLife just is a technic problem

Istnieją rzadkie przypadki, kiedy zachodzi konieczność ponownej instalacji klastra RMS. Najczęstszą przyczyną takiej potrzeby jest nieudany proces provisioningu z jakichś prostych powodów, jak na przykład przypisany wcześniej certyfikat SSL do Web Site’a w IIS. Po nieudanym provisioningu należy odinstalować rolę AD RMS i po restarcie maszyny zainstalować ją na nowo. Niestety jednak nie zawsze dochodzi do pełnej deinstalacji usługi. Błąd cytowany w tytule ma opisanych kilka potencjalnych przyczyn i odpowiadających im rozwiązań. Jednak podstawowym problemem jest zawsze konfiguracja serwera w rejestrze. Należy jednak przed dokonaniem zmian w rejestrze upewnić się, że jest to dokładnie ta rzecz, którą chcemy osiągnąć.
Mianowicie omawiany błąd może wystąpić z następujących powodów:

1. Nieprawidłowy Service Connectin Point – pojawia się w sytuacji, gdy z jakichś powodów w kontenerze CN=SCP, CN=RightManagementService, CN=Services, CN=Configuration, DC=domain, DC=lab pojawia się nieprawidłowy URL do usługi istniejącego już klastra RMSowego. Więcej informacji jedst dostępnych pod tym adresem. Jest to powód bezpośrednio podany w komunikacie błędu na zakończenie kreatora.
2. Druga przyczyna jest wspominana we wpisie w logu aplikacji skojarzonym z niepowodzeniem provisioningu o numerze 204. Ta przyczyna pochodzi z błędu w rejestrze, ale zachodzi ona z powodu braku jednej wartości. Zgodnie z przytoczonym artykułem wystarczy ten klucz ponownie utworzyć.
3. W przypadku odrzucenia poprzednich przyczyn należy zweryfikować zawartość gałęzi rejestru HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS. W przypadku gdy występuje tam jakakolwiek wartość, a szczególnie taka, która zawiera odwołanie do nieistniejącego URL, może wystąpić omawiany błąd. Rozwiązaniem jest usunięcie wszystkich kluczy z tej gałęzi rejestru pozostawiając jedynie wartość (default).

W przypadku napotkania innej, nie opisanej tutaj przyczyny dla tego błędu bardzo proszę o pozostawienie komentarza.

W pewnych sytuacjach pomimo instalacji Systemu Operacyjnego Windows w wersji Enterprise i konfiguracji roli Active Directory Certificate Services jako Enterprise CA usługa CA nie umożliwia publikacji szablonów certyfikatów w wersjach wyższych niż V1. Dzieje się tak z powodu błędnych wpisów w rejestrze charakteryzujących instalację CA jako Standard.

Rozwiązaniem problemu braku widoczności szablonów V2 i V3 w okienku dodawania certyfikatów (porównaj z rysunkiem) jest ustawienie flagi w konfiguracji instalacji CA:

Po aktualizacji rejestru konieczny jest restart usługi CA.
Ponadto wartym wspomnienia jest fakt, że istnieje możliwość ręcznej edycji listy szablonów za pomocą których CA wydaje certyfikaty. Jest to możliwe przez edycję atrybutu

w obiekcie

Obiekty te znajdują się w ścieżce

Dzisiaj będzie rzecz o tym, jak czasem korzystanie z manuala potrafi byc zwodnicze.
Normalnym jest, że jak się dostaje aplikację, którą potrzebujemy wywołać w sposób bardziej fikuśny, niż prosty „dwuklik” to wywołujemy

albo

W odpowiedzi dostajemy w dowolnej formie informacje dotyczące przełączników dostępnych w linii poleceń. W szczególności w takiej formie otrzymujemy informacje dotyczace uruchamiania różnych komponentów aktualizujących system Windows.
Instalator Dodatku Service Pack 1 dla Windows 2008 R2 odpowiada w ten sposób:

Akcją konieczną do wykonania żeby komponent Microsoft Deployment Toolkit był w stanie zaimportować dodatek jako pakiet systemowy jest rozpakowanie pliku .exe do postaci pliku Standalone Update (.msu lub .cab). Jak widzimy na przytoczonym zrzucie ekranowym producent nie przewidział takiej akcji.
Jednakże po kilku nieudanych próbach stwierdziłem że wywołanie:

Nie spowodowało zwrócenia błędu niepoprawnej komendy, natomiast pod oknem interpretera linii poleceń pojawiło się okno dialogowe z wyborem lokalizacji dla wyodrębnionych plików. Znajduje się wśród nich plik .cab, który jest konieczny przy użyciu MDT 2010 U1

Ciekawi mnie tylko, dlaczego Microsoft nie dodał tego przełącznika do manuala.

Serwer DHCP jest doskonałym kandydatem do instalacji na systemie w wersji core. Instalacja, konfiguracja i już. W zasadzie czynności związane z utrzymaniem ograniczają się do rzadkiego backupu i reakcji na zmiany w infrastrukturze sieciowej. A te nie zachodzą zbyt często. Więc warto zaoszczędzić zasobów na serwerze wirtualizacji i zainstalować Windows Core.
Jednakże, jak zazwyczaj w przypadku wersji Core, zetknięcie się z „gołą” linią poleceń cmd potrafi zabić entuzjazm. Postaram się go rozdmuchać na nowo tym prostym Step-by-Step guide’m.

Przypominając podstawowe sprawy (o które się dzisiaj rozbiłem) musimy pamiętać o kilku czynnościach. Po zmianie hasła, którą wymusza sam system operacyjny pierwszą czynnością (bo potem się zapomni) jest zmiana nazwy komputera. Do tego służy polecenie

Bieżącą nazwę (wygenerowaną przez instalatora) poznamy dzięki poleceniu

Drugą irytującą czynnością jest aktywacja systemu. Do tego potrzebujemy skonfigurować adresację IP oraz dokonać procesu aktywacji.
Tak więc, aby przypisać właściwe adresy właściwym interface’om potrzebujemy najpierw ich listę:

Zapisujemy wartość Idx właściwego interface’u. Następnie możemy przypisać adres IP, maskę podsieci oraz bramę domyślną:

Teraz jeszcze tylko serwer dns i mamy pełny ruch sieciowy:

Aktywacji dokonujemy poprzez dwie komendy:

W tym momencie nasz serwer jest gotowy do instalacji i konfguracji roli. Przedstawiony wstęp jest w zasadzie dostępny wszędzie, jednak warto mieć go pod ręką (a piszę to przecież także dla siebie).

Rolę serwera dhcp instalujemy poleceniem

Stan w jakim nasz serwer DHCP się znajduje zaraz po instalacji jest co najmniej interesujący. Wszystkie binaria są co prawda zainstalowane w systemie, jednakże usługa nie jest uruchomiona, a jej profil uruchamiania ustawiony jest na „Wyłączona”.
Żeby to zmienić należy wydać polecenia:

W tym momencie posiadamy sprawną usługę dhcp na serwerze. Jedyne, czego jej brakuje to konfiguracji. Tę możemy wprowadzić ręcznie, lub odtworzyć z kopii zapasowej. Ani jedno, ani drugie zadanie nie jest proste z linii poleceń. Jednak, zanim uruchomimy dostęp za pomocą narzędzi zdalnych, omówmy kwestię dodania naszego serwera do domeny:

Po wykonaniu powyższej komendy konieczny jest restart maszyny. Zwróćmy uwagę, że w tej chwili nasz serwer DHCP zostanie uruchomiony wraz ze startem systemu operacyjnego.
Jedną z ostatnich akcji wykonywanych wprost z linii komend serwera jest (uwaga – w tej kolejności!) instalacja PowerShell’a oraz konfiguracja zdalnego dostępu przez konsolę zarządzającą Windows Server Manager. Należy wywołać polecenie

i przejść do sekcji 4. Configure remote management. Następnie wybieramy opcję 2. Install Power Shell. Po tej operacji należy zrestartować maszynę. Następnie uruchamiamy ponownie skrypt sconfig i wywołujemy opcję 4.3 Allow server remote management.

Po wykonaniu tej akcji następuje aktywacja odpowiednich cmdlet’ów Powershella a także właściwa konfiguracja niektórych przestrzeni nazw WMI.
W tym momencie posiadamy dostęp do naszego serwera przez konsolę Windows Server Manager. Jeżeli chcemy skonfigurować nasz serwer od podstaw, to wystarczy otworzyć węzeł usługi w naszej przystawce MMC i wyklikać odpowiednie opcje (zakres przydzielanych adresów, maskę podsieci, bramę domyślną, DNS, wins) dla każdego z konfigurowanych zakresów.

Jednakże gdy chcemy odtworzyć nasz serwer z wykonanej wcześniej kopii zapasowej należy zachować szczególną ostrożność z dwóch powodów. Po pierwsze konsola pokaże nam okno wyboru katalogu zawierającego kopię zapasową. I jest to pewne ułatwienie, gdyż nie trzeba całej ścieżki wpisywać ręcznie. Jednakże jest to utrudnienie o tyle, że wskazujemy katalog lokalny, wcale nie mając na uwadze, że usługa DHCP będzie poszukiwać dokładnie tego katalogu na serwerze zdalnym. Nie należy się zastanawiać, dlaczego akurat to okno ma wyłączoną opcję pokazywania dysków sieciowych. Należy zadbać o to, żeby ścieżka wskazywana na dysku lokalnym istniała dokładnie taka sama na dysku konfigurowanego właśnie serwera typu Core. Drugą pułapką jest kwestia uprawnień. Nie zawsze usługa dhcp prawidłowo zdiagnozuje fakt, że danych plików nie ma i wyświetli błąd „Access denied”. Drugim możliwym błędem jest fakt, że konsola skoryguje uprawnienia na dysku lokalnym, a nie zdalnym (co jest dość logiczne – nie istnieje żadne powiązanie pomiędzy tymi strukturami katalogów). Należy pamietać o nadaniu uprawnień odczytu i zapisu do katalogu z kopią zapasową na serwerze DHCP dla konta builtin\DHCPService.

Przy zachowaniu opisanych wyżej procedur nasza usługa DHCP będzie długo i bez konieczności konserweracji działać na systemie typu Core.

Dzisiaj przyszła wiekopomna chwila. Uzyskałem tytuł Microsoft Certificated Technical Specialist – Windows Vista.
Egzamin do najtrudniejszych nie należy, aczkolwiek wszystkich przygotowujących się przestrzegam przed bagatelizowaniem tematyki aplikacji wbudowanych w system oraz procedur instalacji systemu operacyjnego.

Dzisiaj o czymś zupełnie nowym, ponieważ CA zostało dodane do Windows Core dopiero w wersji R2. Sama opcja instalacji tylko części komponentów nazwana „Core Installation” została udostępniona w wersji 2008.
Na temat Core Installation jest już dość dużo materiałów, na przykład ten artykuł Nataniela Zielińskiego, więc nie będę opisywał go szerzej. Dość powiedzieć że w wersji tej nie ma większości interface’ów graficznych, system zaś obsługuje się z lini poleceń. Istnieje też dobre opracowanie pozwalające ogarnąć Core Installation, jednakże część usług wprowadzonych dopiero w R2 jest nieomal pozbawiona dokumentacji.
Instalacja serwera CA na zwykłym Windows 2008 wymaga użycia kreatora dodawania roli, którego brak w wersji Core. Tak więc pierwszym krokiem jest zainstalowanie binariów usługi. Wykonuje się to poleceniem

Następnie warto dokonać sprawdzenia poprawności instalacji

Po upewnieniu się o tym, że mamy w systemie pakiet usługi, musimy ją skonfigurować. Można to wykonać za pomocą skryptu automatycznej instalacji dostępnego tutaj. Jest to skrypt VBScript który pozwala bez problemowo zainstalować CA. Na stronie podany jest pełen zestaw parametrów koniecznych do ukończenia procesu instalacji pomyślnie. Należy tutaj zwrócić uwagę na fakt, że parametry

oraz

są nie obsługiwane w Core installation.
Ponaddto przed przystąpieniem do instalacji CA, zarówno w wersji Core jak i zwykłej warto przygotować plik CApolicy.inf który należy umieścić w katalogu %SYSTEMROOT%. Przykład takiego pliku poniżej:

Po instalacji warto ustawić parametry CDP (CRL Distribution Point) na przykład tak:

Utworzenie takiego, lub podobnego skryptu pozwoli ominięcie „wyklikiwania” za pomocą zdalnie podpiętej konsoli mmc parametrów umieszczanych w certyfikatach.
Na koniec dodam, że pierwszym artykułem który pozwolił rozpocząć pracę z CA na systemie W2K8R2 Core Installation był artykuł Eyalestrin’a.

NMAP jest jednym z najczęściej używanych narzędzi administratorów linuxa. Jak wiadomo, umożliwia ono zweryfikowanie stanu poszczególnych portów TCP na określonym hoście/hostach. Jak do tej pory nie byłem w stanie znaleźć poprawnie działającego odpowiednika pod windows. Owszem, istnieją różne „porty” nmap’a czy to w CygWinie, czy też w SFU/SUA, ale wielokrotnie wymagają znacznie szerszych uprawnień, niż posiadają użytkownicy na ich maszynach.
Dlatego chciałbym Wam przedstawić prawdziwie Microsoft’owy odpowiednik tego narzędzia: PORTQRY. Jest to narzedzie na pewno dorównujące, jak nie przewyższające możliwościami nmap dla środowisk Windows. Mówię, że przewyższające, gdyż posiada możliwości śledzenia dynamicznych portów RPC wykorzystywanych przez DCOM. A RPC/DCOM są podstawą działania większości usług. Active Directory, Certificates Services, Exchange – oto tylko niektóre przykłady intensywnego użycia RPC.
Polecając to przydatne narzedzie życzę wszystkim jak najmniejszej liczby problemów z łącznością w Waszych środowiskach.

Błąd który zyskał dzisiaj swojego posta może mieć masę przyczyn. Skupię się na tej, która mnie spotkała po raz kolejny, tak na prawdę tylko dlatego, że wcześniej o niej tu nie napisałem. Postanawiam się poprawić i więcej nie przestawać pisać.
Mianowicie jedną z możliwości powstania tego komunikatu jest nie sam błąd w procesie przetwarzania rpm’a, lecz sama kwestia uruchomienia nowego procesu vpx. Należy jednak nie sugerować się faktem że komenda

wykonuje się poprawnie. Podobnie, nie należy szukać przyczyny wnioskując po poszlace występującej w

.
Problemem jest w tym wypadku niewłaściwy format certyfikatu. Niestety. VMware nie uzna standardowego, powszechnego formatu PEM, takiego jaki „wypluwają” wszystkie urzędy certyfikacji. Żeby ustawić swój własny, dopasowany do istniejącego środowiska certyfikat należy najpierw z formatu PEM skonwertować go do tak zwanej tekstowej reprezentacji PEM:

Szansą na diagnozę tej pomyłki jest interpretacja mało znanego pliku logów

. w Przypadku tego błędu jest tam informacja o niemożności interpetacji pliku z certyfikatem. Należy dodać, że przy diagnozie innych problemów z komunikacją ESX’a z vCenter ten plik logów też może być pomocny.

Popularne polecenie copy robi na pierwszy rzut oka to samo, z tą różnicą, iż nie jest wstanie podołać zadaniu duplikowania katalogów mieszczących się wewnątrz folderu z którego kopiujemy. Aby zaradzić temu problemowi Microsoft wprowadził nowszą wersję copy, nazwaną Xcopy (eXtended Copy). Narzędzie to, obecne w systemie Windows do dzisiaj często pomaga mi w sytuacjach wyglądających na beznadziejne (kiedy graficzne kopiowanie za pomocą przeciągania lub metody „kopiego-pejsta” wykonywane przez explorer.exe rozkłada bezradnie ręce z różnych powodów) ma jednak jedną poważną wadę. Jest nią cytowany w tytule komunikat „insufficient memory” na którym ten użyteczny programik kończy swoje działanie. Błąd ten zgłaszany jest w momencie, gdy kopiowany plik ma ścieżkę bezwzględną ( pełna ścieżka dostępu wraz z literą dysku ) dłuższą niż 254 znaki. A ponieważ dzisiejsze systemy plików obsługują dłuższe ścieżki, ta wada pozornie drobna wada xcopy robi się bardzo istotna.
Rozwiązaniem jest oczywiście znalezienie alternatywnego narzędzia które będzie miało podobną składnię. Pierwszym strzałem było xxcopy które zachowuje się bardzo podobnie, jednak nie identycznie. Jednakże ono też nie jest pozbawione wad. Najważniejszą jest fakt, że aby otrzymać dostęp do części istotnych ficzerów konieczne jest wykupienie licencji. Bliższe informacje można uzyskać na stronie programu.

Narzędziem, które polecam wszystkim (szczęśliwym ) użytkownikom Windows 7 oraz (nie)szczęśliwym użytkownikom Windows Vista ponieważ jest ono dostępne jako składnik systemu operacyjnego, oraz wszystkim innym po ściągnięciu resource kit’a do ich systemów, jest robocopy. narzędzie to, którego nazwa się wzięła od „Robust File Copy”, jest naprawdę potężnym przy wszelkich manipulacjach dużą ilością plików. dobry opis opcji programu znajduje się pod tym adresem w Wikipedii.

Przed chwilą odbyłem z moim przyjacielem TeMPOraLem Dyskusję na temat konwencji odpisywania na wiadomości email, a także o kierunku sortowania danych opatrzonych czasem.

Moim stanowiskiem jest odpowiadanie na górze, a także umieszczanie najświeższych informacji u góry strony/zasobu. Nie przemawia do mnie argument, że książki czytamy z góry na dół, gdyż książki nie są zawartością dynamiczną. Uważam, że sieć jest bardzo elastyczną strukturą, potrzebujemy najważniejsze i najświeższe informacje, a co za tym idzie dostęp do nich powinien być maksymalnie uproszczony.
Historia jest także bardzo ważnym elementem życia onLine, gdyż pozwala jednoznacznie określić ewentualne drobiazgi i przebieg jakiejś aktywności. Jednak jest to tylko w celach dokumentacyjnych. Życie toczy się tak szybko, iż ogarniamy najpilniejsze sprawy. Pamiętamy co było w liście/smsie/rssie godzinę czy dwie temu. Interesuje nas aktualny stan rzeczy dostępny w taki sposób, aby nie musieć się zastanawiać GDZIE on jest. Powinien być, jak mówi jedna Bardzo Ważna dla mnie Osoba „Na Oczach”. Takie ułożenie daje sortowanie malejące względem czasu. Najaktualniejsze dane są na wierzchu.

Argument że wiadomości powinny być posortowane rosnąco względem czasu można jeszcze przyjąć pod dyskusję, gdy ktoś uważa, że zawsze potrzebuje całą informację aby być wstanie przyswoić i zrozumieć aktualną wiadomość. Jednakże poglądu, że powinno się odpowiadać w treści czyjegoś komunikatu „cytując” jedynie, w żaden sposób nie potrafię uzasadnić jako rozsądne. Wyrywa się ułamki wypowiedzi z kontekstu, często bardzo podobnego gdy się dyskutuje niuanse zagadnienia, stąd łatwo o pomyłki w interpretacji. A kiedy konwersację prowadzi więcej osób, to bez zaawansowanego systemu śledzenia cytatów (zagadnienie: kto na co odpowiedział) cała energia czytającego/śledzącego zostaje zmarnowana na dojście do tego, kto jaki pogląd prezentuje.

Na koniec drobne pytanko do wszystkich którzy preferują ułożenie „najnowsze na dole”. Czy swój telefon komórkowy, tudzież klienta poczty elektronicznej przestawili na to, aby sam spis wiadomości był także samo posortowany? Z tego co wiem, wszystkie serwisy webowe obsługujące pocztę pokazują najnowsze wiadmości na górze. Telefony komórkowe tak samo. Readery rss podobnie. Klienty poczty elektronicznej także potwierdzają moją tezę.

To dlaczego na siłę zmieniać od dawna ubite szlaki kosztem szybkości dostępu w imię dziwnej filozofii ?