
(odgapione z http://www.improgrammer.net/now-thats-a-neat-way-to-tell-someone-about-killing-processes/)

(odgapione z http://www.improgrammer.net/now-thats-a-neat-way-to-tell-someone-about-killing-processes/)
Na początku należy sprawdzić, jakie zony są zdefiniowane w firewall. Na świeżo zainstalowanym systemie domyślnie jest to FedoraServer, ale lepiej sprawdzić:
firewall-cmd --get-active-zones
Żeby otworzyć port tcp 5000 wykonaj:
firewall-cmd -permanent --zone=FedoraServer --add-port=5000/tcp
Żeby wylistować definicje zapisane w strefie FedoraServer wykonaj:
firewall-cmd --zone=FedoraServer --listall
Żeby port rzeczywiście został otwarty wykonaj restart firewalla:
systemctl restart firewalld.service
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ć:
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 »
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:
| DB | AG | SSRS | SSIS | SSAS | |
| Logon as a Service | X | X | X | X | X | 
| Increase a process working set | X | ||||
| Replace a process level token | X | X | |||
| Adjust memory quotas for a process | X | X | X | ||
| Bypass traverse checking | X | X | X | ||
| Perform volume maintanace taksks | X | ||||
| Lock pages in memory | X | x | |||
| Impersonate a client after authentication | x | ||||
| Increase Scheduling priority | x | 
Ź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 »