Na serwerze była sobie usługa działająca na koncie local system. Zgodnie z zaleceniami należało ją przełączyć tak, aby pracowała na pewnym koncie domenowym. Prosta sprawa. Wystarczy otworzyć services.msc, odszukać usługi i na zakładce LogOn zmienić konto wykorzystywane przez usługę.

Niestety pech chciał, że to konto nie posiadało odpowiednich uprwanień i po próbie uruchomienia usługa próbowała wystartować, ale się jej to nie udalo. W dzienniku zdarzeń można było znaleć informację o brakujących upranieniach. Niby żaden problem. Uprawnienia zostały nadane i wystarczy ponownie uruchomić usługę, żeby wszystko działało, ale co to? Usługi nie można już zatrzymać ani uruchomić, bo jej status to starting!

Co zrobić? Po prostu zabić proces tej usługi. Ale najpierw trzeba znać jaki to numer procesu:

gwmi win32_service | where {$_.name -like "*service name*" }

w wyniku można odczytać numer procesu, a potem go zabić:

Stop-Process <process_id>

Usługa od razu zmieniła status na stopped, co pozwoliło uruchomić ją ponownie.

Aktualizacje w Windows 10 są domyślnie włączone i nie zaleca się zmieniania tego parametru. Zawsze jednak istnieje możliwość samodzielnego sprawdzenia dostępnych aktualizacji i ich pobrania i zainstalowania. W tym celu kliknij Start >> Wybierz Ustawienia >> Aktualizacje i zabezpieczenia >> Windows Update.

Znajduje się tam przycisk pozwalający uruchomić sprawdzenie dostępnych dla komputera aktualizacji. Czasem jednak zdarza sie tak, że program „kręci i kręci” i nie może znaleźć aktualizacji. Co można zrobić:

1. Wejdź do Panelu sterowania. Uruchom Narzędzie do rozwiązywania problemów i wybierz „Rozwiąż problemy z usługą windows update”
2. Sprawdź czy uruchomiona jest usługa Windows Update
3. Wejdź w ustawienia karty sieciowej Start >> Ustawienia >> Sieć i Internet >> Opcje zaawansowane i zobacz czy połączenie sieciowe ma wyłączone ustawienie „Ustaw jako połączenie taryfowe”
4. Jako jedno z ostatnich rozwiazań. Zatrzymaj usługę Windows Update, zmień nazwę foldere C:\Windows\SoftwareDistribution na np. C:\Windows\SoftwareDistribution.old i ponownie włącz usługę Windows Update

Oczywiście, jak zwykle, restart między jednym a drugim krokiem zawsze jest mile widziany. Podobnie cierpliwość. Pobranie aktualizacji czasami po prostu trwa kilkanaście minut….

Powodzenia!

Utworzyłeś maszynę wirtualną na Azure. Próbujesz się do niej podłączyć przez pulpit zdalny, a tu niespodzianka:

„The remote computer requires Network Level Authentication, which your computer does not supprt.”

Żaden problem, maszyna jest testowa, więc wystarczy włączyć jedną opcję:

Chodzi o  opcję [x] Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended). Hmmm, ale jak to zrobić jak się nie ma połaczenia RDP!? Czytaj dalej »

Ponieważ często o tym zapominam, to:

Źródło: https://msdn.microsoft.com/en-us/library/ms143504.aspx

Za chwilę zmieniam fryzurę! Bo chyba sobie włosy powyrywam! Mam maszynę w Azure, próbuję się do niej połączyć a tu nici:

Remote Desktop Connection
Your system administrator does not allow you to connect to this remote computer. For assistance, contact your system administrator or technical support.

Przecież to ja jestem adminem, więc co mam dalej zrobić!? Czytaj dalej »

Załóżmy, że w swoim skrypcie potrzebujesz rozpoznać, czy dany dzień jest dniem wolnym (sobota lub niedziela) czy roboczym… Proste!

$d = [datetime]::Now
$d.dayofweek

No i świetnie. Wynikiem może na przykład być:

Tuesday

Hmmm, ale czy aby zawsze? Na komputerze z polskimi ustawieniami regionalnymi może zostać zwrócone:

Wtorek

Jeśli chcesz sprawdzić czy dzień jest niedzielą czy sobotą czy innym dniem tygodnia lepszym wyborem byłoby korzystanie z jakiejś wartości liczbowej, gdzie np Niedziela to 0, Poniedziałek to wtorek itp. Da sie coś takiego zrobić. Zrzutuj właściwość DayOfWeek do [int]:

$d = [datetime]::Now
[int]$d.dayofweek

W moim przypadku (wtorek) zwracana wartość to 2. Czy jednak nie będzie tak, że zależnie od ustawień kultury, 0 będzie oznaczać Niedzielę, a w innych warunkach Poniedziałek? Otóż nie!. Jak czytamy na

https://msdn.microsoft.com/pl-pl/library/system.datetime.dayofweek(v=vs.110).aspx

The value of the constants in the DayOfWeek enumeration ranges from DayOfWeek.Sunday to DayOfWeek.Saturday. If cast to an integer, its value ranges from zero (which indicates DayOfWeek.Sunday) to six (which indicates DayOfWeek.Saturday).

The DayOfWeek property returns an enumerated constant; it does not reflect a system’s regional and language settings. To retrieve a string representing a localized weekday name for a particular date, call one of the overloads of the ToString method that includes a format parameter and pass it either the ddd or dddd custom format strings. For details, see How to: Extract the Day of the Week from a Specific Date.

A więc niezależnie od ustawień językowych, regionalnych itp. 0 to zawsze Niedziela a 6 to zawsze Sobota. Wartość stałych można sprawdzić wpisując:

[int][dayofweek]::Sunday
[int][dayofweek]::Monday
[int][dayofweek]::Tuesday
[int][dayofweek]::Wednesday
[int][dayofweek]::Thursday
[int][dayofweek]::Friday
[int][dayofweek]::Saturday

Wynik to oczywiście

0
1
2
3
4
5
6

Jeśli wiec trzeba sprawdzić czy data jest weekendowa wykonaj:

$d = [datetime]::Now
if (($d.DayOfWeek -eq [dayofweek]::Sunday) -or ($d.DayOfWeek -eq [dayofweek]::Saturday))
{
   Write-Output "this is weekend"
}
else
{
   Write-output "this is NOT a weekend"
}

Protokół NTLM służy do uwierzytelnienia (authentication), czyli jego celem jest sprawdzenie kto chce wykonać daną czynność (np. zalogować się do komputera lub zdalnie uruchomić proces na komputerze). Jeśli dwa komputery (klient i serwer) znajdowałyby się w  domenie AD, a połączenie wykonywano by z wykorzystaniem nazwy komputera to zostałby wykorzystany protokół Kerberos. Jeśli jednak komputery znajdują się w grupie roboczej lub do połączenia wykorzystano adres IP to Windows użyje protokołu NTLM.

Jak wiadomo najbardziej wrażliwą informacją o użytkowniku jest jego hasło i dlatego nikt nie chce przesyłać hasła po sieci. NTLM stosuje więc pewną sztuczkę. Komputer kliencki generuje pewną frazę i szyfruje ją z wykorzystaniem hasła użytkownika. Jest to wyzwanie dla komputera serwera, który musi teraz sprawdzić czy hasło jest poprawne. Skąd się wzięło hasło na komputerze kliencie? To proste – podał je użytkownik! A skąd komputer serwer weźmie poprawne hasło? Zazwyczaj komputer serwer nie zna tego hasła, ale może poprosić o pomoc kontroler domeny. Kontroler jest w stanie dla komputera serwera dokonać przeliczeń na haśle i w ten sposób kontroler domeny pomaga w wygenerowaniu klucza sesyjnego, jakim dalej mogą się posługiwać komputery klient i serwer.

NTLM często bywa wyłączony, bo Kerberos jest bezpieczniejszy! W przypadku Kerberos weryfikowany jest nie tylko klient przed serwerem ale jeszcze dodatkowo serwer przed klientem. W NTML wcale nie ma pewności, że serwer z którym klient się chce połączyć jest rzeczywiście tym do którego się chciało połączyć. NTLM nie chroni administratora przed atakiem man-in-the-mddle.