Telnet – instalacja na Windows Server 2016
Środowisko systemów serwerowych Microsoft zmienia się bardzo dynamicznie. Nie ma co ukrywać, że konkurencja rozwija się bardzo szybko i pomimo, że mogłoby wydawać się, iż nic nie zagrozi dominacji serwerów Windows w segmencie małych i średnich firm wykorzystujących rozwiązania oparte o MS SQL, to sam Microsoft wprowadza modyfikacje podążające za najnowszymi trendami. Nie ukrywam, że na przykład bardzo mnie cieszy współpraca z Canonical i migracja części narzędzi terminalowych wprost z Linuxa. Bo właśnie o terminal tutaj chodzi, a będąc bardziej precyzyjnym o wygodę z jego korzystania (czyli np. poleceń telnet, ftp itd.). Narzędzia interfejsu graficznego mają swoje zalety, w szczególności dla początkującego użytkownika, jednak jeśli ktoś przebrnie przez początkowe trudności to zazwyczaj docenia mocno wygodę korzystania z trybu tekstowego.
W dzisiejszym wpisie chciałem pokazać jak zainstalować narzędzia Windows 2016 Server za pomocą 3 metod. Jak można się domyślić z poprzedniego akapitu skupię się raczej na terminalu niż na okienkach konfiguracyjnych. Za przykład posłuży nam program telnet.
Po pierwsze warto sprawdzić czy przypadkiem telnet nie został już zainstalowany w systemie. Można sprawdzić to w bardzo prosty sposób. Otwieramy terminal tekstowy i wpisujemy polecenie:
C:\>telnet google.com 80 'telnet' is not recognized as an internal or external command, → → operable program or batch file. C:\>
Powyższy komunikat świadczy, że należy włączyć narzędzie na poziomie serwera, czyli po prostu zainstalować aplikację.
Tereaz możemy przejść do instalacji w zwykłym terminalu tekstowym (uruchamianym poleceniem cmd – command prompt):
dism /online /Enable-Feature /FeatureName:TelnetClient
Po krótkim oczekiwaniu aplikacja zostanie zainstalowana.
Na tym nie konczą się nasze możliwości ponieważ można zrobić to samo w słynnym PowerShellu. Tym razem trzeba użyć polecenia:
Install-WindowsFeature -name Telnet-Client
W szczególności to rozwiązanie wydaje się być bardzo ciekawe, a użycie polecenia Install-WindowsFeature daje nam naprawdę duże możliwości. Polecam potestować – więcej informacji można znaleźć w dokumentacji na stronach Microsoftu.
Trzeciej opcji, którą jest instalacja w trybie okienkowym, nie będę opisywał. Z premedytacją – jako zwolennik terminali tekstowych.
MG
Tagi: komendy, konfiguracja, linia poleceń, serwer, Windows
Systemy serwerowe rodziny Windows stają się praktycznie niezastąpione w środowisku, gdzie jesteśmy zmuszeni korzystać z firmowych systemów bazodanowych. Oferta tych ostatnich zakłada w zasadzie wykorzystanie tylko jedynego słusznego środowiska pracy. Czasami nastręcza to nietypowych trudności, w szczególności gdy chodzi o sterowanie przepływem komunikacji. Oprogramowanie zapory sieciowej wbudowane w serwer w zasadzie nie pozwala na łatwe przekierowywanie komunikacji TCP nie wspominając już o UDP. Jeśli trafimy na środowisko homogeniczne, to skonfigurowanie wyżej wymienionych przekierowań może być trudne. Podstawowym narzędziem jest tutaj komenda linii poleceń netsh opisana w innym 
Czasami tak się zdarza, że jesteśmy zmuszeni zrezygnować z naszego ulubionego środowiska pracy na rzecz rozwiązań narzuconych z góry. W moim przypadku musiałem się pogodzić z pożegnaniem z Debianem i przenieść ulubione skrypty systemowe na system Windows. Chodziło rzecz jasna o zachowanie tych samych funkcjonalności, a jedną z nich było automatyczne wykonywanie kopii serwera baz danych i zapisanie ich na płycie DVD Blue Ray.
O tym, że linia poleceń w przypadku systemów takich jak Linux daje szerokie możliwości nie trzeba się specjalnie rozpisywać. Czasami jednak jesteśmy zmuszeni napisać skrypt systemowy dla serwera Windows i wtedy nie jest już tak prosto. Mam na myśli całkiem konkretny przypadek z własnego podwórka. W dużym skrócie zadanie polegało na okresowym wysyłaniu pliku baz danych MSSQL na zewnętrzny serwer FTP. Z jednej strony sprawa dosyć prosta, bo od razu przychodzi na myśl wykorzystanie harmonogramu zadań systemowych i użycie odpowiedniego skryptu wsadowego, z drugiej strony okazało się jednak, że narzędzie linii poleceń Windows takie jak komenda ftp niespecjalnie radzi sobie z trybem pasywnym transmisji. Zgodnie z dokumentacją wszystko powinno działać bez problemu, można nawet użyć spreparowanej wcześniej listy poleceń ftp, aby zautomatyzować zadanie jednak bardzo często w trakcie wykonania program zawiesza się. W sieci można znaleźć mnóstwo porad co zrobić w takiej sytuacji. Postanowiłem się tym razem podzielić innym rozwiązaniem.
Administratorzy serwerów opartych o systemy firmy Microsoft, podobnie jak pozostali, zmagają się często z usługami systemowymi, które z niewyjaśnionych przyczyn odmawiają posłuszeństwa. Problemy tego typu potrafią być bardzo uciążliwe. Zwłaszcza jeżeli dotyczą serwisów działających w tle. Z jeszcze gorszą sytuacją mamy do czynienia jeżeli chodzi o serwer kluczowy dla działania większego systemu. Obserwowanie tzw. zwisów usług jest ciężkim doświadczeniem w życiu każdego admina. Wyobraźmy sobie, że jakaś usługa po prostu staje w miejscu co jakiś czas. Zaglądamy do komponentu Usługi Systemowe i widzimy, że niemalże regularnie jest zatrzymywana. Oczywiście zawsze można uruchomić ją ponownie ręcznie i najczęściej udaje się to bez problemu. Niemniej za jakiś czas ponownie zatrzymuje się i tak się dzieje bez wyraźnej przyczyny oraz co gorsza są to zdarzenia cykliczne.
Bardzo często zdarza się, że chcemy przenieść serwis www, swoją stronę domową czy nawet pojedyncze statyczne dokumenty HTML pod zupełnie nowy adres. Aby poinformować swoich użytkowników o zmianach można umieścić odpowiedni komunikat na stronie – tzw. 
Przekierowanie portów (port forwarding) za pomocą reguł iptables jest dobrze znaną i często wykorzystywaną funkcją w systemach Linux. Każdy kto z niej korzystał wie, że bywa bardzo przydatna w różnych sytuacjach. Jednak czy można uzyskać podobny efekt na serwerze z zainstalowanym systemem Windows? Na pierwszy rzut oka wbudowana zapora Windows Firewall nie posiada takich możliwości. Pomimo szczegółowego przeszukiwania wszystkich opcji dostępnych z poziomu menu graficznego, trudno jest tam nawet znaleźć wzmiankę o podobnych usługach. Okazuje się jednak, że pod spodem, pod warstwą interfejsu mającego upraszczać i ułatwiać codzienne czynności administracyjne kryje się całe bogactwo rozmaitych narzędzi. Tym razem chciałbym zwrócić uwagę na polecenie netsh.
Chciałem dzisiaj napisać o problemie z jakim spotkałem się przed kilkoma dniami. Problem dotyczył podłączenia (mapowania) zdalnego udziału sieciowego w domenie Active Directory. Proces kończył się zawsze komunikatem – błąd 2221. Było to o tyle dziwne zachowania, że:
Domena MS Active Directory umozliwia przechowywanie profilu użytkownika w postaci tzw. Roaming Profile. Oznacza to, że przede wszystkim dane użytkowników mogą byc składowane na serwerze i umieszczone w odpowiednim współdzielonym katalogu. Główną zaletą takiego rozwiązania (pominę tym razem wady) jest umożliwienie pracy z każdej końcówki w domenie ponieważ po zalogowaniu profil użytkownika jest przesyłany na stację roboczą. Zaś podczas pracy system dba o synchronizację jego zawartości z serwerem. Brzmi całkiem nieźle i powiedzmy, że generalnie się sprawdza.