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 »

Właśnie zauważyliśmy, że mamy już 600 wpisów na blogu, a ten jest 601! Z tej okazji dzielimy się tym co mamy

1 kupon na kurs Powershell ZA DARMO (!) – po prostu pierwszy lepszy: kupon PIERWSZYLEPSZY

600 kuponów na kurs Powershell w wyjątkowej cenie 10$ – kupon: 601WPIS

Kupon należy wprowadzić podczas zamawiania kursu. Ważność kuponów – do końca marca.

Przy okazji przypominamy, że póki co pierwsza część kursu przygotowującego do egzaminu 70-461 „Querying SQL Server” jest ciągle dostępna za darmo. Kolejne części już niebawem.

Kursy znajdują się na platformie Udemy. Kliknij w tytuł wybranego kursu

Po skopiowaniu bazy SSISDB z jednego serwera na inny pojawił się komunikat o braku Database Master Key (DMK). I słusznie. Na serwerze A DMK jest zaszyfrowany za pomocą Service Master Key (SMK). Ewentualne poufne dane pakietów SSIS w bazie SSISDB są z kolei zaszyfrowane przez DMK. Jeśli baza została przeniesiona na serwer B, to znajdujący się tam SMK nie może być używany do rozszyfrowania DMK, a tym samym traci się dostęp do zaszyfrowanych danych w bazie.

Aby naprawić sytuację, trzeba skopiować DMK z serwera A na serwer B, tak aby zaszyfrował się na serwerze B za pomocą znajdującego się tam SMK. Na serwerze A należy więc wykonać backup key, a na serwerze B restore key. A oto szczegóły:

Najpierw przejdź do omawianej bazy:

USE SSISDB

GO

Zobacz, jakie klucze są aktualnie zdefiniowane (powinien pojawić się Database Master Key)

SELECT * FROM sys.symmetric_keys

Wykonaj kopię klucza:

BACKUP MASTER KEY TO FILE = 'N:\SQLServer\ssisdb_mk.bak'

    ENCRYPTION BY PASSWORD = 'Pa$$w0rd'

A teraz na serwerze docelowym – przejdź do omawianej bazy:

USE SSISDB

GO Czytaj dalej »