Operations master roles
Changes like this typically make me nervous. The help files I have found are very clear, and the solution seems just as clear, but the consequences of being wrong are extreem.
Basically, I have a small AD forest with several servers, two of which are Domain Controllers. DC1, now holds all of the typical roles AD uses: Schema Master, Domain Naming master, RID, PDC emulator master and Infrastructure master.
According to my research, the Infrastructure master should never be on the same DC as the Global catalog unless there is only one DC. In my case, I have two DC's on one domain (the only Domain I have for now), with another comming online in a new domain in the same forest. So, this will be one forest, two domains, the root with the two original DC's mentioned above, and the third DC in the proposed domain, now in testing.
My logical conclusion is that, as I move into adding and testing this new domain, I really ought to move the Infreatructure master over to DC2 in the Root domain.
My only real problem here is... to me this is a big scary thing! I envision system wide failure, total loss of communication and me looking for a new job all because I messed with something that, by the books seems easy, but I have never done before and don't fix what ain't broke! .
...But the adult in me says: this is all nonsence. I am sure it is a seamless process that can be done without a hitch and infact should be done because it is the right way to go.
This brings me to you...
Should I move the Infrastructure Master role?
If I do, will it cause any problems, interuptions or require a reboot of my major systems once I select "OK"?
As far as I can tell, my AD network seems to be working fine so, once I bring the new Domain on line, how important is this recomended move?
Thanks in advance...
Basically, I have a small AD forest with several servers, two of which are Domain Controllers. DC1, now holds all of the typical roles AD uses: Schema Master, Domain Naming master, RID, PDC emulator master and Infrastructure master.
According to my research, the Infrastructure master should never be on the same DC as the Global catalog unless there is only one DC. In my case, I have two DC's on one domain (the only Domain I have for now), with another comming online in a new domain in the same forest. So, this will be one forest, two domains, the root with the two original DC's mentioned above, and the third DC in the proposed domain, now in testing.
My logical conclusion is that, as I move into adding and testing this new domain, I really ought to move the Infreatructure master over to DC2 in the Root domain.
My only real problem here is... to me this is a big scary thing! I envision system wide failure, total loss of communication and me looking for a new job all because I messed with something that, by the books seems easy, but I have never done before and don't fix what ain't broke! .
...But the adult in me says: this is all nonsence. I am sure it is a seamless process that can be done without a hitch and infact should be done because it is the right way to go.
This brings me to you...
Should I move the Infrastructure Master role?
If I do, will it cause any problems, interuptions or require a reboot of my major systems once I select "OK"?
As far as I can tell, my AD network seems to be working fine so, once I bring the new Domain on line, how important is this recomended move?
Thanks in advance...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
mkline71 is correct as usual.
You should make both DCs a GC.
There's no reason for you to make and FMSO transfer especially if your AD network is working fine.
Since you are planning to ahve another domain in the same forest, you still don't have to move any FSMO, unless you are planning to take down your root DC for maintenance and wants to fully operations during the maintenance window. But most of the time, you do not need to do anything.
Here's some info regarding FSMO and if you keep these in mind, it would help:
Every forest must have the following roles:
· Schema master
· Domain naming master
These roles must be unique in the forest. This means that throughout the entire forest there can be only one schema master and one domain naming master.
Every domain in the forest must have the following roles:
· Relative ID (RID) master
· Primary domain controller (PDC) emulator master
· Infrastructure master
These roles must be unique in each domain. This means that each domain in the forest can have only one RID master, PDC emulator master, and infrastructure master.
Some info on when to seize the FSMO:
If an operations master is not available due to computer failure or network problems, you can seize the operations master role. This is also referred to as forcing the transfer of the operations master role. Do not seize the operations master role if you can transfer it instead. Before forcing the transfer, first determine the cause and expected duration of the computer or network failure. If the cause is a networking problem or a server failure that will be resolved soon, wait for the role holder to become available again. If the domain controller that currently holds the role has failed, you must determine if it can be recovered and brought back online.
Responding to FSMO failures
If an operations master is not available due to computer failure or network problems, you can seize the operations master role. This is also referred to as forcing the transfer of the operations master role. Do not seize the operations master role if you can transfer it instead. For more information, see Transferring operations master roles.
Before forcing the transfer, first determine the cause and expected duration of the computer or network failure. If the cause is a networking problem or a server failure that will be resolved soon, wait for the role holder to become available again. If the domain controller that currently holds the role has failed, you must determine if it can be recovered and brought back online.
In general, seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again. The decision depends upon the role and how long the particular role holder will be unavailable. The impact of various role holder failures is discussed in the following topics.
Schema master Temporary loss of the schema master is not visible to network users. It will not be visible to network administrators either, unless they are trying to modify the schema or install an application that modifies the schema during installation.
If the schema master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the schema master is permanent.
Important: A domain controller whose schema master role has been seized must never be brought back online.
For procedures on how to seize the schema master role, see To seize the schema master role under Help of Active Directory Users and Computers.
Domain naming master Temporary loss of the domain naming master is not visible to network users. It will not be visible to network administrators either, unless they are trying to add a domain to the forest or remove a domain from the forest.
If the domain naming master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the domain naming master is permanent.
Important: A domain controller whose domain naming master role has been seized must never be brought back online.
For procedures on how to seize the domain naming master role, see To seize the domain naming master role under Help of Active Directory Users and Computers.
RID master Temporary loss of the RID master is not visible to network users. It will not be visible to network administrators either, unless they are creating objects and the domain in which they are creating the objects runs out of relative IDs (RIDs).
If the RID master will be unavailable for an unacceptable length of time, you can seize the role to the operations master. However, seizing this role is a drastic step that you should take only when the failure of the RID master is permanent.
Important: A domain controller whose RID master role has been seized must never be brought back online.
For procedures on how to seize the RID master role, see To seize the RID master role under Help of Active Directory Users and Computers under Help of Active Directory Users and Computers.
PDC emulator master The loss of the primary domain controller (PDC) emulator master affects network users. Therefore, when the PDC emulator master is not available, you may need to immediately seize the role.
If the current PDC emulator master will be unavailable for an unacceptable length of time and its domain has clients without Windows 2000 client software, or if it contains Windows NT backup domain controllers, seize the PDC emulator master role to the standby operations master. When the original PDC emulator master is returned to service, you can return the role to the original domain controller.
For procedures on how to seize the PDC emulator role, see To seize the PDC emulator role under Help of Active Directory Users and Computers under Help of Active Directory Users and Computers.
Infrastructure master Temporary loss of the infrastructure master is not visible to network users. It will not be visible to network administrators either, unless they have recently moved or renamed a large number of accounts.
If the infrastructure master will be unavailable for an unacceptable length of time, you can seize the role to a domain controller that is not a global catalog but is well connected to a global catalog (from any domain), ideally in the same site as the current global catalog. When the original infrastructure master is returned to service, you can transfer the role back to the original domain controller.
For procedures on how to seize the infrastructure master role, see To seize the infrastructure master role under Help of Active Directory Users and Computers under Help of Active Directory Users and Computers.
In general, seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again. The decision depends upon the role and how long the particular role holder will be unavailable.
You should make both DCs a GC.
There's no reason for you to make and FMSO transfer especially if your AD network is working fine.
Since you are planning to ahve another domain in the same forest, you still don't have to move any FSMO, unless you are planning to take down your root DC for maintenance and wants to fully operations during the maintenance window. But most of the time, you do not need to do anything.
Here's some info regarding FSMO and if you keep these in mind, it would help:
Every forest must have the following roles:
· Schema master
· Domain naming master
These roles must be unique in the forest. This means that throughout the entire forest there can be only one schema master and one domain naming master.
Every domain in the forest must have the following roles:
· Relative ID (RID) master
· Primary domain controller (PDC) emulator master
· Infrastructure master
These roles must be unique in each domain. This means that each domain in the forest can have only one RID master, PDC emulator master, and infrastructure master.
Some info on when to seize the FSMO:
If an operations master is not available due to computer failure or network problems, you can seize the operations master role. This is also referred to as forcing the transfer of the operations master role. Do not seize the operations master role if you can transfer it instead. Before forcing the transfer, first determine the cause and expected duration of the computer or network failure. If the cause is a networking problem or a server failure that will be resolved soon, wait for the role holder to become available again. If the domain controller that currently holds the role has failed, you must determine if it can be recovered and brought back online.
Responding to FSMO failures
If an operations master is not available due to computer failure or network problems, you can seize the operations master role. This is also referred to as forcing the transfer of the operations master role. Do not seize the operations master role if you can transfer it instead. For more information, see Transferring operations master roles.
Before forcing the transfer, first determine the cause and expected duration of the computer or network failure. If the cause is a networking problem or a server failure that will be resolved soon, wait for the role holder to become available again. If the domain controller that currently holds the role has failed, you must determine if it can be recovered and brought back online.
In general, seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again. The decision depends upon the role and how long the particular role holder will be unavailable. The impact of various role holder failures is discussed in the following topics.
Schema master Temporary loss of the schema master is not visible to network users. It will not be visible to network administrators either, unless they are trying to modify the schema or install an application that modifies the schema during installation.
If the schema master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the schema master is permanent.
Important: A domain controller whose schema master role has been seized must never be brought back online.
For procedures on how to seize the schema master role, see To seize the schema master role under Help of Active Directory Users and Computers.
Domain naming master Temporary loss of the domain naming master is not visible to network users. It will not be visible to network administrators either, unless they are trying to add a domain to the forest or remove a domain from the forest.
If the domain naming master will be unavailable for an unacceptable length of time, you can seize the role to the standby operations master. However, seizing this role is a drastic step that you should take only when the failure of the domain naming master is permanent.
Important: A domain controller whose domain naming master role has been seized must never be brought back online.
For procedures on how to seize the domain naming master role, see To seize the domain naming master role under Help of Active Directory Users and Computers.
RID master Temporary loss of the RID master is not visible to network users. It will not be visible to network administrators either, unless they are creating objects and the domain in which they are creating the objects runs out of relative IDs (RIDs).
If the RID master will be unavailable for an unacceptable length of time, you can seize the role to the operations master. However, seizing this role is a drastic step that you should take only when the failure of the RID master is permanent.
Important: A domain controller whose RID master role has been seized must never be brought back online.
For procedures on how to seize the RID master role, see To seize the RID master role under Help of Active Directory Users and Computers under Help of Active Directory Users and Computers.
PDC emulator master The loss of the primary domain controller (PDC) emulator master affects network users. Therefore, when the PDC emulator master is not available, you may need to immediately seize the role.
If the current PDC emulator master will be unavailable for an unacceptable length of time and its domain has clients without Windows 2000 client software, or if it contains Windows NT backup domain controllers, seize the PDC emulator master role to the standby operations master. When the original PDC emulator master is returned to service, you can return the role to the original domain controller.
For procedures on how to seize the PDC emulator role, see To seize the PDC emulator role under Help of Active Directory Users and Computers under Help of Active Directory Users and Computers.
Infrastructure master Temporary loss of the infrastructure master is not visible to network users. It will not be visible to network administrators either, unless they have recently moved or renamed a large number of accounts.
If the infrastructure master will be unavailable for an unacceptable length of time, you can seize the role to a domain controller that is not a global catalog but is well connected to a global catalog (from any domain), ideally in the same site as the current global catalog. When the original infrastructure master is returned to service, you can transfer the role back to the original domain controller.
For procedures on how to seize the infrastructure master role, see To seize the infrastructure master role under Help of Active Directory Users and Computers under Help of Active Directory Users and Computers.
In general, seizing an operations master role is a drastic step that should be considered only if the current operations master will never be available again. The decision depends upon the role and how long the particular role holder will be unavailable.
ASKER
OK...
So how do I make DC2 a Global catalog?
So how do I make DC2 a Global catalog?
http://www.petri.co.il/con
It is in sites and services, step by step instructions are above.
Thanks
Mike
It is in sites and services, step by step instructions are above.
Thanks
Mike
ASKER
OK...
Not to be a trouble maker or anything...
But the article you referenced clearly says:
However, your reference raises this obvious question?
Thanks
Not to be a trouble maker or anything...
But the article you referenced clearly says:
I'm not apposed to your solution; infact, I know I am better off for asking and getting your responce.
"Configuring an excessive number of GCs in a domain wastes network bandwidth during replication. One GC server per domain in each physical location is sufficient. Windows NT sets servers as GCs as necessary, so you dont need to configure additional GCs unless you notice slow query response times."
However, your reference raises this obvious question?
Thanks
You are not being a pain.
That says excessive number of GC's and you won't run into that.
What is the speed between your DC's? Are they on the same LAN.
The big advantage for you is if DC1 goes down then non-admin users won't be able to login because DC2 is not a GC.
Thanks
Mike
That says excessive number of GC's and you won't run into that.
What is the speed between your DC's? Are they on the same LAN.
The big advantage for you is if DC1 goes down then non-admin users won't be able to login because DC2 is not a GC.
Thanks
Mike
Unless your AD database is huge, I don't believe so. Most of the doucmentation are referring to a very large network with large database and small bandwidth...
Having an extra DC will not increase the size of your AD much..if both DCs are in the same location, replication should not be a problem, even the are not, it still shouldn't be a problem. Again, unless your AD is big and WNA link is tiny.
Having an extra DC will not increase the size of your AD much..if both DCs are in the same location, replication should not be a problem, even the are not, it still shouldn't be a problem. Again, unless your AD is big and WNA link is tiny.
exactly, the advantage or redundancy etc is way over the replication speed in most environment with decent WAN link.
ASKER
DC1 and DC2 are the same LAN
"Testing" DC3 will for now be connected to the same switch, seperated by a VLAN and subnet configured on my HP Procurve 5308xl
Once it is finished it will be moved to my Wisconsin office and will be, again another subnet, connected by:
"Testing" DC3 will for now be connected to the same switch, seperated by a VLAN and subnet configured on my HP Procurve 5308xl
Once it is finished it will be moved to my Wisconsin office and will be, again another subnet, connected by:
- T1 in Chicago, using a PPTP VPN connected to Wisconsin's Router.
- ADSL (1.5 Down, 256 Up) in Wisconsin, also a PPTP VPN; the other end of the Chicago connection.
DC3 will be a DC for a new domain so that one will have to be a GC anyway. Your speeds are fine.
On another note when you get some more money in the budget it is highly recommended that you add a DC4 (second domain controller in new domain).
Reason being you should try and have at least two domain controllers for each domain. Just in case the worst case happens and a DC died then having that second DC can really save you.
Thanks
MIke
On another note when you get some more money in the budget it is highly recommended that you add a DC4 (second domain controller in new domain).
Reason being you should try and have at least two domain controllers for each domain. Just in case the worst case happens and a DC died then having that second DC can really save you.
Thanks
MIke
ASKER
Yes, I agree about the second DC; especally seeing as how the DC I am putting in Wisconsin is kinda old... You gotta start someplace!
So, IN digest:
So, IN digest:
- I will make DC2 a GC
- DC3 will be a GC for its own domain
- All will be right with the world!
Lastly, you may even find any box to have a DC4 for the new domain before putting in production as you said DC3 is old. This will get you cover from losing DC3. Or at least ensure a GOOD backup of the box daily
1 and 2 are both great
...all will be right in the world once we get this economy on track :)
...all will be right in the world once we get this economy on track :)
http://msmvps.com/blogs/ul
Thanks
Mike