Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

O domenie Windows (AD), usługach DNS i DHCP, oraz konfiguracji sieci wirtualnych

Wstęp

Od dawna na blogu odgrażam się, że opiszę podstawy budowania systemu wysokiej niezawodności (klaster HA) na poziomie maszyn wirtualnych.
Jako że przykład będzie przedstawiony w środowisku Windows, należy poruszyć w osobnym wpisie kwestię kontrolera domeny , który jest niezbędny w większości takich środowisk (szczególnie w popularnych hypervisorach jak Hyper-V, czy VMware ESX).

Po przejściu przez ten tekst powinieneś:

  • potrafić zainstalować podstawowy kontroler domeny
    w środowisku Windows Server 2012 R2,
  • zainstalować i skonfigurować usługi DNS i DHCP,
  • dołączyć testową stację roboczą do domeny,
  • rozumieć podstawową konfigurację sieci wirtualnych w VMware Worksation.
  • Tutaj mała uwaga: wpis przeznaczony jest dla osób zaawansowanych (lub pretendujących), chcących sprawnie poruszać się w środowisku Windowsowym. Osatnio zarzucono mi zbyt techniczne podejście - tym razem postanowiłem ponownie linkować do Wikipedii i tam należy doczytać. Jeżeli znasz powyższe zagadnienia, lub nie chcesz ich znać, albo wpis jest zbyt trudny - wpis nie jest po prostu dla Ciebie, nic na to nie poradzę.

    Active Directory

    Nie chciałem kopiować/tłumaczyć jednego z dziesiątek tysięcy wpisów w internecie i tłumaczyć co to jest Active Directory, jednak trzeba o tym wspomnieć. AD to potężne narzędzie, które pomino pewnych wad udało się firmie Microsoft. Zacytuję może Dominika Modliszewskiego z WSS.pl:
    Active Directory jest usługą, która w znaczący sposób usprawnia codzienną pracę w administrowaniu siecią. Umożliwia z jednego miejsca - serwera (zwanego kontrolerem domeny) konfigurację komputerów, użytkowników, rozmieszczanie drukarek oraz wiele innych.
    Korzyści z wprowadzenia Active Directory można podsumować w następujący sposób:

  • scentralizowanie zarządzania infrastrukturą informatyczną,
  • automatyczna instalacja i aktualizacja oprogramowania w firmie,
  • jednokrotne uwierzytelnianie, czyli pracownik podczas logowania wprowadzając tylko raz swoją nazwę użytkownika oraz hasło otrzymuje dostęp do wszystkich danych (do których ma uprawnienia) bez konieczności podawania za każdym razem poświadczeń, dzięki czemu możliwe jest zwiększenie produktywności pracowników,
  • redukcja kosztów zarządzania kontami,
  • ograniczenie liczby zgłoszeń o awarii / problemach.
  • Zanim przejdziesz dalej, przeczytaj proszę ten oto wpis Dominika.

    Sieci wirtualne w VMware Workstation

    Jak już ostatnio kilka razy pisałem, używam VMware Worksation i korzystam z kilku szablonów ("template"). Zanim przystąpię do omówienia zagadnienia podstawowej konfiguracji Active Directory / domeny Windows kilka słów o środowisku w którym będzie to zrobione.

    Warto na tym etapie zdecydować w jakiej podsieci będziemy uruchamiać nasz LAB. W większości sytuacji lepszym rozwiązaniem jest nowa podsieć - dodatkowa domena rozgłoszeniowa, dająca możliwość uruchomienia osobnego serwera DHCP, który nie "walczy" z tym uruchomionym na domowym routerze. Po instalacji VMWare i podobnych hypervisorów może zdziwić, że pojawiają się dodatkowe interfejsy sieciowe:

    Zaglądając w ustawienia sieciowe, mają one nadane IP:

    Ustawienia interfejsów wirtualnych znajdują się w zakładce "Edit -> Virtual Network Editor..."

    W celu dokonywania zmian i zobaczenia dodatkowej sieci (VMnet0) należy nacisnąć "Change Settings":

    Pierwsza sieć wirtualna (domyślnie instalowana przez VMware Worksation) to VMnet0. Jest ona bezpośrednio "zmostowana" z główną siecią na domyślnym interfejsie - w mojej sieci domowej to 192.168.10.0 /24. Każda maszyna wirtualna podpięta pod VMNet0 będzie widziana w otoczeniu sieciowym domowych komputerów jak pełnoprawny komputer - uzyska adres IP z domyślnego serwera DHCP (w większości sytuacji uruchomionego pewnie na routerze na IP 192.168.0.1, lub podobnym), będzie widzoczna w tablicy ARP itd.
    Tutaj bardzo ważna uwaga - często na forach (w tym na Dobre Programy) pojawia się błędne założenie, że
    wystarczy uruchomić firewall na komputerze - hoście (gdzie jest uruchomiony VMware) i to zabezpiecza np. Windows XP i zastępuje jego firewall
    Wyjątkowo mylne podejście - ustawienia sieci wirtualnej w trybie "bridge" działają w pierwszej (fizycznej) i drugiej (łącza danych) warstwie modelu OSI. Firewall natomiast zaczyna się w warstwie 3 (adresy IP), potem już porty (warstwa 4) aż do głębokiej inspekcji pakietów (warstwa 7).

    Ja na "na wypadek" zawsze ręcznie ustawiam na odpowiednią kartę sieciową - czasem mam dodatkowe intefejsy bezprzewodowe, karty sieciowe, czy inne wirtualne sieci, VPNy (w tym Hamachi) i przy domyślnych ustawieniach zdarzyły mi się problemy, gdzie VMWare próbował "bindować" do nich:

    Drugi typ sieci to "Host-only" - maszyny wirtualne przypisane do tego vNET mogą komunikować się tylko między sobą, nie będą np. mogły skomunikować się np. z internetem. Opcja wygodna, gdy robimy testy aplikacji typu wirusy, lub innych, które powinny być izolowane od wyjścia na zewnątrz. W VMware Workstation 10-12 sieci typu "host-only" z tego co pamiętam można mieć 17, ale nie dam sobie ręki uciąć i jestem za leniwy, żeby grzebać teraz po dokumentacji w celu sprawdzenia szczegółów...
    Dochodzimy do ostatniej sieci, czyli typu "NAT".
    Sieć taką możemy mieć jedną z prostego względu - VMware robi za "natownicę". Maszyny w tej sieci mogą więc kierując się na odpowiedni adres bramy wydostać się do internetu. Mogą też komunikować się z siecią hosta, ponieważ VMware zapewnia routing. Plus rozwiązania jest taki, że nie wychodzą poza tą sieć np. zapytania DHCP (najprościej mówiąc: system operacyjny maszyny wirtualnej nie uzyska adresu IP z serwera DHCP uruchomionego np. na domowym routerze). Jedna z wad to więcej zabawy w przypadku serwera wirtualnego, który chcemy "wystawić" na zewnątrz (np. usługa WWW) - trzeba wykonać podwójne przekierowanie portów (najpierw na głównym routerze w sieci do komputera hosta, potem na wirtualnym routerze VMware przerutowanie do vLAN).
    Przejdźmy na chwilę do ustawień ("NAT Settings"): w powyższym przykładzie sieć to:
  • 192.168.228.0 /24 (192.168.228.1 - 192.168.224),
  • maska sieci: 255.255.255.0,
  • Gateway (brama domyślna): 192.168.228.2.
  • Warto przyjrzeć się zakładce "DHCP Settings" - DHCP oferuje adresy IP z zakresu:192.168.228.128 - 192.168.228.254

    Ja zawsze wyłączam serwer DHCP oferowany przez VMware - głównie przez to, że w większości sytuacji uruchamiam wewnątrz takiej sieci swój DHCP zachowujący się według moich ustawień, głównie chodzi o DNS (o tym za chwilę).

    Trzeba więc jedynie pamiętać zakres sieci i adres bramy domyślnej (192.168.228.2).

    Active Directory w praktyce

    Rozpisałem się za dużo o VMware - ale chciałem, żeby chociaż trochę coś skorzystały osoby mniej zaawansowane w sieciach. Wracamy do naszego serwera domenowego. Osatnim razem opisałem jak korzystać z szablonów ("template") i "linked clone". Zakładam, że potrafisz zainstalować wirtualną maszynę z Windows 2012 Server R2, Windows 7, lub Windows 10.
    Przykład domeny pokażę na wyżej wspomnianym Windows 2012 R2. Nie różni się to bardzo od 2008/2008R2 (może poza tym, że na 2008 czasem z "palca" trzeba promować domenę). Doskonale rozumiem, że Windows Server 2008/2008R2 jest nadal bardzo popularnym system produkcyjnym, jednak jak ktoś zaczyna swoją przygodę z AD - Windows 2012 R2 jest dobrym wyborem (na horyzoncie widać już 2016, nie ma co się ładować w starsze wersje serwerowe).
    Maszynę wirtualną pod kontroler domeny należy skonfigurować z podstawowymi parametrami opisywanymi w poprzednim wpiście. Na czas instalacji ustawiam jednak trochę więcej RAM - w przypadku deficytu pamięci w komputerze-hoście spokojnie można później w środowisku testowym zmniejszyć na 1-1.5GB (kontroler domeny nie ma aż tak dużo zadań i to mu wystarczy). WMware radzi też sobie całkiem sprawnie z dynamicznym alokowaniem zasobów, jedynie należy pamiętać o instalacji VMware Tools.
    Tutaj też należy wskazać karcie sieciowej z której sieci (vLAN) ma korzystać - VMnet8, czyli "NATowana" podsieć. Po pierwszym uruchomieniu serwera należy ustawić statyczny adres IP:
    DNS wskazujemy na localhost (127.0.0.1) - usługa za chwilę zostanie zainstalowana. Ustawienia można sprawdzić za pomocą polecenia ping:
    Poprawna odpowiedź z 192.168.228.2 oznacza, że mamy dostęp do bramy udostępnianej przez wirtualny router VMware, natomiast odpowiedź z 8.8.8.8, że mamy "wyjście" (routing) do internetu.
    Pierwszą usługą jaką powinniśmy zainstalować to lokalny serwer DNS. Większość problemów w środowisku AD (brak możliwości dołączenia do kontrolera, albo np. kilkuminutowe logowanie stacji roboczych) wynika właśnie ze złych ustawień DNS.
    Na tym etapie można zmienić nazwę serwera. Z racji tego, że czasem łączę 'laby', ustalam powiązania między serwerami itd. warto ustawić nazwę zależną od danego środowiska testowego: np. LAB10_DC. Nic jednak nie stoi na przeskodzie, aby serwer nazywał się "DC", "SERVER", albo "TADEUSZ".
    Możemy przystąpić do instalacji serwera DNS i serwera DHCP - z przystawki "Server Manager" wybieramy opcję "Add roles and features" (Next->Next-Next), zaznaczany "DHCP server" i "DNS server" :
    Cztery razy "Next" i na końcu "Install". Instalacja potrwa bardzo krótko, serwera nie trzeba restartować. W "Dashboard" powinny pojawić się dwie zakładki (DNS i DHCP), które ułatwiają dostęp do przystawek zarządzania usługami:
    DNS nie potrzebuje zbyt wielu zabiegów, skonfigurujmy jednak dodatkowe "forwardery" - żeby serwer Windows wiedział gdzie szukać zapytań do hostów w internecie, np. do strony http://dobreprogramy.pl - jak nie znajdzie ich na lokalnym serwerze DNS (192.168.228.2), niech sprawdzi na serwerze DNS Google.

    W przystawce DNS należy prawym klawiszem kliknąć na nazwie serwera, następnie na ustawienia ("Properties"):

    W zakładce "Forwarders" klikając na "Edit" należy dopisać dowolny zewnętrzny serwer DNS: może to być np. 8.8.8.8
    Wynik konfiguracji powinien być następujący:

    Teraz czas na DHCP. Sam "Dashboard" podpowiada, że potrzebna jest jest konfiguracja i zalecane jest uruchomienie "czarodzeja" ("Wizard"):

    Po wykonaniu tego, należy uruchomić przystawkę DHCP. Tam dla IPv4 tworzymy nowy zakres DHCP ("New Scope..."). W pierwszej kolejności kreator zapyta nas o nazwę (można podać dowolną, np. LAB10).
    W kolejnym oknie ustalamy zares DHCP.
    Nie jest dobrą praktyką ustalanie wszystkich możliwych adresów IP jako dostępne z adresu DHCP. Dobra praktyka mówi o zostawieniu kikunastu adresów poza tym zakresem - unika się wtedy dodatkowych rezerwacji, wykluczeń itd. W średniej wielkości sieci takich adresów poza DHCP powinno być chociaż 10-20 dla celów innych serwerów, urządzeń sieciowych, drukarek, NASów (dysków sieciowych), AP (urządzeń dostępu bezprzewodowego).

    W przypadku, gdy chcemy, aby pierwszy adres uzyskiwany z serwera DHCP był 192.168.228.50 a ostatni 192.168.228.99, konfiguracja jest następująca:

    Kolejne okno konfiguracji pozwala skonfigurować "wykluczenia" - jeżeli wiemy, że np. adres 192.168.228.65 jest już używany przez drukarkę sieciową można dopisać ją właśnie tutaj - serwer DHCP powinie ten adres przy nadawaniu urządzeniom proszącym o IP:

    "Lease Duration" oznacza jak długo serwer DHCP będzie pamiętać IP i przypisywać je do tego samego komputera - komputer (lub inne urządzenie) nawet po wyłączeniu z sieci, jeżeli w ciągu przykładowo 8 dni pojawi się w sieci, dostanie dokładnie ten sam adres IP (sprawdzane jest to na podstawie fizycznego adresu karty sieciowej):

    Router (Default Gateway): wpisujemy adres IP bramy domyślnej (192.168.228.2).

    Należy pamiętać o naciśnięciu "Add" (ja o tym zawsze zapominam...):

    Na koniec pozostaje aktywować nowy zakres DHCP:

    Jeżeli wszystko zostało wykonane poprawnie, pojawił się nowy zakres ("Scope"). Wszystkie opcje, przez które przeprowadził nas "wizard" można przekonfigurować bardzo prosto w poszczególnych opcjach. Ja zawsze sprawdzam "Scope Options": zawsze zapominam dodać "003 Router". Nas najbardziej właśnie interesuje to, oraz co najważniejsze serwer DNS kierujący na kontroler domeny:

    Konfiguracja serwera DHCP nie jest niezbędna, ale ułatwi nam późniejszą pracę i nie będzie trzeba "ręcznie" ustawiać adresów IP dla poszczególnych komputerów klienckich.

    Promocja serwera do roli kontrolera domeny

    Możemy przystąpić do dodania usługi Active Directory (ADDS). Podobnie, jak instalowany był serwer DNS i DHCP, należy zaznaczyć usługę AD:

    Po instalacji usługi należy ją skonfigurować - czyli wypromować kontroler domeny:

    W pierwszej kolejności należy ustalić rolę serwera domenowego, oraz nazwę domeny:

    Z racji tego, że jest to nowe środowisko, wybieramy opcję trzecią (nowy "las"), oraz nazwę domeny Windows. Tu zaczynają się często schody... "Domena Windows" i "domena internetowa" (np. wykupiona u jakiegoś popularnego dostawcy) to dwie zupełnie inne sprawy - często brak zrozumienia tej kwesti budzi później wiele problemów. Kilka zasad:

  • nazwy nie można zmienić,
  • nie należy tworzyć zbyt długiej nazwy domeny (im krócej, tym łatwiej potem np. dołączać komputery do domeny, przelogowywać się między kontami domenowymi itd.),
  • musi być "coś po kropce" - najczęściej można się spotkać z .local (LAB10.local).
  • Dobre praktyki Microsoftu podpowiadają, że powinna być to nazwa domenowa np. strony internetowej firmy (np. dobreprogramy.pl). Jak jednak do końca nie rozumiesz działania DNS i tworzenia dodatkowych wpisów w lokalnym serwerze DNS (np. CNAME autodiscover dla Outlooka, czy www dla strony internetowej), to jednak polecam wpisać .local

    W kolejnym oknie ustala się poziom funkcjonalny lasu i domeny - w naszym przypadku zostawiany domyślny (Windows Server 2012 R2).

    Ustalamy też hasło dostępu do trybu awaryjnego AD (odzyskiwania/naprawy) DSRM - obyś nie musiał nigdy z niego korzystać... W tej chwili nie musimy się skupiać na ostrzeżeniu o braku możliwości utworzenia delegacji DNS:
    Więcej o tym komunikacie i promowaniu kontrolera można doczytać na Technecie.
    W kolejnym oknie konfigurator powinien sam zaproponować "The NetBIOS domain name" jako LAB10. Katalogi "Database folder", "Log files folder" i "SYSVOL folder" należy pozostawić wg. ustawień domyślnych.
    Ostatnie okno to podsumowanie konfiguracji - można przeglądnąć jeszcze raz ustalone parametry. Zachęcam do kliknięcia "View Script" aby przekonać się, że GUI nowszych wersji serwera Windows to nakładka na Power Shell. Skrypt taki warto sobie skopiować i przy budowaniu nowego labu zaoszczędzi to kilku minut kilkania:

    # # Windows PowerShell script for AD DS Deployment # Import-Module ADDSDeployment Install-ADDSForest ` -CreateDnsDelegation:$false ` -DatabasePath "C:\Windows\NTDS" ` -DomainMode "Win2012R2" ` -DomainName "LAB10.local" ` -DomainNetbiosName "LAB10" ` -ForestMode "Win2012R2" ` -InstallDns:$true ` -LogPath "C:\Windows\NTDS" ` -NoRebootOnCompletion:$false ` -SysvolPath "C:\Windows\SYSVOL" ` -Force:$true

    Po naciśnięciu "Install" serwer zostanie wypromowany i zrestartowany. Przy pierwszym logowaniu należy zwrócić uwagę, że nie logujemy już się na konto lokalnego administratora serwera (LAB10_DC\administrator), ale na konto domenowe (LAB10\administrator):

    Serwer więc ma według nomenklatury Microsoft pełną jednoznaczą nazwę domenową (FQDN): LAB10_DC.LAB10.local
    .

    Klient

    Pora przystąpić do podłączenia testowej maszyny klienckiej - będzie to Windows 7 Professional Przypominam tylko, że nie da się podłączyć (w pełnym wymiarze) do domeny stacji roboczej z zainstalowanym Windows Home, lub innym "Starterem" - musi być to edycja Professional, lub wyższa. Przy konfiguracji maszyny wirtualnej ponownie przypominam o przypisaniu wirtualnego interfejsu do odpowiedniej wirtualnej sieci:

    Komputer wirtualny należy w miarę "przyjaźnie" nazwać, np. "PC1" - nazwę też można później bez problemu zmienić. Tutaj zapomniałem o jednej rzeczy... Po uruchomieniu klienta (PC1) nadal nie będzie mieć poprawnych ustawień sieciowych:

    Po przejściu do ustawień serwera DHCP (na maszynie Windows 2012) ustalony zakres ma prawdopodobnie status "czerwony" - nie jest aktywny. Po wypromowaniu serwera do poziomu kontrolera domeny należy zakres ponownie autoryzować - prawy klawisz myszy na serwerze i "Authorize".

    Po chwili można odświeżyć widok (klawisz "F5"), status zmieni się na zielono. Wracamy do komputera klienckiego - uzyskanie adresu z serwera DHCP najprościej wymusić za pomocną polecenia:ipconfig /renew

    Dla pewności można wykonać szybką diagnostykę ustawień za pomocą trzech różnych "pingów":

  • na adres IP serwera (kontrolera domeny),
  • na nazwę serwera (test serwera DNS),
  • na zewnętrzny adres IP (potwierdzenie routingu do internetu):
  • Teraz możemy podpiąć komputer kliencki do domeny:

    Jako nazwę domeny należy wpisać "LAB10.local" - w większości sytuacji wystarczy wpisać samo "LAB10", jednak dla pewności polecam podawać pełną nazwę. W przypadku, gdy poprawnie został skonfigurowany serwer DNS i ustawienia komputera klienckiego, pojawi się zapytanie o login i hasło administratora:
    Stacja robocza została dołączona do domeny i można go zrestartować:

    Teraz na komputerze klienckim możemy zalogować się jako administrator domeny. Tutaj też często pojawiają się problemy - Windows działa w ten sposób, że przy wpisywaniu loginu na komputerze dołączonym do domeny po 6-tym znaku będzie chciał logować jako lokalny użytkownik (np. PC1\administrator):

    W celu poprawnego zalogowania jako login należy podać LAB10\administrator:

    W przypadku udanego logowania oznacza to, że poprawnie dołączyliśmy stację roboczą do domeny.

    Podsumowanie

    Wyszedł trochę przydługi ten tekst ze względu na "liźnięcie" kilku tematów. Zrozumienie jednak podstaw działania serwera Windows i Active Directory jest niezbędne do ruszenia dalej w "uniwersum" Microsoftu. W następnym wpiscie będzie już więcej konkretów dla prawdziwych hardkorów.

    źródła:
    -------
    Fragment opisujący czym jest domena Windows jest żywcem skopiowany z z wpisu blogowego Dominika Modliszewskiego, zamieszczonego w portalu wss.geekclub.pl

     

    windows oprogramowanie serwery

    Komentarze

    0 nowych
    _nikt79_   5 #1 30.05.2016 19:22

    Wpis interesujący, zwłaszcza jeżeli nastąpi kontynuacja z opisem wzmiankowanego HA (oraz failover). Obawiam się jednak że osiągnięcie tego w środowisku microsftowym będzie wymagało ładnych paru maszyn z windows server i w praktyce generowałoby spore koszty licencyjne.
    Chętnie zobaczyłbym prezentacje alternatywy składającej się np. z :
    - Proxmox jako hypervisor zamiast HyperV czy Vsphere (z zaimplementowanym fencingiem dla relokowania maszyn w przypadku awari)
    - DRBD dla zapewnienia replikacji na poziomie dyskowym ( każdy host z proxmoxem ma dostęp do aktualnej kopii wszystkich używanych maszyn )
    - OpenLDAP zamiast Active Directory ( jako rozwiązanie umożliwiające single sign on)
    - Pacemaker + CoroSync dla zapewnienia HA dla wybranych usług (np DRBD)
    - HAProxy + keepalive (jako loadbalancer z HA)

    Oczywiście powyższe środowisku nadaje się tylko do wybranych zastosowań, posiada jednak zdecydowaną zaletę - nie wymaga zakupu żadnych licencji ...

    Pozdrawiam

    Shaki81 MODERATOR BLOGA  38 #2 30.05.2016 19:23

    Po prostu nie wierze:) Kilka dni temu była dyskusja u mnie w pracy a temat właśnie Acitve Directory i DNS'a. Muszę podrzucić ten artykuł mojej władzy. Wielkie dzięki.

    Vidivarius   14 #3 30.05.2016 20:50

    No no. Sporo przydatnej wiedzy. Zaraz zacznę studiowanie.
    Nie myślałeś aby to wydać w trzech tomach? :)

    bachus   20 #4 30.05.2016 20:58

    @_nikt79_: tutaj mowa o środowisku Windows (chociaż pokażę, jak zachowuje się Linux w Hyper-V). W przypadku HA Hyper-V wypada dużo taniej w stosunku do VMWare - poza samym licencjonowaniem "ficzerów" odpadają pewne koszta z licencjonowaniem Windowsa; do w miarę ogarniętego HA wystarczą już dwie licencje Windows 2012 R2 Standard, które dadzją poza klastrem HA x4 wirtualne serwery Hyper-V (w sumie 6 instancji Windows 2012 R2).
    Co do ostatniego zdania: jak chce się mieć jednak Windowsa na produkcji, to jakaś licencja się przyda ;-)
    @Shaki81: DNS. Pierwsza rzecz przy problemach z AD to obadać co tam się dzieje.
    @Vidivarius: to miał być krótki wpis, a wyszło jak wyszło. Doskonale rozumiem, że moje wpisy mogą być dla niektórych upierdliwe ze względu na ilość treści - ale staram się pisząc dzielić tym, co wiem ;-)

    Kaldermane   1 #5 30.05.2016 21:05

    Dla mnie bomba. Prosto i konkretnie. Czekamy teraz na serię Tips&Tricks dla Windows AD czyli jak ułatwić życie sobie i użyszkodnikom.

    W rodzaju: repadmin /syncall czy choćby podstawowych zasad na start (wymuszenie bezpiecznych haseł, zmiana nazwy konta Administrator)

    Autor edytował komentarz w dniu: 30.05.2016 21:12
    bachus   20 #6 30.05.2016 21:09

    @Kaldermane: poważnie jakiś między wpis wrzucić o podstawach AD? Udostępnianie katalogów, zasady dostępu, dobre praktyki i podstawy GPO (np. mapowanie katalogów, czy jakiś scenariusz z profilem wędrującym?). Bez problemu mogę to zrobić, tylko czy znajdzie się na to czytelnik.

    Veers   10 #7 30.05.2016 21:14

    @bachus: jeden już jest - melduję się na ochotnika (szczególnie ten profil wędrujący, ale i reszta się przyda - ot choćby żeby się dowiedzieć gdzie człowiek robi coś inaczej :P )

    Jac0b   6 #8 30.05.2016 21:16

    Fajny tekst :) ale nie do końca zgodzę się ze stwierdzeniem, że "nazwy nie można zmienić,". Pewnie wiesz, że da się ją zmienić choć jest to pracochłonne i niebezpieczne przedsięwzięcie w środowisku produkcyjnym.

    Kaldermane   1 #9 30.05.2016 21:18

    @bachus: Oczywiście, zrobi się z tego fajna seria dla każdego wannabe admina windowsowego. Trzymam kciuki i czekam na więcej.

    Jac0b   6 #10 30.05.2016 21:28

    @bachus: Śmiało pisz, ciekawy wątek do dyskusji i wymiany pomysłów może z tego powstać... no i w końcu ciekawy wątek zbudowany o rozwiązania MS w kontrze do ciągłego wałkowania jaki to linux jest super i w ogóle open source wszędzie!

    bachus   20 #11 30.05.2016 21:29

    @Jac0b: może za bardzo to uprościłem - bardziej chodziło mi o to, że nie da się tak prosto, jak nazwę komputera klienckiego podłączonego do domeny ;-) Co do samej nazwy domeny w środowisku produkcyjnym - znam teorię, ale na szczęście nie miałem nigdy takiej potrzeby i nie życzę sobie takiej konieczności.

    Jac0b   6 #12 30.05.2016 21:31

    @bachus: Ja właśnie mam taki temat u jednego ze swoich klientów ale bronię się przed tym z racji tego, że też znam teorię ale na maszynie śmiga SBS2k8 więc sam rozumiesz, że nie ma szans...

    bachus   20 #13 30.05.2016 21:35

    @Jac0b: SBS2k8 to już zupełnie inna para kaloszy - tam nawet zmianę IP serwera trzeba przeprowadzać wizardem, żeby czasem Exchange się nie obraził. W życiu bym się tego nie podjął, jak klient nie jest jakiś bardzo duży to już chyba obok postawić to na nowej domenie.

    Jac0b   6 #14 30.05.2016 22:35

    @bachus: Wiadomo, dlatego to zostawiłem i nauczka na przyszłość - nie nadawaj domenie nazwy związanej bezpośrednio z nazwą spółki ;) - pisz dalej, jestem ciekawy gdzie z tymi wpisami dotrzesz :)

    bystryy   10 #15 30.05.2016 22:54

    @bachus: "to miał być krótki wpis, a wyszło jak wyszło"

    Wpisy serwerowe, jeśli są krótkie, są podejrzane ;)

    Masz mój głos w kolejnym głosowaniu. Mam nadzieję, że opiszesz (kiedyś) uwierzytelnianie certyfikatami.

    Wojmil   4 #16 30.05.2016 23:06

    @bachus: pewnie że się znajdzie - mnie by to bardzo interesowało

    klonek_wp   6 #17 31.05.2016 00:32

    @bachus: jak już będziesz tworzył dalej coś o HA to warto wspomnieć m.in. dlaczego czasami lepiej kupić MOLP'a niż OEM'a, a jeśli chodzi o podstawy AD to np. tworzenie grup i powiązanie z GPO wcale już takie proste nie jest jak się próbuje to samemu odkryć....

    Vidivarius   14 #18 31.05.2016 08:46

    @bachus: Mnie tam długość nie zraża. Wręcz przeciwnie, lubię tematy dobrze opisane i wyczerpane merytorycznie (w miarę możliwości oczywiście).

    bachus   20 #19 31.05.2016 09:06

    @klonek_wp: licencjonowanie w Windows? Nie jestem pewny czy chcę o tym pisać i odstraszać ludzi od technologii ;-) Co do GPO i powiązania z grupami - z rok temu w dużej firmie miałem zagwostkę, bo klient wyraźnie chciał pewnych rzeczy (offline files) tylko i wyłącznie na laptopach. Nie per-user, ale per-hardware. GPO rozpoznawać czy to laptop przed logowaniem użytkownika.

    Jac0b   6 #20 31.05.2016 10:58

    @bachus: I dałeś radę to zrobić? WMI?

    bachus   20 #21 31.05.2016 11:19

    @Jac0b: tak. Na początku chciałem filtrować po nazwie komputera (maska na zasadzie LT-coś tam), klient jednak chciał "po sprzęcie". Po baterii: dawało czasem dziwne wyniki (np. uszkdzoną baterię wmi laptop potrafił raportować jako nieoobecną). Zrobiłem to po typie pamięci
    (Select * from Win32_PhysicalMemory where FormFactor = 12). Niektóre laptopy potrafiły zwrócić jeszcze FormFactor = 8.

    Jac0b   6 #22 31.05.2016 11:33

    @bachus: Ciekawie :)

    tomaszr   5 #23 31.05.2016 11:43

    @bachus: znajdzie się zawsze, pytanie tylko czy ilość chętnych będzie wystarczającą dla Ciebie motywacją do napisania

    gaijin   5 #24 31.05.2016 12:47

    @bachus: Mistrzu pisz dalej, nie przejmuj się, nam wszystkim zależy na długości... twoich postów

    klonek_wp   6 #25 31.05.2016 20:27

    @bachus: Nie próbuję cię namówić do kilkunastu tomów o licencjach ms ;) ale akurat w kontekście HA transfer licencji na inny fizyczny host ma znaczenie. PS. rozwiązanie z laptopami bardzo intrygujące....

    Autor edytował komentarz w dniu: 31.05.2016 20:31
    Ryychuu   6 #26 31.05.2016 21:38

    @bachus: A bawiłeś się KVM/XEN? Z libvirt/proxmox/ovirt? Wygląda nieźle i jeszcze taniej :P

    #cebulaMocno

    Edyta:
    aa teraz zauważyłem komentarz

    Autor edytował komentarz w dniu: 31.05.2016 22:54
    klonek_wp   6 #27 31.05.2016 22:18

    @Ryychuu: taniej od czego? przecież hyper-v jest darmowy

    Autor edytował komentarz w dniu: 31.05.2016 22:24
    Ryychuu   6 #28 31.05.2016 22:41

    @klonek_wp: odpada licencja na Winde, ale jak ktoś robi podobne rzeczy to koszty licencji Windek są raczej dyskusyjne ;)

    Bardziej chodzi o fakt wykorzystania jakiegoś rozwiązania niepłatnego zupełnie, i jaką bachus ma na to opinie.

    Autor edytował komentarz w dniu: 31.05.2016 22:44
    klonek_wp   6 #29 01.06.2016 03:33

    @Ryychuu: serwer hyper-v jest zupełnie nieodpłatny i jeśli chcesz na nim hostować linuksy to koszt wyniesie 0zł. inna sprawa to po co hostować linuksy na hyper-v czy windowsy na kvm? ponad dwa lata temu stawialiśmy u klienta szesnastowęzłowy klaster który docelowo miał być na kvm ale była okazja to wgraliśmy hyper-v 2012r2 do testów w takim środowisku i.... tak został do dziś. wszystkie VMy (mieszane win+linux) udało się odpalić jako gen2

    djgrzenio   9 #30 01.06.2016 07:27

    Nie lubię hyperv heh brak zapodania fizycznego usb dla vm. Osobiście wolę kvm i jako storage ceph. W proxmox ładnie się to wszystko konfiguracje.

    Co do wpisu spoko. Jednak o ile pamiętam konfiguracja ad sama robi dns i wszystko co trzeba

      #31 01.06.2016 09:02

    @klonek_wp: Z tego co piszesz to też mógłbyś się pokusić o jakiś blog na dp. Było by coś do poczytania zamiast kolejnych opowieści jak to ktoś zmigrował na linuksa.

    MiłoszW   8 #32 01.06.2016 10:07

    To jeszcze misie powiedzcie dlaczego lap z Win8.1 i lap z Win10 nie chcą się w grupę połączyć razem, choć wszystko powpisywane, widać je w Sieci, a jednak zablokowane wsio : )

    bachus   20 #33 01.06.2016 10:08

    @klonek_wp: ja tam nie mam nic za bardzo do zarzucenia Hyper-V - też mam klastry po 20 serwerów (hyperwizorów), gdzie biega po 50 serwerów i nic się za bardzo z tym nie dzieje. Hyper-V jest jedynie trudniejsze do monitorowania, tj. wymaga dodatkowych narzędzi od MS. Nie zdażyło mi się też, aby mieć większe problemy z P2V (maszyna fizyczna zmigrowana do wirtualnej). Opisz może kiedyś swoje środowisko, zawsze jestem ciekawy rozwiązań innych, może coś podpatrzę ;-)

    Odpowiadając na pytania dotyczące innych rozwiązań (KVM, Proxmox) - dokładnie jak ktoś napisał @Ryychuu: "bawiłem się" (środowiska testowe, jakiś domowy lab itd.). Nie czuję się mocny w temacie, aby o tym pisać (znajdzie się czytelnik oblatany w technologii i wytknie mi niekompetencję).

    Autor edytował komentarz w dniu: 01.06.2016 10:13
    klonek_wp   6 #34 01.06.2016 10:29

    @bitx (niezalogowany): czasami miałbym ochotę coś skrobnąć, ale niestety permanentny brak czasu..... czasami nawet raz w tygodniu nie udaje mi się zajrzeć na fora. po za tym jak sam pewnie widzisz po blogach nie każdy ma "lekkie pióro" - nie wiem jak u mnie bo nie próbowałem, ale może nadejdzie taki czas

    klonek_wp   6 #35 01.06.2016 10:38

    @bachus: będzie w drugiej połowie roku okazja coś napisać bo właśnie ten klient będzie migrowany na hyper-v 2016. ostatnio trochę męczyliśmy betę łącznie z upgradem klastra na żywo i wygląda to całkiem dobrze.

    bachus   20 #36 01.06.2016 11:07

    @klonek_wp: no ja też mam w labie. Ostatnio ze dwa dni przesiedziałem w EMEA MS w Dublinie na pokazach. Na licencjonowanie Windows Server 2016 zwróciłeś uwagę? Będzie spora zadyma, MS kończą się kolana (na strzały). Może do końca tygodnia coś skrobnę o licencjonowaniu MS - ostatnio z pół godziny musiałem tłumaczyć klientowi czemu potrzebuje CALe na 40 drukarek.

      #37 01.06.2016 12:17

    @bachus: CALe zawsze były w M$ choć od 2012 polityka jest coraz gorsza :) pamiętam jak wprowadzałem AD u siebie na ~350 maszynach i ~40 drukarkach :) to była prawdziwa szkoła życia, ale potem zarządzanie tym - bajka (zdalna instalacja softu, helpdesk zdalny etc.). Jednak roczne koszty utrzymania licencji - masakra.

    bachus   20 #38 01.06.2016 13:14

    @Pawel)war (niezalogowany): o prowadzeniu helpdesku może kiedyś napiszę - jak to się robi przy większej ilości maszyn i jak sobie ułatwić życie (np. n-able od Solarwinds).

    turek666   1 #39 05.06.2016 11:29

    odnośnie licencjonowania serwerów AD. Jakie licencje potrzebowałbym, jeżeli w centrali mam Datacenter i tu postawione AD, DNS itd, a w oddziałach ( dwóch po max 40 użytkowników ) chciałbym postawić jakieś backupowe serwery tego AD ( readonly? ) z ewentualnym przełączeniem na te serwery w przypadku padu tego głównego? Jakie licencje serwerowe i CALowe bym potrzebował?

    adam9870   12 #40 05.06.2016 12:25

    @bachus
    Mam pytania odnośnie tego obrazka:

    http://gallery.dpcdn.pl/imgc/UGC/73554/g_-_-x-_-_-_73554x20160530002352_0.PNG

    1. Patrząc od lewej - "client devices" jest podłączony do jednego ze switchy. Czy w razie awarii tego switcha do którego podłączony jest użytkownik, straci on dostęp do usług hostowanych na maszynie wirtualnej?

    2. Patrząc od prawej - ostatnie urządzenie po prawej stronie to macierz dyskowa, na której znajdują się pliki maszyn wirtualnych. Ale... macierz jest jedna. Czyli w razie padu macierzy (np. zasilacza, płyty głównej), nie ma dostępu do usług hostowanych na maszynie wirtualnej. Tak?

    Autor edytował komentarz w dniu: 05.06.2016 12:26