Problem: Masz użytkownika UserA. UserA należy do pewnych grup AD. Jest nowy uytkownik UserB, który docelowo powinien należeć do tych samych grup, co userA. Członkostwo  wpewnych grupach zostało już nadane, a w innych jeszcze nie. Musisz sporządzić listę grup, do których należy userA, a userB nie (i odwrtonie).

Rozwiązanie:

Skorzystamy z modułu ActiveDirectory. Możesz go załadować poleceniem

Import-Module ActiveDirectory

ale jeśli masz powershell 4.0 lub nowszy to pierwsze odwołanie się do polecenia z tego modułu spowoduje jego załadowanie. Potrzebne nam polecenie to Get-ADPrincipalGroupMembership, które pozwoli uzyskać listę grup do których należy wskazany parametrem użytkownik. Ponieważ nie interesuje nas nic więcej niż nazwa grupy, to po pobraniu nazwy użytkownika można po prostu przesłać wynik do polecenia select, które pobierze jedynie właściwość name i awansuje ją do rangi obiektu (służy do tego parametr -Expand).

Podczas porównywania zawartości list z nazwami grup skorzystamy z metody Contains. Contains wywoływane na rzecz listy napisów, sprawdza czy przekazywany argumentem napis jest elementem tej listy. Oto i skrypt: Czytaj dalej »

Jak wiesz w Powershell mamy dostęp do wszystkich funkcji .NET. A zbiór funkcji .NET dotyczący formatowania napisów jest naprawdę olbrzymi! Wystrczy przyjrzeć się dokumentacji funkcji ToString(), która potrafi zrobić napis praktycznie ze wszystkigo. Oczywiście do zbudowania ładnego napisu w powershell nie trzeba znać wszyskich możliwych funkcji. Oto jedn użyteczny przykład:

[string]::Format("Value {0:0.00} and value {1:p}", 1.23, 0.45)

Wywołujemy tutaj fukcję statyczną typu string. Wywołanie buduje się w ten sposób, że do nazwy typu po podwójnym dwukropku dodajesz nazwę funkcji, u nas:

[string]::Format

No i teraz najciekawsze, czyli jak wyglądają argumenty funkcji Format. Czytaj dalej »

Wydawać by się mogło, że konflikt adresów MAC nie powinien się zdarzać… a jednak, życie w IT bywa interesujące. Żeby sprawdzić jakie adresy MAC są wykorzystywane przez 'podejrzane komputery’ można posłużyć się następującym skryptem:

$compList1 = 'Server01','Server02','Server03'

Invoke-Command -ComputerName $compList1 {Get-NetAdapter} | Select MacAddress,PSComputerName,Name

Zaczynamy od zainicjowania listy komputerów. Tutaj została ona podana jawnie:

$compList1 = 'Server01','Server02','Server03'

Teraz na każdym z komputerów, korzystając z remotingu uruchomimy skrypt. Invoke-Command uruchamia zdalne komendy na komputerach wskazanych przez parametr ComputerName. Tą komendą do uruchomienia na każdym komputerze, jest Get-NetAdapter.  Czytaj dalej »

Zdarza się, że mamy w powershellu do czynienia z dwiema listami. Obie mają np. kolumnę ID i obie listy mają inne kolumny, a twoim zadaniem jest połączyć te dwie listy w jedną. Poniższy skrypt realizuje takie zadanie. Najpierw skrypt, a potem komentarz:

$list1 = Get-Process | select Id, Pm 
$list2 = Get-Process | select Id, Name 
$list3= $list1 | % {`
                     $x = $_ ;`
                     $list2 | % {`
                                  if ($_.Id -eq $x.Id) {`
                                     $_ | Select @{L="Handle";E={$x.Id  }},`
                                                 @{L="Name";  E={$_.Name}},`
                                                 @{L="PM";    E={$x.Pm  }}`
                    }}}
$list3

Czytaj dalej »

Te kilka poleceń pozwala mi diagnozować problemy z połączeniem do SQL servera, zwłaszcza w przypadku wystąpienia błędu:

SSPI handshake failed with error code 0x80090311

bardzo pomocne są artykuły

• https://mssqlwiki.com/2013/12/09/sql-server-connectivity-kerberos-authentication-and-sql-server-spn-service-principal-name-for-sql-server/
• https://technet.microsoft.com/en-us/library/ms191153.aspx

z których pochodzą między innymi poniższe komendy.

Do poprawnego skonfigurowania protokołu Kerberos i tym samym uniknięcia w/w błedu potrzebne są tzw. Service Principal Name skonfigurowane dla konta serwisowego SQL Server. Jeśli połączenie do serwera jest nawiązywane z wykorzystaniem NTLM zamiast Kerberos, to najpierw sprawdź, czy SPN dla danego serwera są zarejestrowane. Pomoże w tym komenda:

setspn -L 'domain\user'

Wynik pusty oznacza, że zapomniano o konfiguracji SPN. Jeśli komenda coś wyświetla, to są to definicje SPN. Gdy brakuje SPN, to można je utworzyć wykorzystując poniższe instrukcje:

Setspn -A MSSQLSvc/server.subdomain.domain   domain\user
Setspn -A MSSQLSvc/server.subdomain.domain:1433   domain\user

Oczywiście zamienieamy server, subdomin, domain i user na właściwe.

Kiedy protokół jest już skonfigurowany a anadal podejrzewasz problemy, możesz sprawdzić zawartość ticketa Kerberos korzystając z polecenia Klist:

• Aby sprawdzić ticket dla usługi SQL:

Klist get MSSQLSvc/server.subdomain.domain:1433

• Aby sprawdzić ticket dla hosta:

Klist get Host/server.subdomain.domain

Ta ostatnia komenda zawsze powinna coś zwrócić. Jeżeli nie zwraca, tzn że masz problem na poziomie hosta, a nie usługi SQL.

W dużych środowiskach administrując serwerami nierzadko nie wiesz, czy między serwerami jest zaimplementowany firewall czy nie i ewentualnie, czy przepuszczany jest ruch do SQL servera. W takim przypadku rewelacyjnie pomocny jest program portquery. Można by powiedzieć, że to taki ping, który potrafi sprawdzić, czy osiągalny jest nie tyle cały host, co pewna usługa działająca na tym hoście na określonym porcie. Zakładając, że masz serwer Server01, na którym działa SQL server na porcie 1433, to jeśli chcesz sprawdzić czy ruch na porcie 1433 jest filtrowany czy nie wykonaj polecenie:

portqry.exe -n Server01 -e 1433 -p TCP

Jak widać -e określa badany numer portu, a -p protokół. Jeżeli w wyniku otrzymasz FILTERED, tzn że gdzieś jest jakiś firewall, który sprawił, że host jest niedostępny. Jeżeli masz wynik LISTENING, tzn., że usługa nasłuchuje na tym porcie i przyczyny twoich problemów należy poszukać gdzieś indziej.

Ja zwykle wykonuję 2 testy. Jeden lokalnie z tego komputera, na któym pracuje SQL. Tu otrzymuję zwykle wynik LISTENING i wtedy wiem, że mój SQL ma się dobrze. Potem ten sam test uruchamiam z róznych serwerów zdalnych i jeśli otrzymuję FILTERED, to wiem, że po pomoc należy się udać do sieciowców.

Portquery można pobrać z http://www.microsoft.com/en-us/download/details.aspx?id=24009

Była sobie aplikacja, zaimplementowana na około 30 serwerach. Na niektórych z nich zainstalowano pakiet oprogramowania w wersji X a na innych w wersji Y. Na niektórych z tych serwerów pojawiały się pewne kłopoty, a na innych nie. W każdym razie wygląda na to, że przyczyną tych kłopotów może być zbyt niska wersja tego pakietu. Co robić?

Rozwiązanie numer 1 – otworzyć sesję RDP do każdego z serwerów, na każdym wejść w Dodaj/Usuń programy, poszukać mojego pakietu i… spisać jego wersję. A jak za miesiąc przyjdzie znowu sprawdzić to samo, trzeba będzie otworzyć sesję RDP do każdego z serwerów, na każdym wejść w Dodaj usuń/programy… never ending story…

Rozwiązanie numer 2 – skorzystać z powershella:

Najpierw tworzymy listę komputerów do sprawdzenia. Można ją przechowywać nawet w pliku, tutaj inicjuję ją po prostu w zmiennej:

$computers = "Server01", "Server02", "Server30"

Jest sobie taka klasa WMI o nazwie Win32_Product, kóra prezentuje w sobie zainstalowane na danym systemie oprogramowanie. Aby sprawdzić, czy na komputerze jest zainstalowany dany produkt można  wykonać zapytanie WMI:

Get-WMIObject -Class Win32_Product -filter "Name LIKE '%PDW%'" -ComputerName $c

Czytaj dalej »