Active Directory domain controllers (DCs) are presumably the most change-loath sorts of servers out there. Utilized for verifying clients and devices to the domain, these are best set up and left as is - particularly with regards to their host name or network information.
While it's essentially an easy decision to express that renaming an domain controller is never going to be vital, shockingly, there may come when you need to change the system settings. Maybe a subnet is being rearranged or resigned, an organization obtaining has happened and new subnets are being presented whereupon domain controllers must be united, or some other factor is at play.
In case you're set up excess domain controllers (as any prepared IT proficient must do), moving one to an alternate subnet is simple. The torment focuses may emerge when both are moved over and customer PCs keep scanning for - and neglecting to discover - the domain controllers at their previous IP addresses. I don't prescribe it, since it can cause a wide range of network issues or even blackouts, however in the event that it must be done there's a cautious way to step.
Here are seven hints for fruitful domain controller organize relocations.
1. Check and build up your firewall rules
Firewall rules, particularly in complex situations, are probably going to represent an immense migraine. You have to guarantee that traffic between the vital subnets is proper for correspondence among customers and your space controllers, and conceivably between domain controllers and other domain controllers. Regardless of whether you're setting up new access or essentially growing what you as of now have, this is a key component, else you'll see some exceptionally odd and confounding conduct with respect to frameworks endeavoring to converse with DCs.
Windows Server 2008 R2 and Windows Server 2008, in consistence with Internet Assigned Numbers Authority (IANA) proposals, expanded the dynamic port range for associations.
That is a major range and that probably won't be all you need, so watch that Microsoft interface above and guarantee the suitable access is set up.
2. Arrange Sites and Subnets in AD
In case you're really changing the subnet of the domain controller, it's essential to follow this progression (in case you're just changing the IP address yet keeping it on a similar system you can avoid this).
Acive Directory uses characterized destinations and subnets for correspondence, replication, and different errands which work off camera. This guide discloses how to set them up.
Getting the fitting subnets set up in Active Directory is basic to guarantee the proceeded with solid activity of your condition. Include subnets varying and in any case twofold check to ensure everything is arranged as it ought to be. Try not to evacuate any destined to-be-resigned subnets (if appropriate) until they're really decommissioned, obviously.
3. Concentrate on DNS contemplations
DNS records are one of the absolute most significant factors in guaranteeing customers can speak with space controllers. At the point when you really change the IP address of the space controller the DNS records should refresh - as long as you are utilizing dynamic DNS - however static records should be physically balanced at the hour of cutover (whichever way you ought to affirm the fitting records are set up). Additionally try to check for some other static records relating to these hosts - and incorporate the forward just as converse DNS zones.
It may not be simply Active Directory DNS records you need to stress over; if your space controllers are giving DNS data to optional servers you have to look at the settings for those too to discover what may should be refreshed.
4. Check have records
Superficially it might sound ridiculous to stress over refreshing host records when DNS is such a great amount of simpler to oversee and utilize. In all honesty, have records are still especially being used, especially underway conditions - the most condemning of all - whereby a DNS disappointment can cause gigantic troubles.
In the event that you have handfuls or several conceivably affected frameworks, checking each machine's host record can be a dull procedure. You could utilize a basic Windows bunch document to deal with that (note you should have authoritative rights on the objective frameworks, the C: drive holds the Windows envelope and has been shared as C$).
Make an folder called c:\results.
Make a text file containing all the objective host names to check, at that point save it to c:\results\computers.txt.
save the document as c:\results\hostck.bat
Run c:\results\hostck.bat.
This will get to each focus on framework's host document at that point duplicate it to the c:\results organizer and name the record after the PC being referred to.
You would then be able to search the c:\results organizer for any pertinent IP delivers you may need to change, at that point do as such on the ideal objective frameworks varying. Clearly you would prefer not to do this until the genuine change has been made, and one simple strategy to do so is to refresh the host documents in the c:\results registry, at that point make a group record there called c:\results\hostupdt.bat with these substance.
5. Setup the board programming
Setup the executives programming, for example, Puppet or Chef may have the domain controller IP addresses/subnet hard-wired in some place, maybe even to produce have documents. It won't help you very much to change those host records if your design the executives customer is simply going to transform them back, so make a point to scan for the present IP locations of your space controllers
6. Guarantee virtual machine systems (if material) exist and are accessible
In case you're moving an domain controller to another subnet and it is a virtual machine, ensure the subnet exists in your virtual condition and is accessible to the hypervisor frameworks.
You won't really need to add this subnet to your virtual domain on the off chance that it only has customers which will speak with the domain controllers (that is the thing that your firewall rules should allow in step #1), however it might merit considering on the off chance that you expect to add frameworks which you'd prefer to talk legitimately to the domain controllers without managing firewall contemplations.
7. Create and execute your arrangement
Since the correct parts are set up, you can create and complete your arrangement. You ought to report the work to clients ahead of time and plan to do as such twilight when there will be the least effect.
Try to refresh each server in turn with the new system settings and make any ongoing changes varying, for example, arrangement programming changes, have document organizations or DNS record refreshes.
In the event that conceivable, screen arrange traffic during the transformation procedure to guarantee customers can speak with the server at it's new domain. You may take a stab at pinging it, running nslookup orders against it, getting to the server in Windows Explorer to affirm you can see the SYSVOL and NETLOGON shares, or in any event, closing down different DCs at that point affirming you can sign into the domain and access Active Directory assets.
When you have all your domain controllers exchanged over, ensure different frameworks which associate with them are working the manner in which they ought to be, for example, optional DNS servers. Affirm they are pulling down the zone documents from the DCs and in any case carrying on regularly.
In the event that issues emerge which can't be settled, you may need to return the DC to its unique system settings. Try not to stop for a second to do as such, yet ensure it's just an impermanent circumstance. Return to these means in that situation and research the indications/pieces of information, for example, blunders in the DC occasion logs to decide the following strategy to finish the venture.
No comments:
Post a Comment
What do you think about it