0

Windows Terminal Services Logon „Access Denied”


Dzisiaj przedstawię rozwiązanie problemu z Usługą Terminalową w środowisku z odrębnym serwerem Licencji Terminalowych.

Symptomy:

  • W trakcie logowania użytkownik otrzymuje komunikat „Access denied.”. Wyświetlany jest on zamiast ekranu logowania po uprzednim komunikacie „Welcome”.
  • W logu aplikacyjnym i systemowym nie występują żadne informacje o błędach, lub są one ewidentnie niezwiązane z podstawowym objawem.
  • W logu TerminalServices-LocalSessionManager występuje następujący wpis skorelowany z próbą logowania użytkownika: „Session X has been disconnected, reason code 12″, gdzie X oznacza numer sesji przydzielony konkretnej próbie logowania.
  • Problem ten dotyka zarówno systemy windows 2008 R2 jak i 2012 (R2).
  • Często towarzyszy tej sytuacji brak możliwości wymuszenia GPO

Tymczasowym rozwiązaniem problemu może być wykonanie dodatkowego wpisu w rejestrze:

1
2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\
IgnoreRegUserConfigErrors (DWORD) = 1

Po dodaniu tego wpisu konieczne jest ponowne uruchomienie komputera.

Po zażegnaniu kryzysu związanego z brakiem możliwości pracy użytkowników na spokojnie można przystąpić do diagnostyki, co się zepsuło tak naprawdę.
W tym konkretnym przypadku przyczyną był błędnie skonfigurowany Firewall na kontrolerach domeny przy użyciu GPO, gdzie był zabroniony ruch „SMB over TCP”.
Przyczyn należy w każdym razie szukać w otoczeniu kontrolerów domeny.

Continue...
0

Failover Cluster Generic Script Resource Failed 0×80070009


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 0×9.
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!

Continue...
1

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ć.
Continue...
0

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.

Continue...
1

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

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.

Continue...
0

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.

Continue...
0

Instalacja Usług Certyfikacji (CA) na Windows 2008 R2 Core


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

1
start /w ocsetup.exe CertificateServices /norestart /quiet

Następnie warto dokonać sprawdzenia poprawności instalacji

1
oclist find /i "CertificateServices"

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

1
/interactive

oraz

1
/iw

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[Version]
Signature="$Windows NT$

[PolicyStatementExtension]
Policies=LegalPolicy

[LegalPolicy]
OID=1.1.1.1.1.1.1.121

NOTICE=Certyfikat wystawiony zgodnie z dokumentem Kodeks_Postepowania_Certyfikacyjnego_Testowe_Domeny
URL="http://pki.testowa.domena.lab/repozytorium/cps.html"

[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=5
RenewalValidityPeriod=years
CRLPeriod=days
CRLPeriodUnits=14
CRLOverlapPeriod=days
CRlOverlapUnits=7
CRLDeltaPeriod=hours
CRLDeltaPeriodUnits=0

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
certutil -setreg CA\DSConfigDN CN=Configuration,DC=CCKNF,DC=AD
certutil -setreg CA\CRLPeriodUnits 14
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 7
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Hours"
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:http://pki.testowa.domena.lab/repozytorium/%%3%%8%%9.crl\n65:file://\\%%1\CertEnroll/%%3%%8%%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:http://pki.testowa.domena.lab/repozytorium/%%1_%%3%%4.crt\n1:file://\\%%1\CertEnroll/%%1_%%3%%4.crt"
certutil -setreg CA\AuditFilter 127
certutil -setreg CA\ValidityPeriodUnits 2
certutil -setreg CA\ValidityPeriod "Years"
net stop certsvc & net start certsvc
certutil -crl

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.

Continue...
2

lenistwo.. Sprawco wszystkiego!


No tak. To prawda. Gdyby nie lenistwo nie było by niczego. Tego sukcesu także. Mój UPS zepsuł się dawno. Tak dawno, że zdążyła mu gwarancja wygasnąć, pomimo, że usterka miała miejsce jeszcze w trakcie jej trwania. Po prostu nie chciało mi się zadzwonić do kuriera, żeby zawiózł urządzenie serwisu na ich koszt. I tak sobie bezużyteczny stał. Nie chciało mi się go do tego serwisu wysyłać, bo wrócił z niego dalej uszkodzony….

Mniejsza z tym. Kiedy dziś mnie lekko zezłościł swoją bezużytecznością, i zajrzałem do karty gwarancyjnej, to wyobraźcie sobie, z jaką ulgą odetchnąłem : „Nareszcie mogę go otworzyć ja”. ;) Po czym zabrałem się do dzieła.

Po otwarciu jakże schludnego i marketingowo nieskazitelnego „opakowania na elektronikę” zdębiałem. Panowie z serwisu producenta faktycznie wymienili akumulator, tak jak w karcie gwarancyjnej stoi, ale nie raczyli już odczyścić płytki z rozlanego elektrolitu. Zabrałem się do sprzątania.

TAK! Sprzątać po serwisantach wewnątrz urządzenia – to jest to, co tygrysy lubią najbardziej :D Aceton, Kwas Solny i te sprawy… W między czasie się okazało, że elektrolit rozpuścił jakieś pięć centymetrów przewodu wewnątrz izolacji – trudno – sztukować też trzeba umieć, gdy się w serwisie pracuje. Potem w ramach emulacji złącza, które się kompletnie rozlazło, dwie zworki zlutowane z przewodami, i GOTOWE.

Tak oto mój UPS został naprawiony.

Ale to nie koniec zabawy. Jak powszechnie wiadomo, tego typu urządzenia są montowane w różnych wersjach: tańszych i droższych. Teraz wystarczy się zorientować, czego nam producent poskąpił na płycie głównej, i mamy wersję extended ;) Dokładnie w ten sposób mój model dorobił się wskaźnika ładowania aku. Teraz jeszcze pozostaje wywiercić otworek w obudowie :D

Tak że czasem strach przed serwisem bywa twórczy. A wybór metody zależy od Ciebie, Drogi Czytelniku.

Continue...