WGUiSW #91

6 czerwca, tradycyjnie w pierwszy wtorek miesiąca, odbyło się spotkanie grupy windowsowej - WGUiSW. Ostatnie spotkanie przed przerwą letnią. Było kilka interesujących tematów, które miałem okazję wysłuchać na żywo. Poniżej przedstawiam krótką relację z tego spotkania - było o edukacji, SQL Serverze, o Active Directory, oraz o SCOMie i Orchestratorze. Było treściwie, ciekawie, z naprawdę dużą porcją wiedzy - każda jedna sesja warta była obecności na sali.

Spotkaniem kierował tym razem Michał Olak. Było sprawnie i płynnie, bez problemów. Innymi słowy: jak zawsze :)

Za kierownicą - Michał Olak

WGUiSW Snack - Damian Płaszczyński prezentuje funkcjonalności wirtualnych labów

Po powitaniu Damian Płaszczyński przedstawił snacka dotyczącego poznawania nowych produktów Microsoft. Dokładniej chodziło o korzystanie z wirtualnych labów. Dotychczas poznając nowe produkty czy też ucząc się do egzaminów certyfikacyjnych korzystałem z MSDNów, TrainingKitów, stron firm trzecich, ale nie z virtual labów. Krótka sesja Damiana przekonała mnie, że warto coś z tym zrobić i przetestować to rozwiązanie, gdzie z użyciem zwirtualizowanego środowiska można krok po kroku poznać daną technologię. To była bardzo cenna sesja.

Michał Sadowski rozpoczyna sesję

Kolejna sesja poprowadzona została gościnnie przez Michała Sadowskiego - Windows vs. SQL Server czyli jak skonfigurować Windows aby SQL Server działał dobrze. Ponieważ dana technologia (SQL Server) nie jest mi obca, natomiast na co dzień jestem jednak bardziej administratorem Windows Server, wysłuchałem sesji z przyjemnością. Generalnie chodziło o zwrócenie uwagi na różne elementy, które z punktu widzenia administratorów serwerów (SA) mogą zostać pominięte jako mało istotne, natomiast z punktu widzenia administratorów baz danych (DBA) mają duże, jeśli nie kluczowe w pewnych kwestiach, znaczenie. Jedną z takich rzeczy jest wybór procesora podczas zakupu serwera. Jest tu kilka aspektów - jednym z nich jest "nowoczesność" kupowanego procesora - tu odsyłam do zapoznania się z modelem Tick-Tock, w skrócie: to, że kupujemy procesor w danej architekturze, nie oznacza, że korzystamy z najnowszej technologii dostępnej dla tej architektury. Inne sprawa dotycząca procesorów, to kwestia wydajności przy kosztach licencjonowania. Generalnie chodzi o to, że koszt lepszego procesora i idący za tym wzrost wydajności (przy tej samej ilości rdzeni, więc i takich samych kosztach licencjonowania) jest mega-korzystny i należy iść w stronę najwyżej wydajnych procesorów - gdyż koszty licencji za jeden core więcej są dużo, dużo wyższe. 

Przykładowe porównanie kosztów i wydajności - droższy procesor vs. tańszy procesor

Inne obszary na które warto zwrócić uwagę to:

• dyski twarde (partycjonowanie i disk alignment), 
• domyślna konfiguracja nie jest najwydajniejszą konfiguracją!,
• wybór właściwego planu zasilania (high performance, inaczej system może wyłączyć core przy niższym obciążeniu),
• instalacja łatek na MS SQL, nie tylko na system (np. Cumulative update n-1),
• instalacja więcej niż jednej instancji - należy podzielić zasoby - wiele usług SQL nie ma świadomości współistnienia innych instancji, a wtedy równolegle uruchomione instancje będą konkurować ze sobą o zasoby; dodatkowo: z praktycznego punktu widzenia instalacja więcej niż 4 lub 5 instancji nie ma sensu, z punktu widzenia wydajności działania SQL.
• ostrożne podejście do wirtualizacji serwerów SQL - zwykle nie działa to zgodnie z oczekiwaniami, jest to niewielka oszczędność pieniędzy, kosztem spadku wydajności, która jest przecież kluczowa w rozwiązaniach serwerów bazodanowych,
• konieczność kompresowania kopii zapasowych - przyspiesza ich wykonanie, ale również odtwarzanie, oszczędza miejsce.

 Podczas sesji mieliśmy okazję poznać mniej techniczne aspekty dotyczące administrowania bazami danych, np. nieoficjalne rozwinięcie skrótu DBA (Default Blame Acceptor).

Mariusz Ferdyn

Po przerwie Mariusz Ferdyn w bardzo zgrabny sposób zaprezentował do czego może doprowadzić nie do końca świadome zarządzanie serwerem (nadmierne uprawnienia dla użytkowników) i brak zainstalowanych aktualnych poprawek (MS16-081). Domyślnie użytkownik może dodać w AD dziesięć maszyn, jednak bez podnoszenia uprawnień możliwe jest dodanie kolejnych maszyn "w imieniu" wcześniej dodanych komputerów.  Idąc tym tokiem działania nie ma więc praktycznych ograniczeń w ilości dodanych komputerów. Wynikają z tego różne rodzaje zagrożeń - o ile przepełnienie bazy AD jest mało realne, to możliwe jest umieszczenie w sieci "bytu" lub kilku, który zagrzebany gdzieś w strukturze AD może pozyskać bardzo konkretny zbiór informacji wyciągniętych z naszej bazy - i może to robić przez długi, długi czas nim zostanie odnaleziony. Bug istniał od około 2000 roku, do połowy 2016! Po raz kolejny pokazuje to jak istotne jest instalowanie aktualnych poprawek. Dodatkowo najlepiej jest zmienić wartość parametru ms-DS-MachineAccountQuota na 0, oraz odebrać zwykłym użytkownikom (Authenticated Users, dla polisy bezpieczeństwa "Add workstation to the Domain") możliwość dodawania kont do domeny. Jak zwykle w przypadku Mariusza, bardzo ciekawa sesja - z przykładami "na żywo".

Jak odpowiednio ustawić i definiować możliwość dodawania komputerów do domeny:

W tym celu należy skorzystać z metody AD Delegaton. Jest to zadanie, które wymaga pewnego nakładu pracy - trzeba przygotować odpowiednie struktury OU, określić role administracyjne, stworzyć Security Groups, oraz określić uprawnienia i audytowanie.

Pierwszy krok to skorzystanie z polecenia redircmp - szczegóły, w celu przekierowania tworzenia nowych komputerów do odpowiedniego OU.

Najprościej skorzystać z Delegation Wizard (kliknąć prawym przyciskiemna odpowiednim OU i wybrać Delegate Control...) lub skorzystać z ACLek bezpośrednio dla danego OU.

• wymagane jest jedno uprawnienie: Create computer object
• można również nadać uprawnienia do innych zadań związanych z obiektami typu komputer:
• Delete computer object,
• Reset Password (obiektu typu Computer),
• Read and write Account Restrictions (włącznie/wyłączanie obiektu typu Computer),
• Validated write to DNS host name, 
• Validated write to service principal name (ustawienie SPN)
• itp., itd. 

Delegacja ignoruje wartości wpisane w parametrze ms-DS-MachineAccountQuot, oddelegowana grupa może dodać praktycznie nieskończoną ilość obiektów.
Warto wspomnieć o grupie Account Operators i przy okazji ostrzec przed korzystaniem z niej - grupa ta posiada znacznie szersze uprawnienia niż jedynie dodawanie komputerów do domeny, dodatkowo posiada uprawnienia do działania na obiektach użytkowników i innych.

Ostatnią sesję w tym półroczu poprowadził nam Łukasz Rutkowski. Jak to zwykle w przypadku Łukasza było "bardzo poważnie", tym razem było prawie "samo mięso", to znaczy prezentacja rozwiązań w środowisku produkcyjnym. W związku z powyższym zostaliśmy poproszeni o nie wykonywanie zdjęć. Więc było o SCOM (niestety, czwarta część serii ma już być tą ostatnią). Znam SCOMa, trochę, bawiłem się kiedyś Orchestratorem, jednak to co było prezentowane zmusiło mnie do pozbierania szczęki z podłogi, gdy już ocknąłem się po sesji. Było bardzo konkretnie i technicznie, a ogrom wykonanej pracy wzbudził ogromny respekt. Orchestrator wykorzystywany był w ponad czterdziestu scenariuszach, które tworzone były przez zespół Łukasza ponad półtora roku! Ze słów prowadzącego sesję - wykorzystywany jest między innymi:

• obsługi monitorowania wygasających haseł,
• monitorowania zestawionych połączeń VPN (site-to-site),
• wdrażania Office365,
• wdrażania środowisk testowych opartych o Azure,
• itp.

Tak więc była to doskonale poprowadzona ostatnia sesja przed letnią przerwą, gdzie wiedza, sposób dzielenia się nią (przystępny, lekki, dowcipny i zrozumiały) oraz treść technicznej prezentacji możliwości wykorzystania rozwiązania którego relatywnie chyba mało osób dotyka.
Generalnie całe ostatnie spotkanie WGUiSW przygotowane było na najwyższym poziomie.