Serwer DHCP jest doskonałym kandydatem do instalacji na systemie w wersji core. Instalacja, konfiguracja i już. W zasadzie czynności związane z utrzymaniem ograniczają się do rzadkiego backupu i reakcji na zmiany w infrastrukturze sieciowej. A te nie zachodzą zbyt często. Więc warto zaoszczędzić zasobów na serwerze wirtualizacji i zainstalować Windows Core.
Jednakże, jak zazwyczaj w przypadku wersji Core, zetknięcie się z „gołą” linią poleceń cmd potrafi zabić entuzjazm. Postaram się go rozdmuchać na nowo tym prostym Step-by-Step guide’m.
Przypominając podstawowe sprawy (o które się dzisiaj rozbiłem) musimy pamiętać o kilku czynnościach. Po zmianie hasła, którą wymusza sam system operacyjny pierwszą czynnością (bo potem się zapomni) jest zmiana nazwy komputera. Do tego służy polecenie
1 | netdom <nazwa obecna> renamecomputer /newName:<nowa nazwa> |
Bieżącą nazwę (wygenerowaną przez instalatora) poznamy dzięki poleceniu
1 | hostname |
Drugą irytującą czynnością jest aktywacja systemu. Do tego potrzebujemy skonfigurować adresację IP oraz dokonać procesu aktywacji.
Tak więc, aby przypisać właściwe adresy właściwym interface’om potrzebujemy najpierw ich listę:
1 2 3 4 5 6 | netsh interface ipv4 show interfaces Idx Met MTU State Name --- ---------- ---------- ------------ --------------------------- 3 10 1500 connected Local Area Connection 1 50 4294967295 connected Loopback Pseudo-Interface 1 |
Zapisujemy wartość Idx właściwego interface’u. Następnie możemy przypisać adres IP, maskę podsieci oraz bramę domyślną:
1 | netsh interface ipv4 set address name=<Idx> source=static address=<IP> mask=<netmask> gateway=<Domyślna brama> |
Teraz jeszcze tylko serwer dns i mamy pełny ruch sieciowy:
1 | netsh interface ipv4 add dnsservers [name=]<string> [address=]<IPv4 address> [[index=]<integer>] [[validate=]yes|no] |
Aktywacji dokonujemy poprzez dwie komendy:
1 2 | slmgr.vbs -ipk <klucz produktu> slmgr.vbs -ato |
W tym momencie nasz serwer jest gotowy do instalacji i konfguracji roli. Przedstawiony wstęp jest w zasadzie dostępny wszędzie, jednak warto mieć go pod ręką (a piszę to przecież także dla siebie).
Rolę serwera dhcp instalujemy poleceniem
1 | Dism /online /enable-feature /featurename:DHCPServerCore |
Stan w jakim nasz serwer DHCP się znajduje zaraz po instalacji jest co najmniej interesujący. Wszystkie binaria są co prawda zainstalowane w systemie, jednakże usługa nie jest uruchomiona, a jej profil uruchamiania ustawiony jest na „Wyłączona”.
Żeby to zmienić należy wydać polecenia:
1 2 | sc config dhcp start=auto sc start dhcp |
W tym momencie posiadamy sprawną usługę dhcp na serwerze. Jedyne, czego jej brakuje to konfiguracji. Tę możemy wprowadzić ręcznie, lub odtworzyć z kopii zapasowej. Ani jedno, ani drugie zadanie nie jest proste z linii poleceń. Jednak, zanim uruchomimy dostęp za pomocą narzędzi zdalnych, omówmy kwestię dodania naszego serwera do domeny:
1 | netdom join <nazwaHosta> /Domain:<FQDN> /UserD:Username /passwordd:* |
Po wykonaniu powyższej komendy konieczny jest restart maszyny. Zwróćmy uwagę, że w tej chwili nasz serwer DHCP zostanie uruchomiony wraz ze startem systemu operacyjnego.
Jedną z ostatnich akcji wykonywanych wprost z linii komend serwera jest (uwaga – w tej kolejności!) instalacja PowerShell’a oraz konfiguracja zdalnego dostępu przez konsolę zarządzającą Windows Server Manager. Należy wywołać polecenie
1 | sconfig |
i przejść do sekcji 4. Configure remote management. Następnie wybieramy opcję 2. Install Power Shell. Po tej operacji należy zrestartować maszynę. Następnie uruchamiamy ponownie skrypt sconfig i wywołujemy opcję 4.3 Allow server remote management.
Po wykonaniu tej akcji następuje aktywacja odpowiednich cmdlet’ów Powershella a także właściwa konfiguracja niektórych przestrzeni nazw WMI.
W tym momencie posiadamy dostęp do naszego serwera przez konsolę Windows Server Manager. Jeżeli chcemy skonfigurować nasz serwer od podstaw, to wystarczy otworzyć węzeł usługi w naszej przystawce MMC i wyklikać odpowiednie opcje (zakres przydzielanych adresów, maskę podsieci, bramę domyślną, DNS, wins) dla każdego z konfigurowanych zakresów.
Jednakże gdy chcemy odtworzyć nasz serwer z wykonanej wcześniej kopii zapasowej należy zachować szczególną ostrożność z dwóch powodów. Po pierwsze konsola pokaże nam okno wyboru katalogu zawierającego kopię zapasową. I jest to pewne ułatwienie, gdyż nie trzeba całej ścieżki wpisywać ręcznie. Jednakże jest to utrudnienie o tyle, że wskazujemy katalog lokalny, wcale nie mając na uwadze, że usługa DHCP będzie poszukiwać dokładnie tego katalogu na serwerze zdalnym. Nie należy się zastanawiać, dlaczego akurat to okno ma wyłączoną opcję pokazywania dysków sieciowych. Należy zadbać o to, żeby ścieżka wskazywana na dysku lokalnym istniała dokładnie taka sama na dysku konfigurowanego właśnie serwera typu Core. Drugą pułapką jest kwestia uprawnień. Nie zawsze usługa dhcp prawidłowo zdiagnozuje fakt, że danych plików nie ma i wyświetli błąd „Access denied”. Drugim możliwym błędem jest fakt, że konsola skoryguje uprawnienia na dysku lokalnym, a nie zdalnym (co jest dość logiczne – nie istnieje żadne powiązanie pomiędzy tymi strukturami katalogów). Należy pamietać o nadaniu uprawnień odczytu i zapisu do katalogu z kopią zapasową na serwerze DHCP dla konta builtin\DHCPService.
Przy zachowaniu opisanych wyżej procedur nasza usługa DHCP będzie długo i bez konieczności konserweracji działać na systemie typu Core.