Problem z lokalizacją połączenia sieciowego w Windows Server 2012.

Okresowe aktualizacje systemów operacyjnych to norma w dzisiejszych czasach. "Łatają" wszyscy producenci i dotyczy to także (a może przede wszystkim ;) ) Microsoftu.

Filozofii w tym wielkiej nie ma, instaluje się "łaty", restartuje komputer i... po sprawie. Czyżby? Czasami zdarza się, że coś pójdzie nie tak - ot choćby znane swego czasu problemy z Windows 10 po których komputer potrafił się już nie uruchomić. Podobnie wygląda sprawa z systemami serwerowymi Microsoftu a konkretnie z Windows Server 2012 (Standard). Do tej pory po wszystkich aktualizacjach i restartach nie było z nim najmniejszego problemu. Po ostatnich środowych biuletynach (z 13 lipca - ooo, czyżby jednak pechowa trzynastka? ;) ) pojawiły się poważne problemy.

Jako, że owa maszyna z WS2012 na pokładzie oprócz serwera plików, świadczy również usługi związane z serwerem licencji dla Solid Works oraz system bazodanowy dla Symfonii (Pervasive SQL) to po nocnym "up to date" rano rozpętało się istne pandemonium :D

Mimo, że aktualizowany serwer nie sygnalizował po resecie żadnych kłopotów, to użytkownicy zasypali mnie zgłoszeniami o Symfonii nie mogącej połączyć się z bazą oraz o Solidzie, który nie mógł pobrać sobie licencji (Zdjęcie 1).

Jak to zwykle bywa, wszyscy potrzebowali rozwiązania na JUŻ choć zwykle rano snują się po biurach z kawą i bułkami :) No cóż, jak mus to mus - miałem pewne podejrzenia co do tego incydentu i pierwsze swoje kroki skierowałem ku zaporze sieciowej. Mimo, że sama zapora była ok, to jednak status jej połączenia figurował jako "nie połączono". W tym momencie wszystko stało się jasne. Jakimś cudem po aktualizacji poprawek i restarcie serwera połączenie "przeskoczyło z "sieci z domeną" na "sieci publiczne".

Jak wiemy, w zależności od kategorii do jakiej należy nasza sieć (z domeną, prywatne lub publiczne) zmienia się tez zachowanie samej zapory - akurat właśnie ustawienie "publiczne" jest najbardziej restrykcyjne i przez to odcięło hosty z Solidem i Symfonią od połączenia z serwerem! W sieciach z domeną (tak jak u mnie) powinno to wyglądać jak na zdjęciu 2

Tymczasem siecią połączoną była ta "publiczna" co właśnie generowało problemy. Szybki rzut oka do "Centrum sieci i udostępniania potwierdził moje przypuszczenia. Aby na 100% zweryfikować winę firewall'a po prostu go... wyłączyłem. Poskutkowało to nawałnicą telefonów, że teraz wszystko działa :) Hola hola - nie tak szybko! Wprawdzie mógłbym dodać kilka regułek do zapory w kategorii "publiczna" ale nie tędy droga. Należało zmienić kategorię na powrót na "sieć z domeną" - niestety, w Windows Server 2012 domyślnie ta opcja jest wyłączona. Można ją włączyć (o tym za chwilę) ale najszybszy i najbardziej banalny sposób na zmianę kategorii połączenia to wyłączenie na chwilę interfejsu sieciowego! Click... i po problemie (Zdjęcie 3)

To banalne rozwiązanie sprawiło, że problem przestał istnieć. Jasne, zdaję sobie sprawę, że większość z czytelników DP to fachowcy, którzy już to wiedzą, niemniej wierzę, iż taka solucja może się komuś przydać a niekiedy nie warto tracić czasu.

Miało być jeszcze o możliwości zmiany kategorii. Jest to jak najbardziej możliwe a w tym celu musimy edytować lokalną polisę zabezpieczeń na serwerze a dokładniej klucz ukryty w:

(Zdjęcie 4)

W okienku "Uprawnienia użytkowników" zmieniamy opcję lokalizacji sieciowej z "Nie skonfigurowano" na "użytkownik może zmienić lokalizację" i to wszystko. UWAGA! Możliwość zmiany kategorii zyskamy dopiero po restarcie maszyny!