Failover Cluster Generic Script Resource Failed 0x80070009

Witajcie,

Dzisiaj chciałbym się podzielić spostrzeżeniem mocno nieintuicyjnego zachowania funkcjonalności Failover Clustering w Windows 2012 R2.
Mianowicie, może się zdarzyć, że po przygotowaniu skryptu kontrolującego zachowanie aplikacji (Generic Script), której chcemy zapewnić wysoką dostępność i po konfiguracji zgodnie z tym blogiem Zespołu produktowego Microsoft zasób klastra nie zostanie uruchomiony, a status zasobu będzie zawierał informację

1
The storage control block is invalid.

Przedstawia to poniższy zrzut ekranowy:
Status zasobu klastrowego
Kiedy zgodnie z sugestią z komunikatu o błędzie wyświetlimy rozszerzoną informację o błędzie uzyskamy informację o kodzie błędu

1
0x80070009

Rozszerzona informacja o błędzie
Podobny wpis zostanie odłożony w logu systemowym klastra:
Log systemowy klastra

W takiej sytuacji należy przede wszystkim się upewnić, że przygotowany przez nas skrypt nie zwraca z żadnego wywołania API wartości 0x9.
Gdy posiadamy taką pewność, to błąd ten oznacza, że skrypt Visual Basic ma niepoprawną składnię i menedżer zasobów klastra nie był w stanie prawidłowo go skompilować.
Dlatego dobrą praktyką jest przed utworzeniem zasobu klastrowego weryfikacja poprawności kompilacji skryptu. W tym celu należy wydać polecenie z linii poleceń:

1
cscript.exe C:\pełna\ścieżka\do\pliku.vbs

Ponieważ skrypt zawierać powinien same definicje funkcji, a nie ma żadnych ich wywołań (cecha charakterystyczna wywołań zwrotnych – „CallBack”), to prawidłowo napisany skrypt nie powinien nic wykonać ani wyświetlić.
W przypadku nieprawidłowej walidacji wynik będzie podobny do poniższego zrzutu ekranu:
Błąd walidacji skryptu

Pozdrawiam serdecznie i życzę samych poprawnych skryptów!

Generowanie Żądania certyfikatu z openssl dla Microsoft Enterprise CA

Dawno temu pisałem o tym, jak wygenerować żądanie certyfikatu dla systemów nie będących Windowsami tak, aby dało się certyfikat wystawić na Microsoft Enterprise CA. Jako przykład podałem generowanie certyfikatów serwera vCenter
Niedawno temat powrócił, ale w nowej odsłonie, gdyż serwer vSphere wymaga zdefiniowania w certyfikacie odpowiednich Nazw Alternatywnych. Powstało pytanie, jak pogodzić te dwie funkcjonalności.
Okazuje się to być całkiem proste, trzeba tylko pamiętać, że choć plik konfiguracji openssl pozwala na wiele sekcji opisujących rozszerzenia żądania certyfikatu, to tylko jedna z nich może być wykorzystywana w trakcie generowania certyfikatu. Dlatego przygotowując plik konfiguracyjny dla określonego serwera warto uporządkować jego strukturę, względem propozycji przedstawionej w poprzednim wpisie.
Przykładowy plik konfiguracyjny może wyglądać następująco:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
openssl_conf = openssl_init

[ openssl_init ]
oid_section = new_oids

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ new_oids ]
MsCaCertificateTemplate = 1.3.6.1.4.1.311.20.2

[ v3_req ]
basicContraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:server01, DNS:server01.domena.test
MsCaCertificateTemplate = ASN1:PRINTABLESTRING:VMwareCertificate

[ req_distinguished_name ]
countrName = PL
stateOrProvinceName = Malopolskie
localityName = Krakow
0.organizationName = Firma
organizationalUnitName = Oddzial
commonName = server01.domena.test

Analizując najważniejsze części:

  • Linia 1. Wskazuje na sekcję będącą konfiguracją globalną.
  • Linia 4. Wskazuje na sekcję defniującą OIDy. Linia ta jest jedyną w sekcji konfiguracji globalnej
  • Linia 13. Wskazuje na sekcję definiującą rozszerzenia, które zostaną dodane do żądania certyfikatu
  • Linia 15. Definiuje sekcję z OIDami.
  • Linia 16. Definiuje OID zarejestrowany i użytkowany przez Microsoft do oznaczania rozszerzenia definiującego szablon certyfikatu
  • Linia 22. Definiuje alternatywne nazwy serwera. Należy zwrócić uwagę na fakt, że w przykładzie używany jest prefiks DNS: Możliwe są także inne prefiksy.
  • Linia 23. Definiuje nazwę używanego szablonu certyfikatów. Należy zwrócić uwagę, że wykorzystywany jest wariant nazwy bez żadnych spacji. Nazywa się on „Certificate Template Name”, w przeciwieństwie do nazwy przyjaznej, nazywającej się „Certificate Template Display Name”

Pozostała cześć jest standardowa dla każdego żądania obsługiwanego przez openssl.

Błąd Orchestrator 2012 R2 REST OIP: HTTP Version should be either 1.0 or 1.1

Dzisiaj szybka diagnostyka problemu przedstawionego w tytule postu.
Rozważamy następujący scenariusz:

  1. Orchestrator 2012 R2 zainstalowany na serwerze Windows 2012 R2
  2. Zaimportowany Integration Pack dla REST
  3. Skonfigurowane ustawienia regionalne które zakładają separator dziesiętny inny niż kropka (’.’)
  4. W parametrach akcji „Invoke Rest Service” jest wprowadzona zgodna z dokumentacją wartość ciągu „1.0” lub „1.1”

W Polsce, mamy Z scenariuszem takim mamy do czynienia zazwyczaj , gdzie zwyczajowym separatorem dziesiętnym jest przecinek.
I to właśnie on jest powodem powstania problemu, w przypadku gdy jesteśmy pewni że ostatni punkt scenariusza został zrealizowany prawidłowo.
Wewnątrz implementacji tej akcji znajduje się odpowiednik następującego kodu (tutaj przytaczam powershell, aby łatwo było potwierdzić diagnozę):

1
2
3
4
5
6
7
$result = 0;
$HTTPVersion = "1.1"
$status = [float]::TryDecode($HTTPVersion, [ref]$result);
if(($status -ne $true) -or ($HTTPVersion -ne "1.0") -or ($HTTPVersion -ne "1.1"))
{
"Return Error: HTTP Version should be either 1.0 or 1.1";
}

W sytuacji, gdy w ustawieniach regionalnych separator dziesiętny nie jest ustawiony na znak '.' to w linii numer 3 zostanie ustawione $status == $false.
Rozwiązaniem jest ustawić klucz rejestru HKU\SID\Control Panel\International\sDecimal
oraz HKU\SID\Control Panel\International\sMonDecimalSep dla użytkownika o wartości SID na znak

1
'.'

Na koniec należy zrestartować usługę orchestratora, a problem zostanie rozwiązany.

Po raz pierwszy opisałem temat odpowiadając na pytanie rosyjskojęzycznej osoby z technet’u.

Jak zdalnie wywołać opublikowane zadanie na kliencie SCCM 2012

Witajcie,

W sieci można znaleźć wiele pytań o zdalne wywoływanie akcji klienta SCCM poprzez skrypty.
W oficjalnym SDK do SCCM 2012 nie ma absolutnie nic na temat takiej możliwości. W wersji do SCCM 2007 jest przykład skryptu wykonywanego lokalnie, wywołującego obiekty klas COM CPAppletMgr oraz UIResourceMgr. Niestety, konfiguracja DCOM, która umożliwiałaby zdalne użycie tych obiektów jest conajmniej uciążliwa, a przy okazji bezużyteczna na dłuższą metę, gdyż niedorzecznym była by wiara, że klasy te (a w szczególności GUID’y) nie zmienią się w przyszłości.
Bardziej naturalną formą integracji z SCCM’em jest wykonywanie wywołań WMI.
I tutaj znowu Microsoft podłożył wszystkim autorom skryptów kukułcze jajo – w SDK do wersji 2012 jest jedynie suchy opis klas WMI dostępnych w kliencie i serwerze, jednakże brakuje jakichkolwiek wskazówek dotyczących ich używania.
Po dłuższych poszukiwaniach odnalazłem fantastyczne narzędzie: SMSCLICTR, które zbiera wszystkie możliwe ustawienia i wywołania w proste do użycia biblioteki .NET. Mogą być one wykorzystane także w powershell’u, jednakże często użycie zewnętrznych typów danych w PS jest zabronione przez polityki bezpieczeństwa systemu.
Ostatecznie nie pozostało nic innego, jak utworzenie własnego kawałka kodu, który będzie wykonywał wymagane akcje.

  1. Po pierwsze, konieczne jest wywołanie odświeżenia polityk klienta SCCM. Może to zostać wykonane przez poniższą funkcję:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    function ForceMachinePolicyRefresh
    {
    param($clientname, $username, $userpass, $PolicyID)
    $ms = new-object system.management.managementscope
    $ms.Path = "\\$clientname\root\CCM"
    $ms.options.username = $username
    $ms.options.password = $userpass
    $mc = new-object system.management.managementclass($ms, 'SMS_Client', $null)
    $mc.invokeMethod("TriggerSchedule", $PolicyID)
    return $mc
    }

    Parę uwag do powyższego kodu:

    • Połączenie do przestrzeni nazw WMI następuje w formie bezpośredniej, bez użycia rzutowania, dostępnego w powershell na klasę [wmi], z powodu konieczności przekazania poświadczeń. Kod ten może wywoływać WMI zdalnie, dzięki zastosowaniu $ms.options.username które wspierane jest tylko w przypadku zdalnych połączeń.
    • Jest to ogólna funkcja umożliwiająca wymuszenie wywołania dowolnej harmonogramowej akcji. Tak więc może zostać użyta nie tylko do odświeżania polityki komputera, ale także do zastosowania ustawień konfiguracji lokalnej, co zostanie pokazane za moment.
    • Ostatnią rzeczą, dotyczącą tego małego kawałka kodu jest fakt, iż może zostać użyty jako szablon do manipulacji dowolnymi właściwościami i metodami opublikowanymi przez klasę WMI SMS_Client. Dopiero teraz SDK może się okazać pomocne.
  2. Tak więc mając zdefiniowaną tę procedurę pomocniczą możemy przejść do sedna sprawy. Poniższa funkcja służy do uruchomienia wymuszonej publikacji podanego w argumencie pakietu lub aplikacji. Funkcja pobiera wszystkie wymagane argumenty, tak że jest zupełnie niezależna od kontekstu, w którym jest wykonywana:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    function InvokeOptionalAdvertisement
    {
    Param($clientname, $username, $userpass, $advertID, $packID)
    $mc = ForceMachinePolicyRefresh -clientname $clientname -username $username -userpass $userpass -PolicyID "{00000000-0000-0000-0000-000000000021}"
    $ms = new-object system.management.managementscope
    $ms.path = "\\$clientname\root\ccm\policy\Machine\ActualConfig"
    $ms.options.username = $username
    $ms.options.userpass = $userpass
    $query =new-object System.Management.ObjectQuery
    $query.QueryString = "Select * From CCM_SoftwareDistribution where ADV_AdvertisementID = '$advertID' and PKG_PackageID = '$packID'"
    $searcher = new-object system.management.managementobjectsearcher($query)
    $searcher.Scope = $ms
    $advs = $searcher.Get
    $enum = $advs.GetEnumerator()
    $enum.MoveNext()
    $adv = $enum.Current
    $adv.SetPropertyValue("ADV_RepeatRunBehavior", "RerunAlways")
    $adv.SetPropertyValue("ADV_MandatoryAssignments", "True")
    $adv.Put()
    $query1 = new-object System.Management.ObjectQuery
    $query1.QueryString = "Select ScheduledMessageID FROM CCM_Scheduler_ScheduledMessageID like '" + $adv.ADV_AdvertisementID + "-" + $adv.PKG_PackageID + "%'"
    $searcher1 = new-object System.management.managementobjectsearcher($query1)
    $searcher1.scope = $ms
    $scheds = $searcher1.Get()
    $scheds | Foreach-Object { $mc[1].invokeMethod("TriggerSchedule", $_.ScheduledMessageID) }
    return $adv
    }

    No i oczywiście słowo komentarza do powyższego kodu:

    • Na początku wywołujemy odświeżenie polityki komputera, aby mieć pewność, że pracujemy na aktualnych danych publikacji pobranych z SCCMa. Tę akcję wykonujemy przy użyciu naszej pomocniczej procedury.
    • Następnie definiujemy nowy kontekst zarządzania WMI obejmujący aktualnie załadowaną konfigurację klienta SCCM.
    • Kolejno, tworzymy instację klasy ObjectQuery, która reprezentować będzie zapytanie WMI. To zapytanie pobiera z przestrzeni wszystkie obiekty klasy CCM_SoftwareDistributionktóre pasują do przekazanych wymagań.
    • Poprzez wywołanie metody $searcher.Get umieszczamy w zmiennej $advs wszystkie obiekty będące wynikiem zapytania.
    • Dzięki użyciu sztuczki z pobraniem enumeratora i jego właściwości $enum.Current otrzymujemy tylko pojedynczy obiekt, zamiast kolekcji zawierającej ten obiekt.
    • Teraz pora na wykonanie głównego zadania. Modyfikowane są dwie właściwości obranego obiektu, co powoduje, że zamiast opcjonalnej publikacji, na tym konkretnym kliencie staje się ona obowiązkowa i zostanie wykonana przy następnym wywołaniu harmonogramu tej publikacji.
    • Ostatnia część skryptu listuje wszystkie zarejestrowane w systemie obiekty harmonogramu i wymusza ich uruchomienie. To powoduje także wywołanie akcji harmonogramu dla naszej publikacji, którą chcemy wymusić.

Błąd „The AD RMS installation could not determine the certificate hierarchy.” podczas reinstalacji AD RMS

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.

Microsoft Enterprise CA nie zezwala na publikację szablonów V2 i V3

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.
Okno Publikacji szablonu
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:

1
certutil -setreg ca\setupstatus +512

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

1
certificateTemplates

w obiekcie

1
pKIEntrollmentService

Obiekty te znajdują się w ścieżce

1
CN=Internal Issuing CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contonso,DC=lab

Instalacja Service Pack 1 dla Windows 2008 R2 poprzez MDT 2010 U1

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

1
aplikacja.exe /?

albo

1
aplikacja.exe /help

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:
Okno Dialogowe z pomocą dla linii komend instalatora SP1 dla Windows 2008 R2
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:

1
 windows6.1-KB976932-X64.exe /extract

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.

Konfiguracja DHCP w Windows 2008 R2 Core

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

1
 netdom <nazwa obecna> renamecomputer /newName:<nowa nazwa>

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

1
 hostname

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ę:

1
2
3
4
5
6
netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  3          10        1500  connected     Local Area Connection
  1          50  4294967295  connected     Loopback Pseudo-Interface 1

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

1
netsh interface ipv4 set address name=<Idx> source=static address=<IP> mask=<netmask> gateway=<Domyślna brama>

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

1
netsh interface ipv4 add dnsservers [name=]<string> [address=]<IPv4 address> [[index=]<integer>] [[validate=]yes|no]

Aktywacji dokonujemy poprzez dwie komendy:

1
2
slmgr.vbs -ipk <klucz produktu>
slmgr.vbs -ato

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

1
Dism /online /enable-feature /featurename:DHCPServerCore

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:

1
2
sc config dhcp start=auto
sc start dhcp

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:

1
netdom join <nazwaHosta> /Domain:<FQDN> /UserD:Username /passwordd:*

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

1
 sconfig

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.

VMware ESX – failed to install Virtual Center Agent

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

1
 service vmware-vpxa restart

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

1
 /var/log/messages

.
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:

1
 openssl x509 -text -in /etc/vmware/ssl/rui.crt -out /etc/vmware/ssl/rui.crt

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

1
 /var/log/vmware/vpxa.log

. 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.

Xcopy – „insufficient memory”

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.