poniedziałek, 27 czerwca 2016

Resetowanie licencji Terminal Server 2000/2003

Licencje terminalowe w wersji 2000/2003 są już kompletnie nie dostępne. Nie można więc dokupić, aby zwiększyć ich liczbę. Jeśli na co dzień nie przekraczamy zakupionej liczby, to może się okazać, że reset licencji od czasu do czasu nie powinien nas zbytnio przytłaczać, zwłaszcza, że procedura ta jest dość prosta.

Dlaczego jednak może być konieczność resetowania licencji? Gdy mamy wykupione licencje per device to każdy nowy komputer, który zaloguje się na nasz serwer terminali zajmie jedną licencję. Operacja ta powtarza się z każdym nowym komputer aż do wypełnienia licencji. Gdy wszystkie licencje zostaną rozdysponowane – wtedy nikt z nowym komputer nie dostanie się do serwera terminali (mowa o usługach terminalowych oczywiście!). W tej sytuacji reset licencji bywa niezwykle pomocny, aby proces
przypisywania licencji zacząć od początku.

Oto instrukcja resetu licencji:

  1. Zatrzymujemy serwis odpowiedzialny za licencje terminalowe (net stop TermServLicensing). 
  2. Zmieniamy nazwę %windir%\system32\LServer na %windir%\system32\LServer.old 
  3. Tworzymy nowy katalog %windir%\system32\LServer.
  4. Uruchamiamy ponownie serwis licencyjny (net start TermServLicensing).
  5. Następnie wsprowadź ponownie licencje do serwera.

wtorek, 12 stycznia 2016

Outlook 2010 (problemy)

Tym razem bardzo krótka notka, która ma Wam dać do ręki szybkie rozwiązanie (bez owijania w bawełnę). Chodzi o kolejną nieudaną łatkę do Office, która skutecznie uprzykrza życie z Outlookiem i tym razem mowa o wersji 2010.

Objawy, które odnotowaliśmy:
  • nie trzymanie ustawień, np. okno podglądu po każdym uruchomieniu znika (trzeba je włączyć), lub resetowane są ustawienia podglądu wiadomości do tych domyślnych (co mnie osobiście od razu złości),
  • Outlook lubi uruchamiać się w trybie awaryjnym (nawet bez powiadamiania).

Tym razem winowajcą jest poprawka KB3114409. Jest jak zwykle do odinstalowania z Dodaj Usuń Programy, więc jest łatwo jej się pozbyć. Po odinstalowaniu trzeba będzie zrestartować komputer.

piątek, 18 grudnia 2015

Odzyskiwanie AD w Windows 2008 Server

Odzyskiwanie AD w Windows 2008 Server – czyli Recovery System State. Zadanie to nie jest już takie proste jak to miało miejsce w poprzednich systemach operacyjnych (Windows 2003 Server i starsze). Największa trudność tego zadania polega na uruchomieniu serwera w trybie DSRM (Directory Service Restore Mode). Wynika ona z tego faktu, że standardowo serwer nie jest przygotowany do wejścia w ten tryb – serwer musi być przygotowany.

Przygotowanie serwera do uruchomienia w trybie DSRM polega na dodaniu odpowiedniej opcji startu systemu za pomocą narzędzi BCDEDIT. Wiele źródeł podaje aby modyfikować domyślną opcję bootloadera, ale jest to zabieg co-nieco niebezpieczny i może przynieść nam w niedalekiej przyszłości bardzo wiele niepotrzebnych problemów. Podam więc sposób pozwalający w razie wpadki bez problemu wrócić do standardowego trybu pracy serwera bez dodatkowych, sztucznych zabiegów.

Cały zabieg zaczynamy od uruchomienia polecenia CMD jako administrator. Następnie wykonujemy skopiowanie domyślnej pozycji bootloadera, nadając mu jednak już odpowiednią nazwę:
C:\bcdedit /copy {default} /d "Directory Service Repair Mode"
W wyniku tej operacji otrzymamy komunikat mówiący o powodzeniu wykonania komendy i stworzeniu nowej pozycji bootloadera z nowym, określonym GUID:
The entry was successfully copied to {GUID_wygenerowany_przez_serwer}

Następnie musimy zmodyfikować tę pozycję, aby uruchamiała nam serwer w trybie DSRM:
C:\bcdedit /set { GUID_wygenerowany_przez_serwer} safeboot dsrepair

Teraz mamy podczas startu do wyboru już dwie opcje (pod warunkiem zaznaczenia opcji, aby system czekał na nasz wybór):


Teraz mamy już z górki.
Uruchamiamy serwer w trybie DSRM i po zalogowaniu (będzie potrzebne hasła odzyskiwania AD) z linii komend uruchomionej jako administrator uruchamiamy komendę sprawdzającą jakie mamy dostępne backupy (należy pamiętać, aby je wcześniej dołączyć do serwera!):
C:\wbadmin get versions
W wyniku tego polecenia dostaniemy coś na wzór:


Wybieramy właściwy backup, z którego chcemy odzyskać System State (AD) i wpisujemy polecenie:
C:\wbadmin start systemstaterecovery –version:12/13/2016-17:00
I teraz uzbrajamy się w cierpliwość, jako że odzyskiwanie potrafi trwać ponad godzinę przy bardzo małej AD.

Ten sposób wyzwala tzw. nieautorytatywne odzyskanie AD, więc jest przydatne, gdy mamy tylko jeden kontroler domeny, lub uszkodzony mamy tylko jeden kontroler domeny i chcemy tylko naprawić uszkodzenia zaciągając najświeższe dane z innego kontrolera domeny. Jeśli chcemy odzyskać System State (wraz z AD) w trybie autorytatywnym należy nieco zmodyfikować polecenie odzyskiwania:
C:\wbadmin start systemstaterecovery –version:12/13/2016-17:00 -authsysvol

poniedziałek, 1 czerwca 2015

Problem z dodaniem/usunięciem roli/funkcji w Windows 2008

W serwerze Windows 2008 (także w SBS, R2) zdarzają się bardzo często problemy z dodawaniem lub usuwaniem ról/funkcji. Gdy odpalamy Server Manager to w miejscu informacji dotyczących zainstalowanych ról i funkcji wyświetla się błąd. W pasku stanu można natomiast kliknąć "Pokaż szczegóły błędu". Tam odnajdujemy błąd:
hresult 0x80070543
Przeszukałem wiele zasobów internetowych i większość prowadziła do dwóch rozwiązań:

  • problem z aktualizacjami, który rozwiązuje się z pomocą Microsoft Update Readiness Tool,
  • problem z ustawieniem usług składowych
W moim przypadku ten pierwszy sposób to był niecelny strzał (u mnie aktualizacje chodziły bez zastrzeżeń a narzędzie nie pokazało żadnych problemów). Ten drugi sposób dotyczył mojego przypadku . Problem polega na tym, że Internet donosi o różnych ustawieniach domyślnych usług składowych, dla których będzie to działać poprawnie. 
W moim przypadku zadziałało:
  • uruchamiamy dcomcnfg.exe i przechodzimy do Usługi Składowe -> Komputery -> Mój Komputer,
  • tu wybieramy prawym przyciskiem i Właściwości,
  • przechodzimy do zakładki Właściwości domyślne
  • a tu wybieramy Połącz w Domyślnym poziomie uwierzytelnienia oraz Identyfikuj w Domyślnym poziomie personifikacji.
Powinno zacząć działać bez restartu. 
Warto tu jeszcze wspomnieć o tym, że zmiana tych ustawień, może mieć pewien wpływ na inne zainstalowane na serwerze aplikacje. Po zmianie należy więc przeprowadzić pełne procedury testowe. 

piątek, 19 grudnia 2014

Defragmentacja indeksów MS SQL

Fragmentacja indeksów w MS SQL jest dość ważnym problemem wydajnościowym baz danych. Utrzymanie tychże indeksów w dobrej kondycji staje się więc bardzo ważnym zadaniem administratora baz danych.
Kto powinien i kiedy defragmentować indeksy? Warto zacząć od sprawdzenia fragmentacji indeksów. Poniżej jest kod pozwalający na weryfikację fragmentacji zewnętrznej i wewnętrznej:

SELECT OBJECT_NAME(dt.object_id), si.name, dt.avg_fragmentation_in_percent, dt.avg_page_space_used_in_percent
FROM (SELECT OBJECT_ID, index_id, avg_fragmentation_in_percent, avg_page_space_used_in_percent FROM sys.dm_db_index_physical_stats (DB_ID(N'BAZA_DANYCH'), NULL, NULL, NULL, 'DETAILED') WHERE index_id <> 0) as dt
INNER JOIN sys.indexes si
ON si.object_id = dt.object_id
AND si.index_id = dt.index_id

Kolumna avg_fragmentation_in_percent mówi nam o fragmentacji zewnętrznej. Wartości powyżej 10 procent wskazuje na fragmentację (warto już coś zadziałać). Kolumna avg_page_space_used_in_percent mówi natomiast o fragmentacji wewnętrznej indeksu. Wartość poniżej 75% wskazuje na problem.

Jeżeli powyższe zapytanie kończy się błędem:
Incorrect syntax near '('

To oznacza, że nasza baza danych pracuje w "compatibility level 80 (SQL Server 2000)". Należy podnieść ten poziom i wtedy zapytanie działa jak należy.Jeżeli natomiast nie ma możliwości (z różnych powodów) podniesienia poziomu funkcjonalności należy zacząć od zdefiniowania zmiennych. Oto przykład takiego zapytania:
USE BAZA_DANYCH
GO
DECLARE
    @database_id INT = DB_ID(),
    @object_id INT = OBJECT_ID(N'BAZA_DANYCH')
SELECT a.index_id, name, avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (@database_id ,@object_id , NULL, NULL, NULL) AS a JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id
GO

Do fragmentacji indeksów otrzymujemy dwa polecenia: ALTER INDEX...REORGANIZE oraz ALTER INDEX...REBUILD. Pierwszą z nich używamy, gdy problem fragmentacji jest nie wielki. REORGANIZE dodatkowo zużywa mniej zasobów i może zostać wykonana on-line. 
Mocno pofragmentowane indeksy powinno się przebudować (REBUILD). Należy pamiętać, że domyślnie powinno się to wykonywać, gdy baza danych nie jest wykorzystywana. Jest tu także opcja uruchomienia tego zadania w "locie" przy pomocy określenia dodatkowej opcji ONLINE, jednak REBUILD przebudowuje indeksy od samego początku, więc jest to zadanie dość czasochłonne i zasobożerne. 

Polecenia stosuje się bardzo prosto. Aby przebudować wszystkie indeksy w danej tabeli wpisujemy polecenie: 
ALTER INDEX ALL ON nazwa_tabeli REBUILD
ALTER INDEX ALL ON nazwa_tabeli REORGANIZE 

Aby przebudować wszystkie indeksy we wszystkich tabelach danej bazy danych kod mamy już nieco dłuższy:
USE  [Baza_danych]
GO
DECLARE @TableName VARCHAR(255)
DECLARE @sql NVARCHAR(500)
DECLARE TableCursor CURSOR FOR
SELECT OBJECT_SCHEMA_NAME([object_id])+'.'+name AS TableName
FROM sys.tables
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'ALTER INDEX ALL ON ' + @TableName + ' REBUILD'
EXEC (@sql)
FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor
GO

Skrypt ten przebuduje wszystkie indeksy nie zmieniając wskaźnika wypełnienia stron indeksu (fill factor). Aby przebudować z nowym wskaźnikiem wypełnienia dodajemy do kodu małe zmiany:
USE [Baza_danych]
DECLARE @TableName VARCHAR(255)
DECLARE @sql NVARCHAR(500)
DECLARE @fillfactor INT
SET @fillfactor = 90
DECLARE TableCursor CURSOR FOR
SELECT OBJECT_SCHEMA_NAME([object_id])+'.'+name AS TableName
FROM sys.tables
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'ALTER INDEX ALL ON ' + @TableName + ' REBUILD WITH (FILLFACTOR = ' + CONVERT(VARCHAR(3),@fillfactor) + ')'
EXEC (@sql)
FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor
GO

Idąc już tą drogą pozostaje podać jeszcze skrypt reorganizacji wszystkich indeksów bazy danych:
USE [Baza_danych]
DECLARE @TableName VARCHAR(255)
DECLARE @sql NVARCHAR(500)
DECLARE TableCursor CURSOR FOR
SELECT OBJECT_SCHEMA_NAME([object_id])+'.'+name AS TableName
FROM sys.tables
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'ALTER INDEX ALL ON ' + @TableName + ' REORGANIZE'
EXEC (@sql)
FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor
GO
To wszystko może wyglądać dość skomplikowanie. Przypomnę więc dla tych bardziej początkujących, że defragmentacje można przeprowadzić również poprzez MaintenancePlan, używając klocków Reorganize Index Task lub Rebuild Index Task

Odblokowanie xp_cmdshell

Niektóre narzędzia potrzebują rozszerzonego dostępu do MS SQL. Najczęściej są to narzędzia optymalizacji baz danych (defragmentacja, odbudowanie indeksów, backup, itp.). Od MS SQL 2008 podniesiono poziom zabezpieczeń nie pozwalając poprawnie działać tym programom. Wynika to z zablokowania fukcji sys.xp_cmdshell. Próba uruchomienia tych narzędzi najczęściej kończy się takim komunikatem:
SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'xp_cmdshell' by using sp_configure. For more information about enabling 'xp_cmdshell', see "Surface Area Configuration" in SQL Server Books Online.

Aby odblokować tę funkcjonalność należy wykonać poniższy kod:
EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC sp_configure 'xp_cmdshell', 1
GO
RECONFIGURE
GO

środa, 29 października 2014

MS SQL Management Studio 2005 Error 29506

Doinstalowanie SQL Management Studio 2005 nie musi być łatwe. Nie musi nawet być intuicyjne. Oto przykład:
Gdy napotkasz błąd instalacji nr 29506 należy zrobić co następuje:
- zakończyć bieżącą instalację,
- uruchomić linie poleceń jako Administrator,
- uruchomić plik instalacyjny z linii komend.

Problem dotyczy przede wszystkim systemów Windows 7 i Vista.


piątek, 24 października 2014

Kerio Connect i konfiguracja HTTPS

Zdemolowany i pobity SSL 3.0 (o istotności tego problemu piszemy tutaj: http://blog.plik.pl/2014/10/wotum-nieufnosci-dla-ssl-30-przyjete.html) wprowadził wiele zamieszania w środowisku informatycznych nie tylko od strony klientów (przeglądarki internetowe) ale także od strony serwerów, gdzie należało zablokować możliwość nawiązywania komunikacji po w/w protokole. Przy tej okazji jednak okazało się, że blokada SSL 3.0 (i SSL 2.0 z domysłu) powoduje, że część serwerów dogaduje się z przeglądarkami po równie „niezdrowym” protokole TLS 1.0. Niestety o tym wspomina się już z rzadka – a szkoda. W tym artykule chciałbym skupić się wyłącznie na rekonfiguracji Kerio Connect, jako że nawet producent przedstawił niepełną instrukcję, koncentrując się wyłącznie na SSL 3.0.

Instrukcja zablokowania skompromitowanych protokołów w Kerio Connect:

  1. Zatrzymaj serwis serwera pocztowego Kerio Connect. 
  2. Odnajdź plik konfiguracyjny mailserver.cfg i otworz go do edycji. 
  3. Upewnij się że SSL 2.0 jest zablokowany: 
<variable name="DisableSSLv2">1</variable>
  1. Zablokuj protokół SSL 3.0: 
<variable name="DisableSSLv3">1</variable>
  1. Zablokuj protokół TLS 1.0:
<variable name="DisableTLSv1">1</variable>

Wotum nieufności dla SSL 3.0 przyjęte!

Po osiemnastu latach protokół SSL 3.0 idzie na emeryturę. Niestety nie jest to odejście klasycznego emeryta lecz raczej polityka – z wielkim hukiem i w dźwiękach wielkiego skandalu. Oto ogłoszono w zeszłym tygodniu, że atak nazwany pieszczotliwie POODLE, pozwala na przechwycenie ciasteczek, które używane są do logowania w serwisach internetowych. Problem więc dotknął wszystkich i wszystkiego. Od tygodnia trwają gorączkowe prace mające na celu rezygnację z tego protokołu od strony serwerów świadczących usługi jak i od strony klientów (przeglądarek), gdzie blokujemy możliwość korzystania ze skompromitowanego protokołu SSL 3.0.

Niestety mówi się o tym bardzo mało – zdecydowanie za mało. Media uznawane za powszechne nie wspomniały o tym (sam nie oglądam, ale odpytałem znajomych – nikt nie wychwycił takiego newsa). Prasa informatyczna wspomina o tym raczej jak o ciekawostce typu „a dziś w zoo urodził się nowy mieszkaniec…”. Ci, którzy coś napiszą z rzadka wymieniają też inne protokoły, które cieszą się podobną sławą: SSL 2.0, TLS 1.0 oraz obecnie mniej znany PCT 1.0.

Wszystko szkoda, nie dobrze i źle!

Jak doszło do złamania protokołu, na czym to polega to przeczytacie  w wielu artykułach w Internecie. Mało który artykuł jednak dotyka konsekwencji skompromitowania SSL 3.0. I to jest to miejsce w którym chciałbym poświęcić kilka minut na kilka przykładów, które mam nadzieję, pozwolą puścić wodze wyobraźni.

Po pierwsze Windows XP MUSI w końcu przejść do lamusa. Kochamy go całym sercem (i chyba nie tylko sercem), nie możemy się z nim rozstać, Microsoft już dawno temu zakończył wsparcie dla tego systemu a my ciągle i uparcie przy nim tkwimy. W gruncie rzeczy nie dziwię się, że przyzwyczajono nas, że jak coś działa to po co psuć? Teraz jednak jeśli chcemy bezpiecznie pracować na komputerze to czas zapomnieć o Windows XP. Internet Explorer, który w wielu przypadkach jest wprost wymagany do otwierania niektórych witryn/aplikacji, nie ma możliwości ustawienia protokołów TLS 1.1 i TLS 1.2. Słowem nie można w Windows XP bezpiecznie nawiązać połączenie szyfrowanego (https). Można się wprawdzie wspomóc inną przeglądarką, ale faktem jest, że nie wszystko na nich zadziała.
(o tym jak wyłączyć skompromitowane protokoły w przeglądarkach piszemy tu: http://blog.plik.pl/2014/10/wyaczenie-ssl-30-oraz-tls-10-w.html )

Po drugie. Ciągle jest bardzo dużo serwisów (zwłaszcza w strefie biznesu), gdzie witryny obsługują wyłącznie SSL 3.0. Stąd też po rekonfiguracji przeglądarek (aby nie łączyły się po trefnych protokołach) okazuje się, że firmy nie mogą realizować swoich zadań/obowiązków biznesowych. W większości przypadków jesteśmy zmuszenie wrócić do obsługi SSL 3.0 wystawiając się tym samym na skuteczne ataki hackerów. Błędne koło. Szczęśliwie instytucje finansowe błyskawicznie zrezygnowały z obsługi złamanych protokołów. Co jednak z pozostałymi? Wiele wskazuje na to, że jeszcze trochę poczekamy na poprawę.
Co zrobić w takiej sytuacji? Wiele nam nie pozostaje. Ja sugerują ustawić obsługę SSL 3.0 tylko w jednej z przeglądarek i korzystać z niej tylko wtedy, gdy nas do tego zmuszą. Zdecydowanie jednak zalecam dobrze rozważyć słowo „zmuszą” – może jednak nie musimy korzystać z usług firm, które nie nadążają za biegiem teraźniejszości? Może jest to odpowiedni moment weryfikacji naszych współpracujących z nami parnerów?

Po trzecie. Tu właściwie możemy otworzyć cały worek konsekwencji związanych z przejęciem naszego konta na serwerze usługi. W przypadku instytucji bankowych będą to wymierne straty pieniężne. W przypadku sklepów internetowych, gdzie mamy ustawione automatyczne płacenie (a są takie!), straty pieniężne. W przypadku kont społecznościowych, spore problemy z utrzymaniem naszego wizerunku jak i bezpieczeństwa osobistego i rodzinnego, itp. itd…


Przykładów można mnożyć w nieskończoność. Na co dzień niestety staramy się o tym nie myśleć, poklepując siebie po plecach i mówiąc „jakoś to będzie”. Zagrożenie jest jednak wyraźne i realne. Warto poświęcić kilka minut na to aby jednak przemyśleć to jeszcze raz i może zastosować się do nowych realiów powszechnie dostępnego Internetu?

Tu możesz sprawdzić czy Twoja przeglądarka jest podatna na atak POODLE: https://www.poodletest.com/

Problem aktualizacji KB2949927

Dnia 16.10.2014 wyszła poprawka Microsoftu, która dodała informatykom troszkę dodatkowej roboty. Mowa o zwalonej (nie bójmy się tego słowa) aktualizacji oznaczonej KB2949927. Poprawka ta uszkodziła procedury hashowania SHA-2, sprawiając, że niektóre podsystemy przestają poprawnie funkcjonować. Błąd poprawki dotknął systemy Windows 2008 R2 Server oraz Windows 7.

Przykład:
Serwer pocztowy Kerio Connect zainstalowany na Windows 2008 R2 64-bit. Kerio połączony jest z AD, aby autoryzować użytkowników. Przy tej komunikacji jest wykorzystywany m.in. SHA-2. Po instalacji aktualizacji KB2949927 serwer nie potrafi poprawnie autoryzować użytkowników. Autoryzacje odbywają się raz na 7-10 razy lub zgłasza błąd ale pobiera pocztę (choć załączników już nie chce). Generalnie spory bałagan.
Poprawkę tę Microsoft po kilku dniach zablokował i jeśli ktoś instaluje aktualizacje z opóźnieniem (a jest to bardzo dobra metoda) to nie spotka się z tym problemem.

Jak odinstalować:
Na początku upewnijmy się, że łatka została zainstalowana szukając jej w „Historii zainstalowanych aktualizacji” (krok w gruncie rzeczy nie jest konieczny, ale pozwala zweryfikować, czy problemy które doświadczamy dotyczą właśnie tego problemu).
Aktualizacji tej nie zobaczymy w „Dodaj/usuń programy” więc należy odinstalować ją używając commandline’a:
Wusa /uninstall /KB:2949927

Po zakończeniu procesu deinstalacji system należy zrestartować.