RE: [ActiveDir] Script to transfer FSMO roles.
Apparently some parts of ntdsutil are scriptable, see http://support.microsoft.com/?kbid=243267 . -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Bembridge Sent: Monday, February 13, 2006 1:52 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Script to transfer FSMO roles. Hi All, Can somebody point me in the right direction as to how to use a scripted solution for seizing the FSMO roles in case of a site failure? What we have is a W2K3 Domain, with two core sites and 60 branch offices. In the case of site 1 failing we want a procedure of activation a script so on the standby DC to seize the FSMO roles. Site 1 1 X DC Sch, Inf, DNM, PDC, GC 1 X DC RID, GC Site 2 1 X DC Standby FSMO role holder, GC 1 X DC GC Regards, Simon List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Script to transfer FSMO roles.
Title: [ActiveDir] Script to transfer FSMO roles. check out the thread on "W2K3 Std. vs. Ent. for DCs / x64" => Std. Edition is usually fine; mostly depends on your memory requirements for caching the DIT (AD Database) - best to go directly to Win2003x64 (especially if you happen to rollout new HW) /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Montag, 13. Februar 2006 23:02To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Dean All sounds good. We are creating a single domain, two core main sites with around 60 branch office world wide. Each core site has 2 X DC, will be W2K3 R2 once we get are heads around the new product. At first we are working with W2K3 SP1. DC will be Server Standard, Exch W2K3. A bit of citrix, and unix (Vintela for SSO) lots to think about. We are just doing a bit of AD proving at the moment and I will write up the FSMO transfer/seizure scenarios. Is their any really advantage over the server additions :- Standard vs Enterprise. My feeling and what I have seen in the past, that standard fits the build for a DC build. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean WellsSent: 13 February 2006 20:38To: Send - AD mailing listSubject: RE: [ActiveDir] Script to transfer FSMO roles. Not that's springing to mind. Some related thoughts - * inbound replication is single threaded (i.e. no concurrency limitation is required) * in 2k, 15 mins. represented the anticipated end-to-end replication within a site * the KCC in 2k3 is capable of load-balancing bridgeheads * the min. polled replication interval between DCs in different sites is 15 mins. * the KCC in 2k is limited; assuming ((domain+1) * sites^2) <=100,000 -- then all is good * the KCC in 2k3 is also limited but to a lesser extent; assuming ((domain+1) * sites) <=100,000 -- then all is good Assuming you have a single domain (or less than ~10 total domain & app. partitions combined), both Windows 2000 and Windows 2003 KCC/ISTGs will more than suffice. --Dean WellsMSEtechnology* Email: [EMAIL PROTECTED]http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Monday, February 13, 2006 3:04 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Yep I love spell checker, also have four kids running around the house at the moment ready for a pig out at TGI’s. I do not know why but I am sure I read somewhere that a bridgehead server had a threshold of 15 inbound replication partners. We have two core sites with 2 x DC in both and around 64 branch offices. We were going to let the KCC sort it all out for us but just have this niggling doubt about the 15 limit I am sure I read or dreamt somewhere. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean WellsSent: 13 February 2006 18:58To: Send - AD mailing listSubject: RE: [ActiveDir] Script to transfer FSMO roles. Can you elaborate on what you mean by "replication threshold" (or fresh hold if you prefer ... gotta love spell checkers :o)? --Dean WellsMSEtechnology* Email: [EMAIL PROTECTED]http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Monday, February 13, 2006 11:06 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, Yes it is a test environment we will be doing it in. So much going on. Also just a quick question, is there a Inbound – Outbound replication fresh hold for a site bridgehead server?? I have read somewhere that it is 15? Not sure how this has changed with R2 also as we are still awaiting the software to install and trial. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: 13 February 2006 12:45To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Are you saying"simulating the procedure in the production environment by seizing the FSMO roles" ? don't do that! use a test environment that is a correct representation of the production environment to do your tests! jorge From: [EMAIL PROTECTED] on behalf of Simon BembridgeSent: Mon 2006-02-13 13:26To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: 13 February 2006 10:09To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTE
RE: [ActiveDir] Script to transfer FSMO roles.
In hindsight, the same is true of the PDC regardless of whether it is seized or transferred so that's somewhat moot ... my scotch = my bad :O) -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Tuesday, February 14, 2006 10:41 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Script to transfer FSMO roles. Inline ... -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 7:57 PM To: ActiveDir@mail.activedir.org Cc: Send - AD mailing list Subject: RE: [ActiveDir] Script to transfer FSMO roles. >> That is not true, the schema and naming FSMOs also have extensive >> state that is sensitive and critical, however the frequency of the updates is significantly less, and thus less likely to cause an issue. - what's not true .. yes it is? :o) - schema FSMO, domain naming FSMO -- state? I guess this is a matter of perspective then ... personally, I don't consider an entire partition to be state (or a crossRef or an NC head or ...), they are IMO the result of a mostly controlled, single-mastered update not the state of the role holder that introduced the change(s). State, in this context, defines something particular to the role that indicates its position within a sequence of events ... or knowledge of what it did last time ... or information relevant to "what to do next" ... or ... >> Having personally been on PSS cases for people who've f-d up thier forest, because they didn't understand the concept of the F-Single-Master-O - nod, I imagine many have a sadly similar experience. >> and which data each is responsible for, I do not recommend seizing >> any roles except one. - neither do I ... but the need does arise (seizing I mean). That's not to say I advocate scripting it (per my original post) though scripting a transfer has, to date, been a non-issue. >> It is not good to conflict the NCs, hard to undo, and even worse to conflict the schema. - good point, most (including the relatively inexperienced) are aware of this (I hope). >>If you're a novice, here is what you should remember, IMNHO >> - Only the PDC is safe for seizing. - don't agree, for example - : think impact on BDCs ... they do still exist : timesync; most will forget the necessary reconfiguration : AOB >> - The infrastructure master is probably safe (I've never >>really thought it through enough to vouch for it). - I've seized it often (under test conditions) and occasionally in production = no problems or observed side effects of any kind. - Seizing any other role is a complicate process that will require learning of some DS internals, and a few steps. The process for seizure, should be A) Understand what data that FSMO owns, and think carefully if ANYONE has updated that data on a DC that is somehow unavailable to the forest at this moment, and could be brought back to the forest? a. If it could be brought back, you must then decide to not bring it back _EVER_, destroy the DC before seizure. Or bring it back and let it's changes replicate out. B) By seizing you can break the F-Single-Master-O model, and effectively have the potential to multi-mastered the data on more than one DCs, conflicting the data in a very bad way... C) Run repadmin /syncall to guarantee your forest has a consistent view of the data in question you want to seize. D) Finally perform the seizure, don't use a script, don't temp yourself with it. Use ntdsutil / dsmgmt. E) Finally, evaluate what you did to cause this seizure? Did you take down a box without properly demoting it? Institute an IT policy that allows for that mistake never to happen again, seizures should not be a part of any IT operation, unless you experienced critical hardware failure. >> Dean is right, it's the wrong place to fixup RID seizure in ntdsutil though, but I also think an LDAP modification performing a seizure, and a LDAP control for performing the more common transfer is ass backwards as well, so what do I know. - the seizure approach is odd IMO though the transfer approach makes sense (at least to me). I would also very much like to see all necessary related directory mods. made server-side. I wrote this mail in a hurry, so didn't proof it, probably mistakes ... BrettSh [msft] Building #7 Garage Door Operator On Mon, 13 Feb 2006, Dean Wells wrote: > Having chatted offline on this topic, I&#x
RE: [ActiveDir] Script to transfer FSMO roles.
Inline ... -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 7:57 PM To: ActiveDir@mail.activedir.org Cc: Send - AD mailing list Subject: RE: [ActiveDir] Script to transfer FSMO roles. >> That is not true, the schema and naming FSMOs also have extensive state that is sensitive and critical, however the frequency of the updates is significantly less, and thus less likely to cause an issue. - what's not true .. yes it is? :o) - schema FSMO, domain naming FSMO -- state? I guess this is a matter of perspective then ... personally, I don't consider an entire partition to be state (or a crossRef or an NC head or ...), they are IMO the result of a mostly controlled, single-mastered update not the state of the role holder that introduced the change(s). State, in this context, defines something particular to the role that indicates its position within a sequence of events ... or knowledge of what it did last time ... or information relevant to "what to do next" ... or ... >> Having personally been on PSS cases for people who've f-d up thier forest, because they didn't understand the concept of the F-Single-Master-O - nod, I imagine many have a sadly similar experience. >> and which data each is responsible for, I do not recommend seizing any roles except one. - neither do I ... but the need does arise (seizing I mean). That's not to say I advocate scripting it (per my original post) though scripting a transfer has, to date, been a non-issue. >> It is not good to conflict the NCs, hard to undo, and even worse to conflict the schema. - good point, most (including the relatively inexperienced) are aware of this (I hope). >>If you're a novice, here is what you should remember, IMNHO >> - Only the PDC is safe for seizing. - don't agree, for example - : think impact on BDCs ... they do still exist : timesync; most will forget the necessary reconfiguration : AOB >> - The infrastructure master is probably safe (I've never >>really thought it through enough to vouch for it). - I've seized it often (under test conditions) and occasionally in production = no problems or observed side effects of any kind. - Seizing any other role is a complicate process that will require learning of some DS internals, and a few steps. The process for seizure, should be A) Understand what data that FSMO owns, and think carefully if ANYONE has updated that data on a DC that is somehow unavailable to the forest at this moment, and could be brought back to the forest? a. If it could be brought back, you must then decide to not bring it back _EVER_, destroy the DC before seizure. Or bring it back and let it's changes replicate out. B) By seizing you can break the F-Single-Master-O model, and effectively have the potential to multi-mastered the data on more than one DCs, conflicting the data in a very bad way... C) Run repadmin /syncall to guarantee your forest has a consistent view of the data in question you want to seize. D) Finally perform the seizure, don't use a script, don't temp yourself with it. Use ntdsutil / dsmgmt. E) Finally, evaluate what you did to cause this seizure? Did you take down a box without properly demoting it? Institute an IT policy that allows for that mistake never to happen again, seizures should not be a part of any IT operation, unless you experienced critical hardware failure. >> Dean is right, it's the wrong place to fixup RID seizure in ntdsutil though, but I also think an LDAP modification performing a seizure, and a LDAP control for performing the more common transfer is ass backwards as well, so what do I know. - the seizure approach is odd IMO though the transfer approach makes sense (at least to me). I would also very much like to see all necessary related directory mods. made server-side. I wrote this mail in a hurry, so didn't proof it, probably mistakes ... BrettSh [msft] Building #7 Garage Door Operator On Mon, 13 Feb 2006, Dean Wells wrote: > Having chatted offline on this topic, I'm reminded that it's worth > mentioning an exception pertaining to the RID FSMO. Extensive state > is maintained for this particular role, state which is sensitive and > requires modification when the role is seized. Unfortunately, these > modifications are handled client-side by NTDSUTIL (a mistake in my > opinion), as such, any manual seizure of the RID Master should be > either conducted using NTDSUTIL (again, in a con
RE: [ActiveDir] Script to transfer FSMO roles.
That is not true, the schema and naming FSMOs also have extensive state that is sensitive and critical, however the frequency of the updates is significantly less, and thus less likely to cause an issue. Having personally been on PSS cases for people who've f-d up thier forest, because they didn't understand the concept of the F-Single-Master-O, and which data each is responsible for, I do not recommend seizing any roles except one. It is not good to conflict the NCs, hard to undo, and even worse to conflict the schema. If you're a novice, here is what you should remember, IMNHO - Only the PDC is safe for seizing. - The infrastructure master is probably safe (I've never really thought it through enough to vouch for it). - Seizing any other role is a complicate process that will require learning of some DS internals, and a few steps. The process for seizure, should be A) Understand what data that FSMO owns, and think carefully if ANYONE has updated that data on a DC that is somehow unavailable to the forest at this moment, and could be brought back to the forest? a. If it could be brought back, you must then decide to not bring it back _EVER_, destroy the DC before seizure. Or bring it back and let it's changes replicate out. B) By seizing you can break the F-Single-Master-O model, and effectively have the potential to multi-mastered the data on more than one DCs, conflicting the data in a very bad way... C) Run repadmin /syncall to guarantee your forest has a consistent view of the data in question you want to seize. D) Finally perform the seizure, don't use a script, don't temp yourself with it. Use ntdsutil / dsmgmt. E) Finally, evaluate what you did to cause this seizure? Did you take down a box without properly demoting it? Institute an IT policy that allows for that mistake never to happen again, seizures should not be a part of any IT operation, unless you experienced critical hardware failure. Dean is right, it's the wrong place to fixup RID seizure in ntdsutil though, but I also think an LDAP modification performing a seizure, and a LDAP control for performing the more common transfer is ass backwards as well, so what do I know. I wrote this mail in a hurry, so didn't proof it, probably mistakes ... BrettSh [msft] Building #7 Garage Door Operator On Mon, 13 Feb 2006, Dean Wells wrote: > Having chatted offline on this topic, I'm reminded that it's worth > mentioning an exception pertaining to the RID FSMO. Extensive state is > maintained for this particular role, state which is sensitive and requires > modification when the role is seized. Unfortunately, these modifications > are handled client-side by NTDSUTIL (a mistake in my opinion), as such, any > manual seizure of the RID Master should be either conducted using NTDSUTIL > (again, in a controlled manner) or supplemented with the necessary RID > allocation pool modifications. > -- > Dean Wells > MSEtechnology > * Email: dwells <mailto:[EMAIL PROTECTED]> @msetechnology.com > <http://msetechnology.com/> http://msetechnology.com > > > > _ > > From: Dean Wells [mailto:[EMAIL PROTECTED] > Sent: Monday, February 13, 2006 9:06 AM > To: Send - AD mailing list ([EMAIL PROTECTED]) > Subject: RE: [ActiveDir] Script to transfer FSMO roles. > > > A few thoughts -- > > I'm not entirely adverse to the idea of throwing commands at NTDSUTIL and > seizing roles (and relying upon the mandatory pre-emptive transfer attempt) > but I prefer not to perform such actions when the capability to trap > failures within a sequence of events is beyond my control, e.g. the transfer > fails and the seize continues without confirmation or regard for my input. > > Although I realize that your goal here is to seize a role, a single slip of > the finger may inadvertently cause seizure to occur. I would suggest > scripting the operation to _manually_ attempt a transfer first, trap the > error and confirm your intention to proceed with a seize (remains achievable > with NTDSUTIL). Of course, the implications of _not_ doing it this way are > entirely dependent upon either or both the FSMO role in question and/or your > particular infrastructure. > > The commands below outline an alternative approach for attempting a FSMO > transfer of the domain naming master - > > admod -h -b "" becomedomainmaster::1 > > ... and the equivalent seizure - > > admod -h -b cn=partitions,cn=configuration,dc= > fsmoroleowner::"" > > ... e.g. - > &
RE: [ActiveDir] Script to transfer FSMO roles.
Title: [ActiveDir] Script to transfer FSMO roles. Great, sounds like you're good to go! Re: W2K3 Standard vs. Enterprise: there's a mass of information concerning the feature differences and supported hardware, the following is as good a place as any to start - http://www.microsoft.com/windowsserver2003/default.mspx I have no concerns using Standard edition for DCs, I don't see it too often since the majority of my customers are licensed up the wazoo and use whatever ISO they stumble across first :o) --Dean WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Monday, February 13, 2006 5:02 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Dean All sounds good. We are creating a single domain, two core main sites with around 60 branch office world wide. Each core site has 2 X DC, will be W2K3 R2 once we get are heads around the new product. At first we are working with W2K3 SP1. DC will be Server Standard, Exch W2K3. A bit of citrix, and unix (Vintela for SSO) lots to think about. We are just doing a bit of AD proving at the moment and I will write up the FSMO transfer/seizure scenarios. Is their any really advantage over the server additions :- Standard vs Enterprise. My feeling and what I have seen in the past, that standard fits the build for a DC build. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean WellsSent: 13 February 2006 20:38To: Send - AD mailing listSubject: RE: [ActiveDir] Script to transfer FSMO roles. Not that's springing to mind. Some related thoughts - * inbound replication is single threaded (i.e. no concurrency limitation is required) * in 2k, 15 mins. represented the anticipated end-to-end replication within a site * the KCC in 2k3 is capable of load-balancing bridgeheads * the min. polled replication interval between DCs in different sites is 15 mins. * the KCC in 2k is limited; assuming ((domain+1) * sites^2) <=100,000 -- then all is good * the KCC in 2k3 is also limited but to a lesser extent; assuming ((domain+1) * sites) <=100,000 -- then all is good Assuming you have a single domain (or less than ~10 total domain & app. partitions combined), both Windows 2000 and Windows 2003 KCC/ISTGs will more than suffice. --Dean WellsMSEtechnology* Email: [EMAIL PROTECTED]http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Monday, February 13, 2006 3:04 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Yep I love spell checker, also have four kids running around the house at the moment ready for a pig out at TGI’s. I do not know why but I am sure I read somewhere that a bridgehead server had a threshold of 15 inbound replication partners. We have two core sites with 2 x DC in both and around 64 branch offices. We were going to let the KCC sort it all out for us but just have this niggling doubt about the 15 limit I am sure I read or dreamt somewhere. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean WellsSent: 13 February 2006 18:58To: Send - AD mailing listSubject: RE: [ActiveDir] Script to transfer FSMO roles. Can you elaborate on what you mean by "replication threshold" (or fresh hold if you prefer ... gotta love spell checkers :o)? --Dean WellsMSEtechnology* Email: [EMAIL PROTECTED]http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Monday, February 13, 2006 11:06 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, Yes it is a test environment we will be doing it in. So much going on. Also just a quick question, is there a Inbound – Outbound replication fresh hold for a site bridgehead server?? I have read somewhere that it is 15? Not sure how this has changed with R2 also as we are still awaiting the software to install and trial. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: 13 February 2006 12:45To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Are you saying"simulating the procedure in the production environment by seizing the FSMO roles" ? don't do that! use a test environment that is a correct representation of the production environment to do your tests! jorge From: [EMAIL PROTECTED] on behalf of Simon BembridgeSent: Mon 2006-02-13 13:26To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon
RE: [ActiveDir] Script to transfer FSMO roles.
Title: [ActiveDir] Script to transfer FSMO roles. Dean All sounds good. We are creating a single domain, two core main sites with around 60 branch office world wide. Each core site has 2 X DC, will be W2K3 R2 once we get are heads around the new product. At first we are working with W2K3 SP1. DC will be Server Standard, Exch W2K3. A bit of citrix, and unix (Vintela for SSO) lots to think about. We are just doing a bit of AD proving at the moment and I will write up the FSMO transfer/seizure scenarios. Is their any really advantage over the server additions :- Standard vs Enterprise. My feeling and what I have seen in the past, that standard fits the build for a DC build. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: 13 February 2006 20:38 To: Send - AD mailing list Subject: RE: [ActiveDir] Script to transfer FSMO roles. Not that's springing to mind. Some related thoughts - * inbound replication is single threaded (i.e. no concurrency limitation is required) * in 2k, 15 mins. represented the anticipated end-to-end replication within a site * the KCC in 2k3 is capable of load-balancing bridgeheads * the min. polled replication interval between DCs in different sites is 15 mins. * the KCC in 2k is limited; assuming ((domain+1) * sites^2) <=100,000 -- then all is good * the KCC in 2k3 is also limited but to a lesser extent; assuming ((domain+1) * sites) <=100,000 -- then all is good Assuming you have a single domain (or less than ~10 total domain & app. partitions combined), both Windows 2000 and Windows 2003 KCC/ISTGs will more than suffice. -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Bembridge Sent: Monday, February 13, 2006 3:04 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Yep I love spell checker, also have four kids running around the house at the moment ready for a pig out at TGI’s. I do not know why but I am sure I read somewhere that a bridgehead server had a threshold of 15 inbound replication partners. We have two core sites with 2 x DC in both and around 64 branch offices. We were going to let the KCC sort it all out for us but just have this niggling doubt about the 15 limit I am sure I read or dreamt somewhere. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: 13 February 2006 18:58 To: Send - AD mailing list Subject: RE: [ActiveDir] Script to transfer FSMO roles. Can you elaborate on what you mean by "replication threshold" (or fresh hold if you prefer ... gotta love spell checkers :o)? -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Bembridge Sent: Monday, February 13, 2006 11:06 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, Yes it is a test environment we will be doing it in. So much going on. Also just a quick question, is there a Inbound – Outbound replication fresh hold for a site bridgehead server?? I have read somewhere that it is 15? Not sure how this has changed with R2 also as we are still awaiting the software to install and trial. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 13 February 2006 12:45 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Are you saying"simulating the procedure in the production environment by seizing the FSMO roles" ? don't do that! use a test environment that is a correct representation of the production environment to do your tests! jorge From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 13:26 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 13 February 2006 10:09 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC"
RE: [ActiveDir] Script to transfer FSMO roles.
Title: [ActiveDir] Script to transfer FSMO roles. Not that's springing to mind. Some related thoughts - * inbound replication is single threaded (i.e. no concurrency limitation is required) * in 2k, 15 mins. represented the anticipated end-to-end replication within a site * the KCC in 2k3 is capable of load-balancing bridgeheads * the min. polled replication interval between DCs in different sites is 15 mins. * the KCC in 2k is limited; assuming ((domain+1) * sites^2) <=100,000 -- then all is good * the KCC in 2k3 is also limited but to a lesser extent; assuming ((domain+1) * sites) <=100,000 -- then all is good Assuming you have a single domain (or less than ~10 total domain & app. partitions combined), both Windows 2000 and Windows 2003 KCC/ISTGs will more than suffice. --Dean WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Monday, February 13, 2006 3:04 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Yep I love spell checker, also have four kids running around the house at the moment ready for a pig out at TGI’s. I do not know why but I am sure I read somewhere that a bridgehead server had a threshold of 15 inbound replication partners. We have two core sites with 2 x DC in both and around 64 branch offices. We were going to let the KCC sort it all out for us but just have this niggling doubt about the 15 limit I am sure I read or dreamt somewhere. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean WellsSent: 13 February 2006 18:58To: Send - AD mailing listSubject: RE: [ActiveDir] Script to transfer FSMO roles. Can you elaborate on what you mean by "replication threshold" (or fresh hold if you prefer ... gotta love spell checkers :o)? --Dean WellsMSEtechnology* Email: [EMAIL PROTECTED]http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Monday, February 13, 2006 11:06 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, Yes it is a test environment we will be doing it in. So much going on. Also just a quick question, is there a Inbound – Outbound replication fresh hold for a site bridgehead server?? I have read somewhere that it is 15? Not sure how this has changed with R2 also as we are still awaiting the software to install and trial. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: 13 February 2006 12:45To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Are you saying"simulating the procedure in the production environment by seizing the FSMO roles" ? don't do that! use a test environment that is a correct representation of the production environment to do your tests! jorge From: [EMAIL PROTECTED] on behalf of Simon BembridgeSent: Mon 2006-02-13 13:26To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: 13 February 2006 10:09To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge From: [EMAIL PROTECTED] on behalf of Simon BembridgeSent: Mon 2006-02-13 10:52To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Script to transfer FSMO roles. Hi All,Can somebody point me in the right direction as to how to use a scriptedsolution for seizing the FSMO roles in case of a site f
RE: [ActiveDir] Script to transfer FSMO roles.
Title: [ActiveDir] Script to transfer FSMO roles. Yep I love spell checker, also have four kids running around the house at the moment ready for a pig out at TGI’s. I do not know why but I am sure I read somewhere that a bridgehead server had a threshold of 15 inbound replication partners. We have two core sites with 2 x DC in both and around 64 branch offices. We were going to let the KCC sort it all out for us but just have this niggling doubt about the 15 limit I am sure I read or dreamt somewhere. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: 13 February 2006 18:58 To: Send - AD mailing list Subject: RE: [ActiveDir] Script to transfer FSMO roles. Can you elaborate on what you mean by "replication threshold" (or fresh hold if you prefer ... gotta love spell checkers :o)? -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Bembridge Sent: Monday, February 13, 2006 11:06 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, Yes it is a test environment we will be doing it in. So much going on. Also just a quick question, is there a Inbound – Outbound replication fresh hold for a site bridgehead server?? I have read somewhere that it is 15? Not sure how this has changed with R2 also as we are still awaiting the software to install and trial. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 13 February 2006 12:45 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Are you saying"simulating the procedure in the production environment by seizing the FSMO roles" ? don't do that! use a test environment that is a correct representation of the production environment to do your tests! jorge From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 13:26 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 13 February 2006 10:09 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 10:52 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Script to transfer FSMO roles. Hi All, Can somebody point me in the right direction as to how to use a scripted solution for seizing the FSMO roles in case of a site failure? What we have is a W2K3 Domain, with two core sites and 60 branch offices. In the case of site 1 failing we want a procedure of activation a script so on the standby DC to seize the FSMO roles. Site 1 1 X DC Sch, Inf, DNM, PDC, GC 1 X DC RID, GC Site 2 1 X DC Standby FSMO role holder, GC 1 X DC GC Regards, Simon List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
RE: [ActiveDir] Script to transfer FSMO roles.
Title: [ActiveDir] Script to transfer FSMO roles. Can you elaborate on what you mean by "replication threshold" (or fresh hold if you prefer ... gotta love spell checkers :o)? --Dean WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon BembridgeSent: Monday, February 13, 2006 11:06 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, Yes it is a test environment we will be doing it in. So much going on. Also just a quick question, is there a Inbound – Outbound replication fresh hold for a site bridgehead server?? I have read somewhere that it is 15? Not sure how this has changed with R2 also as we are still awaiting the software to install and trial. Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: 13 February 2006 12:45To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Are you saying"simulating the procedure in the production environment by seizing the FSMO roles" ? don't do that! use a test environment that is a correct representation of the production environment to do your tests! jorge From: [EMAIL PROTECTED] on behalf of Simon BembridgeSent: Mon 2006-02-13 13:26To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: 13 February 2006 10:09To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge From: [EMAIL PROTECTED] on behalf of Simon BembridgeSent: Mon 2006-02-13 10:52To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Script to transfer FSMO roles. Hi All,Can somebody point me in the right direction as to how to use a scriptedsolution for seizing the FSMO roles in case of a site failure?What we have is a W2K3 Domain, with two core sites and 60 branch offices. Inthe case of site 1 failing we want a procedure of activation a script so onthe standby DC to seize the FSMO roles.Site 11 X DC Sch, Inf, DNM, PDC, GC1 X DC RID, GCSite 21 X DC Standby FSMO role holder, GC1 X DC GCRegards, SimonList info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
RE: [ActiveDir] Script to transfer FSMO roles.
Title: [ActiveDir] Script to transfer FSMO roles. Having chatted offline on this topic, I'm reminded that it's worth mentioning an exception pertaining to the RID FSMO. Extensive state is maintained for this particular role, state which is sensitive and requires modification when the role is seized. Unfortunately, these modifications are handled client-side by NTDSUTIL (a mistake in my opinion), as such, any manual seizure of the RID Master should be either conducted using NTDSUTIL (again, in a controlled manner) or supplemented with the necessary RID allocation pool modifications. --Dean WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com From: Dean Wells [mailto:[EMAIL PROTECTED] Sent: Monday, February 13, 2006 9:06 AMTo: Send - AD mailing list ([EMAIL PROTECTED])Subject: RE: [ActiveDir] Script to transfer FSMO roles. A few thoughts -- I'm not entirely adverse to the idea of throwing commands at NTDSUTIL and seizing roles (and relying upon the mandatory pre-emptive transfer attempt) but I prefer not to perform such actions when the capability to trap failures within a sequence of events is beyond my control, e.g. the transfer fails and the seize continues without confirmation or regard for my input. Although I realize that your goal here is to seize a role, a single slip of the finger may inadvertently cause seizure to occur. I would suggest scripting the operation to _manually_ attempt a transfer first, trap the error and confirm your intention to proceed with a seize (remains achievable with NTDSUTIL). Of course, the implications of _not_ doing it this way are entirely dependent upon either or both the FSMO role in question and/or your particular infrastructure. The commands below outline an alternative approach for attempting a FSMO transfer of the domain naming master - admod -h -b "" becomedomainmaster::1 ... and the equivalent seizure - admod -h -b cn=partitions,cn=configuration,dc= fsmoroleowner::"" ... e.g. - admod -h machine1.adcorp.lan -b cn=partitions,cn=configuration,dc=adcorp,dc=lan fsmoroleowner::"CN=NTDS Settings,CN=MACHINE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=ADCORP,DC=LAN" This approach provides more control at the expense of requiring slightly more specific knowledge of the directory. --Dean WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: Monday, February 13, 2006 5:09 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge From: [EMAIL PROTECTED] on behalf of Simon BembridgeSent: Mon 2006-02-13 10:52To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Script to transfer FSMO roles. Hi All,Can somebody point me in the right direction as to how to use a scriptedsolution for seizing the FSMO roles in case of a site failure?What we have is a W2K3 Domain, with two core sites and 60 branch offices. Inthe case of site 1 failing we want a procedure of activation a script so onthe standby DC to seize the FSMO roles.Site 11 X DC Sch, Inf, DNM, PDC, GC1 X DC RID, GCSite 21 X DC Standby FSMO role holder, GC1 X DC GCRegards, SimonList info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
RE: [ActiveDir] Script to transfer FSMO roles.
Jorge, Yes it is a test environment we will be doing it in. So much going on. Also just a quick question, is there a Inbound - Outbound replication fresh hold for a site bridgehead server?? I have read somewhere that it is 15? Not sure how this has changed with R2 also as we are still awaiting the software to install and trial. Simon _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 13 February 2006 12:45 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Are you saying"simulating the procedure in the production environment by seizing the FSMO roles" ? don't do that! use a test environment that is a correct representation of the production environment to do your tests! jorge _ From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 13:26 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 13 February 2006 10:09 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge _ From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 10:52 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Script to transfer FSMO roles. Hi All, Can somebody point me in the right direction as to how to use a scripted solution for seizing the FSMO roles in case of a site failure? What we have is a W2K3 Domain, with two core sites and 60 branch offices. In the case of site 1 failing we want a procedure of activation a script so on the standby DC to seize the FSMO roles. Site 1 1 X DC Sch, Inf, DNM, PDC, GC 1 X DC RID, GC Site 2 1 X DC Standby FSMO role holder, GC 1 X DC GC Regards, Simon List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. <>
RE: [ActiveDir] Script to transfer FSMO roles.
Title: [ActiveDir] Script to transfer FSMO roles. A few thoughts -- I'm not entirely adverse to the idea of throwing commands at NTDSUTIL and seizing roles (and relying upon the mandatory pre-emptive transfer attempt) but I prefer not to perform such actions when the capability to trap failures within a sequence of events is beyond my control, e.g. the transfer fails and the seize continues without confirmation or regard for my input. Although I realize that your goal here is to seize a role, a single slip of the finger may inadvertently cause seizure to occur. I would suggest scripting the operation to _manually_ attempt a transfer first, trap the error and confirm your intention to proceed with a seize (remains achievable with NTDSUTIL). Of course, the implications of _not_ doing it this way are entirely dependent upon either or both the FSMO role in question and/or your particular infrastructure. The commands below outline an alternative approach for attempting a FSMO transfer of the domain naming master - admod -h -b "" becomedomainmaster::1 ... and the equivalent seizure - admod -h -b cn=partitions,cn=configuration,dc= fsmoroleowner::"" ... e.g. - admod -h machine1.adcorp.lan -b cn=partitions,cn=configuration,dc=adcorp,dc=lan fsmoroleowner::"CN=NTDS Settings,CN=MACHINE1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=ADCORP,DC=LAN" This approach provides more control at the expense of requiring slightly more specific knowledge of the directory. --Dean WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge deSent: Monday, February 13, 2006 5:09 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge From: [EMAIL PROTECTED] on behalf of Simon BembridgeSent: Mon 2006-02-13 10:52To: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Script to transfer FSMO roles. Hi All,Can somebody point me in the right direction as to how to use a scriptedsolution for seizing the FSMO roles in case of a site failure?What we have is a W2K3 Domain, with two core sites and 60 branch offices. Inthe case of site 1 failing we want a procedure of activation a script so onthe standby DC to seize the FSMO roles.Site 11 X DC Sch, Inf, DNM, PDC, GC1 X DC RID, GCSite 21 X DC Standby FSMO role holder, GC1 X DC GCRegards, SimonList info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
RE: [ActiveDir] Script to transfer FSMO roles.
Are you saying"simulating the procedure in the production environment by seizing the FSMO roles" ? don't do that! use a test environment that is a correct representation of the production environment to do your tests! jorge From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 13:26 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 13 February 2006 10:09 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 10:52 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Script to transfer FSMO roles. Hi All, Can somebody point me in the right direction as to how to use a scripted solution for seizing the FSMO roles in case of a site failure? What we have is a W2K3 Domain, with two core sites and 60 branch offices. In the case of site 1 failing we want a procedure of activation a script so on the standby DC to seize the FSMO roles. Site 1 1 X DC Sch, Inf, DNM, PDC, GC 1 X DC RID, GC Site 2 1 X DC Standby FSMO role holder, GC 1 X DC GC Regards, Simon List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. <>
RE: [ActiveDir] Script to transfer FSMO roles.
Jorge, If we are simulating a DR scenario running the script on the backup FSMO serve in site 2 will not be a problem?? Simon _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: 13 February 2006 10:09 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Script to transfer FSMO roles. run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge _ From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 10:52 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Script to transfer FSMO roles. Hi All, Can somebody point me in the right direction as to how to use a scripted solution for seizing the FSMO roles in case of a site failure? What we have is a W2K3 Domain, with two core sites and 60 branch offices. In the case of site 1 failing we want a procedure of activation a script so on the standby DC to seize the FSMO roles. Site 1 1 X DC Sch, Inf, DNM, PDC, GC 1 X DC RID, GC Site 2 1 X DC Standby FSMO role holder, GC 1 X DC GC Regards, Simon List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. <>
RE: [ActiveDir] Script to transfer FSMO roles.
run the script on the DC that should host the FSMO role(s) or replace %COMPUTERNAME% with %1 and use the name of the new FSMO role holder as an argument. Make sure to adjust the script concerning the FSMO roles that should be seized/transfered --> Seize-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize infrastructure master" "Seize RID master" "Seize PDC" QUIT QUIT --> Seize-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Seize domain naming master" "Seize schema master" QUIT QUIT --> Transfer-Domain-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer infrastructure master" "Transfer RID master" "Transfer PDC" QUIT QUIT --> Transfer-Forest-FSMO-Roles.cmd NTDSUTIL ROLES CONNECTIONS "CONNECT TO SERVER %COMPUTERNAME%" QUIT "Transfer domain naming master" "Transfer schema master" QUIT QUIT cheers, Jorge From: [EMAIL PROTECTED] on behalf of Simon Bembridge Sent: Mon 2006-02-13 10:52 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Script to transfer FSMO roles. Hi All, Can somebody point me in the right direction as to how to use a scripted solution for seizing the FSMO roles in case of a site failure? What we have is a W2K3 Domain, with two core sites and 60 branch offices. In the case of site 1 failing we want a procedure of activation a script so on the standby DC to seize the FSMO roles. Site 1 1 X DC Sch, Inf, DNM, PDC, GC 1 X DC RID, GC Site 2 1 X DC Standby FSMO role holder, GC 1 X DC GC Regards, Simon List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. <>
