Najlepsza praktyka wycofywania kontrolera domeny, który jest również serwerem DNS?

Istnieją dwie szkoły myślenia dotyczące procesu likwidacji kontrolerów domen Active Directory, które są intensywnie wykorzystywane jako serwery DNS.

1. Dodaj adres IP wychodzącego kontrolera domeny do nowego kontrolera domeny i upewnij się, że DNS nasłuchuje pod tym adresem.

2. Zdegraduj starego kontrolera domeny, pozostaw na nim rolę DNS i skonfiguruj globalny serwer przesyłania dalej DNS na nowym serwerze.

Oczywiście oba są stopami, dopóki wszystkie serwery i urządzenia nie zostaną skonfigurowane do korzystania z podstawowego adresu IP nowego serwera, ale czasami ten okres przejściowy może być stosunkowo długi w zależności od wielkości środowiska.

Czy istnieje tutaj wyraźna najlepsza praktyka?

Waham się odpowiedzieć, ponieważ uważam, że jest to bardziej pytanie „dyskusyjne” niż pytanie ściśle zadawane pytań i odpowiedzi ... ale to leniwy sobotni poranek, więc i tak odpowiem.

Czy istnieje tutaj wyraźna najlepsza praktyka?

Nie. (Cholera, może to była łatwa odpowiedź ...)

Microsoft zapewnia bardzo ogólne, łatwe do Googleing Bingable wskazówki na temat obniżania poziomu kontrolerów domeny i przeprowadzania migracji AD i DNS, ale nie będę zawracał sobie głowy łączeniem się z nimi ani nie będę udawał, że odpowiedzą na konkretne pytanie, ponieważ Microsoft oczywiście nie może udokumentuj każdy konkretny przypadek dla każdego środowiska organizacji.

Tak więc administratorzy systemów / inżynierowie tacy jak my muszą wypełnić luki dzięki naszej własnej wiedzy i doświadczeniu, w którym Microsoft nie napisał specjalnego skryptu tylko dla nas, i to czyni nas cennymi.

Mogę podać przykład czegoś, co zrobiliśmy, aby rozwiązać ten sam problem, ponieważ pracuję również w środowiskach obejmujących wiele globów z dziesiątkami lub więcej kontrolerami domen, różnymi lasami AD współdzielonymi w tych samych sieciach, urządzenia inne niż Windows również zużywają Usługi DNS z tych samych kontrolerów domeny itp. Przeprowadzka do nowych centrów danych i wyprowadzka ze starych, konieczność migracji na nowy sprzęt lub nowe wersje systemu operacyjnego oraz zwykła stara polityka biznesowa to wszystkie możliwe powody, dla których musielibyśmy wycofać kontrolery domeny, które potencjalnie nadal były używane. A gdy masz wiele heterogenicznych organizacji korzystających obecnie z tych serwerów DC / DNS, zwykle jest to wyczerpujący, przeciągający się proces rekonfiguracji każdego klienta (z których wiele może nie być pod Twoją kontrolą) przed wycofaniem kontrolera domeny, z udziałem menedżerów projektów,

Więc dlatego mówię, że nikt nie może dać się odpowiedź na to pytanie. Można to zrobić na tysiąc sposobów, a niektóre będą lepsze niż inne, w zależności od struktury i potrzeb organizacji.

Coś, co zrobiliśmy, aby rozwiązać ten problem, to utworzenie VIP-a dla każdego centrum danych i połączenie wszystkich kontrolerów domeny w tym centrum danych za tym VIP-em. (Ten VIP jest przeznaczony dla usługi DNS tylko z oczywistych powodów, nie mówię o równoważeniu obciążenia Kerberos i LDAP.) W ten sposób klienci mogą być skonfigurowani do korzystania z tego VIPa dla ich resolvera DNS, a my możemy dodawać i zabierać kontrolery domeny stojące za tym VIP-em, kiedykolwiek i jakkolwiek zechcemy.

Ale nie stoi przed tobą problem ... więc biorąc pod uwagę podane opcje:

1. Dodaj adres IP wychodzącego kontrolera domeny do nowego kontrolera domeny i upewnij się, że DNS nasłuchuje pod tym adresem.

2. Zdegraduj starego kontrolera domeny, pozostaw na nim rolę DNS i skonfiguruj globalny serwer przesyłania dalej DNS na nowym serwerze.

Wybrałbym opcję nr 1, ponieważ Twoim celem jest jak najszybsze wycofanie starego serwera, a opcja nr 2 nie pomaga pozbyć się starego serwera. W przypadku opcji 2 istnienie serwera jest nadal konieczne. Nie chciałbym też zgodzić się z sugestią Mathiasa R. Jessena dotyczącą stref skrótowych, ponieważ znów musisz pozostawić stary serwer na miejscu i na służbie, co nie sprzyja twojemu celowi końcowemu.

Z opcją nr 1, choć może to być brzydkie, możesz wycofać stary serwer, ubiegać się o oszczędności dla swojej firmy, uniknąć płacenia czynszu za kolejny miesiąc w tym centrum danych i otrzymać nagrodę za bycie tak dobrym pracownikiem.

Edycja: Myśląc trochę o naszym czacie, myślę, że mogłem rzucić na ciebie własne wymagania, ponieważ mam teraz wymagania dotyczące ASAP-a dla niektórych rzeczy, więc to było zupełnie nowe. Wygląda na to, że nie masz tak bezpośredniego wymagania, aby wyłączyć serwer jak najszybciej.

To powiedziawszy, nie zmieniam mojej sugestii, ponieważ nadal wolałbym ją. W przeszłości dodawanie dodatkowego adresu IP do istniejącego kontrolera domeny działało dla mnie dobrze w bardzo podobnych scenariuszach, a wolałbym raczej, niż mieć dziwny ślad serwera siedzącego tam przez nieokreślony czas.

Droga do piekła Active Directory jest wyłożona tymczasowymi bandażami. Przypisywanie adresu IP zepsutego lub do zlikwidowania serwera DNS nowemu serwerowi DC i DNS jest tymczasowym bandażem.

Jak zauważył @gravyface w komentarzach, w idealnym scenariuszu zmieniłbyś wszystkie zakresy DHCP i konfiguracje statyczne, aby zaktualizować preferencje DNS klienta do nowego adresu IP zamiast starego, zanim całkowicie zlikwidujesz stary kontroler domeny.

Rozumiem, że przekonanie, że wszyscy klienci zostali ponownie skonfigurowani, niekoniecznie jest możliwe na czas, ale z pewnością uważam opcję nr 2 (przekazywanie całej przestrzeni nazw) za najmniej budzącą zastrzeżenia opcję.

Oprócz zezwalania staremu serwerowi na przesyłanie dalej żądań nawet po jego zdegradowaniu, zaleciłbym włączenie Rejestrowania debugowania dla przychodzących żądań na serwerze DNS - dzięki temu łatwiej jest ocenić nie tylko, czy klienci nadal wskazują stary serwer DNS, ale także identyfikacja wspomnianych klientów.

Biorąc to pod uwagę, myślę, że przegapiłeś oczywistą trzecią opcję: strefy skrótowe !

• Zdegraduj kontroler domeny, zachowaj rolę DNS i dodaj wszystkie strefy, które wcześniej pełniły jako strefy skrótowe - przekaż wszystko inne. W ten sposób wymuszasz na klientach faktyczne skontaktowanie się z kontrolerami domeny, których powinni używać, zamiast wykonywać dla nich pracę