SBS2003 | Windows Server 2008 - Exchange 2007
|
From: Ace Fekay [MCT] on 15 Oct 2009 19:30 "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message news:OKmQOteTKHA.764(a)TK2MSFTNGP02.phx.gbl... > D, > > I think that I understand SBS2003 and SBS2008 plenty well....but that is > okay. I do not take offense to what you are saying... > > A couple of things that I noted: > > 1) you can indeed have multiple Domain Controllers in an SBS environment. > Shoot, you can have an additional 25 if you wanted. You just need to make > sure that you maintain the following: > A) that the SBS box holds all five FSMO Roles > B) that the SBS box is a Global Catalog Server > C) that - if we are talking SBS2008 - the SBS box is a DHCP > Server > > 2) You most certainly can have additional Exchange Servers | MS SQL > Servers in an SBS environment. You just have to purchase the additional > software and appropriate number of CALs as the second MS Exchange or MS > SQL would clearly not be covered by the SBS CALs. Have it in many > environments. Generally, the question is why would you do such a > thing....and, generally, the answer is that you are going to be migrating > to 'normal' Windows (or, that there are sever performance issues). We > have, for example, in two environments SBS2003 Standard but have a second > Exchange Server (Exchange 2003 in both cases). In another environment, we > have SBS2003 Premium but have MS SQL 2005 on another box. In all cases > everything works very very well. You do not *move* anything....you simply > do not use the services on the SBS2003 box. Naturally, you would need to > move the mailboxes (if we are talking about Exchange) or migrate the data > (if we are talking about SQL or SharePoint). > > 3) Trusts - agreed. The SBS box has to be the "main" domain controller in > the forest root. You *MUST* have a single domain/tree/forest environment > as there is no possibility of a trust. Well, there are a couple of > exceptions, like when you are moving SBS2003 to new hardware or when you > are moving SBS2003 to SBS2008 (you install SBS2008 in Migration Mode and > have 21 days to complete everything....actually going to be doing this in > a couple of weeks). But, there can not be a child domain or another tree > in your SBS forest..... > > 4) Transition Pack - went away one year ago (okay, actually 10 months ago) > so that is not an option anymore. > > 5) Pretty sure that you mean SBS Premium.....not SBS Advanced (if we are > getting technical here....which apparently we are). > > 6) Exchange on a DC - always a concern. Why? You are very limited in > what you can do. You can not run dcpromo on that box (okay...agreed,,,if > you are doing that on an SBS box then running Exchange on a Domain > Controller is the least of your concerns at that particular moment). If > you do have an environment where you do have multiple Domain Controllers | > Global Catalog Servers then MS Exchange - because it is installed on a > DC - will only make use of *THAT* DC | GC (DSProxy and DSAccess). So, if > that DC | GC is down.......again, if the SBS box is down then you do not > really care about whether or not Exchange is on a DC or not and which DCs > \ GCs it *could* possibly use...but it is still a concern. Also, > store.exe consumes a TON of RAM. And, if we are talking about SBS2003 > Premium, then having MS Exchange 2003 and MS SQL 2000 | MS SQL 2005 > running on the same box is a *HUGE* concern [think RAM....32-bit is > limited to 4GB....we have a couple of SBS 2003 Premium environments where > they have 150MB of available RAM at any given point because MS SQL is > taking up a ton of RAM (use MS SQL based applications that are RAM > Resource HOGS) and MS Exchange is taking up a ton of RAM....]. > > 7) Totally disagree with the last paragraph....have done it (well, Windows > Server 2003....no Windows Server 2008 as you indicate....) a couple of > times....in fact, we still manage an environment where we went from > SBS2003 to "normal" Windows 2003 | Exchange 2003. In that environment we > did not use the Transition Pack. Same in at least one other. And, we > have gone through that same process, only we did indeed make use of the > Transition Pack. > > In fact, in the environment where we did not use the transition > pack....several of the SBS features are still available. And, are being > used this very day. > > So, while it is fair that you state that my root issue is that I do not > understand SBS it is also fair that I disagree with your statement. But, > again, no offense taken. > Just thought to add the following... 1) b). I know you already knew this, but didn't explicitly state it. I just wanted to point out to others that since this is one domain, all DCs that are added as replicas into the SBS domain, should be GCs. Only exception to the rule is if there are multiple domains in the forest, which doesn't apply to SBS anyway. 6) Exchange on a DC: I agree, in a non-SBS environment, Exchange on a DC is the worst thing. Besides the store.exe process being eaten up and the DSAccess and DSProxy locked to itself for the GC (and if the AD services fail on the DC, Exchange flounders, even if there are other DCs/GCs), we can't forget that on a DC, the write-back cache is disabled in support of the transactional database method that AD uses. However, Exchange's transactional process is different, and relies on the write-cache being enabled. The result is a possible loss of emails if an issue were to occur such as a sudden power down of the DC/Exchange server. AD database will be ok, but the Exchange database *may* lose data. However, SBS was designed to work around this isssue. Same with SQL on it. I know I am referencing information from "big server land," and some folks here will definitely remind me of that, but the rules still apply with all DCs being a GC in a single domain, whether big server land or SBS! Cheers! :-) Ace
From: Cary Shultz on 15 Oct 2009 19:56 Ace, in-line..... "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message news:%23uJw29eTKHA.764(a)TK2MSFTNGP02.phx.gbl... > "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message > news:OKmQOteTKHA.764(a)TK2MSFTNGP02.phx.gbl... >> D, >> >> I think that I understand SBS2003 and SBS2008 plenty well....but that is >> okay. I do not take offense to what you are saying... >> >> A couple of things that I noted: >> >> 1) you can indeed have multiple Domain Controllers in an SBS environment. >> Shoot, you can have an additional 25 if you wanted. You just need to >> make sure that you maintain the following: >> A) that the SBS box holds all five FSMO Roles >> B) that the SBS box is a Global Catalog Server >> C) that - if we are talking SBS2008 - the SBS box is a >> DHCP Server >> >> 2) You most certainly can have additional Exchange Servers | MS SQL >> Servers in an SBS environment. You just have to purchase the additional >> software and appropriate number of CALs as the second MS Exchange or MS >> SQL would clearly not be covered by the SBS CALs. Have it in many >> environments. Generally, the question is why would you do such a >> thing....and, generally, the answer is that you are going to be migrating >> to 'normal' Windows (or, that there are sever performance issues). We >> have, for example, in two environments SBS2003 Standard but have a second >> Exchange Server (Exchange 2003 in both cases). In another environment, >> we have SBS2003 Premium but have MS SQL 2005 on another box. In all >> cases everything works very very well. You do not *move* anything....you >> simply do not use the services on the SBS2003 box. Naturally, you would >> need to move the mailboxes (if we are talking about Exchange) or migrate >> the data (if we are talking about SQL or SharePoint). >> >> 3) Trusts - agreed. The SBS box has to be the "main" domain controller >> in the forest root. You *MUST* have a single domain/tree/forest >> environment as there is no possibility of a trust. Well, there are a >> couple of exceptions, like when you are moving SBS2003 to new hardware or >> when you are moving SBS2003 to SBS2008 (you install SBS2008 in Migration >> Mode and have 21 days to complete everything....actually going to be >> doing this in a couple of weeks). But, there can not be a child domain >> or another tree in your SBS forest..... >> >> 4) Transition Pack - went away one year ago (okay, actually 10 months >> ago) so that is not an option anymore. >> >> 5) Pretty sure that you mean SBS Premium.....not SBS Advanced (if we are >> getting technical here....which apparently we are). >> >> 6) Exchange on a DC - always a concern. Why? You are very limited in >> what you can do. You can not run dcpromo on that box (okay...agreed,,,if >> you are doing that on an SBS box then running Exchange on a Domain >> Controller is the least of your concerns at that particular moment). If >> you do have an environment where you do have multiple Domain Controllers >> | Global Catalog Servers then MS Exchange - because it is installed on a >> DC - will only make use of *THAT* DC | GC (DSProxy and DSAccess). So, if >> that DC | GC is down.......again, if the SBS box is down then you do not >> really care about whether or not Exchange is on a DC or not and which DCs >> \ GCs it *could* possibly use...but it is still a concern. Also, >> store.exe consumes a TON of RAM. And, if we are talking about SBS2003 >> Premium, then having MS Exchange 2003 and MS SQL 2000 | MS SQL 2005 >> running on the same box is a *HUGE* concern [think RAM....32-bit is >> limited to 4GB....we have a couple of SBS 2003 Premium environments where >> they have 150MB of available RAM at any given point because MS SQL is >> taking up a ton of RAM (use MS SQL based applications that are RAM >> Resource HOGS) and MS Exchange is taking up a ton of RAM....]. >> >> 7) Totally disagree with the last paragraph....have done it (well, >> Windows Server 2003....no Windows Server 2008 as you indicate....) a >> couple of times....in fact, we still manage an environment where we went >> from SBS2003 to "normal" Windows 2003 | Exchange 2003. In that >> environment we did not use the Transition Pack. Same in at least one >> other. And, we have gone through that same process, only we did indeed >> make use of the Transition Pack. >> >> In fact, in the environment where we did not use the transition >> pack....several of the SBS features are still available. And, are being >> used this very day. >> >> So, while it is fair that you state that my root issue is that I do not >> understand SBS it is also fair that I disagree with your statement. But, >> again, no offense taken. >> > > Just thought to add the following... > > 1) b). I know you already knew this, but didn't explicitly state it. I > just wanted to point out to others that since this is one domain, all DCs > that are added as replicas into the SBS domain, should be GCs. Only > exception to the rule is if there are multiple domains in the forest, > which doesn't apply to SBS anyway. Correct.....all DCs generally speaking should also be DCs. The one caveat to that is if you have multiple domains (which we have clearly established is not possible in SBS-land...) then the DC that holds the Domain-wide DSMO Role of Infrastructure Master [there are two Forest-wide FSMO Roles (Schema Master and Domain Naming Master) and there are three Domain-wide FSMO Roles (PDC Emulator, RISD Master and Infratructure Master)...so, if you had four domains in the forest you would have 14 roles - the two Forest-wide and then the three Domain-wide for each of the four Domains...12 + 2 = 14] should not be a GC...and that is because of the Phantom Objects issue. However, unless I am terribly mistaken if all of the Domain Controllers in the entire Forest are GCs as well then there is no concern with the Phantom Objects issue. > 6) Exchange on a DC: I agree, in a non-SBS environment, Exchange on a DC > is the worst thing. Besides the store.exe process being eaten up and the > DSAccess and DSProxy locked to itself for the GC (and if the AD services > fail on the DC, Exchange flounders, even if there are other DCs/GCs), we > can't forget that on a DC, the write-back cache is disabled in support of > the transactional database method that AD uses. However, Exchange's > transactional process is different, and relies on the write-cache being > enabled. The result is a possible loss of emails if an issue were to occur > such as a sudden power down of the DC/Exchange server. AD database will be > ok, but the Exchange database *may* lose data. However, SBS was designed > to work around this isssue. Same with SQL on it. Agreed. Well stated. > > I know I am referencing information from "big server land," and some folks > here will definitely remind me of that, but the rules still apply with all > DCs being a GC in a single domain, whether big server land or SBS! > > Cheers! > > :-) > > Ace > > >
From: Ace Fekay [MCT] on 15 Oct 2009 20:44 In-line, as well... "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message news:uKhGwMfTKHA.1280(a)TK2MSFTNGP04.phx.gbl... > Ace, in-line..... > > "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message > news:%23uJw29eTKHA.764(a)TK2MSFTNGP02.phx.gbl... >> "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message >> news:OKmQOteTKHA.764(a)TK2MSFTNGP02.phx.gbl... >>> D, >>> >>> I think that I understand SBS2003 and SBS2008 plenty well....but that is >>> okay. I do not take offense to what you are saying... >>> >>> A couple of things that I noted: >>> >>> 1) you can indeed have multiple Domain Controllers in an SBS >>> environment. Shoot, you can have an additional 25 if you wanted. You >>> just need to make sure that you maintain the following: >>> A) that the SBS box holds all five FSMO Roles >>> B) that the SBS box is a Global Catalog Server >>> C) that - if we are talking SBS2008 - the SBS box is a >>> DHCP Server >>> >>> 2) You most certainly can have additional Exchange Servers | MS SQL >>> Servers in an SBS environment. You just have to purchase the additional >>> software and appropriate number of CALs as the second MS Exchange or MS >>> SQL would clearly not be covered by the SBS CALs. Have it in many >>> environments. Generally, the question is why would you do such a >>> thing....and, generally, the answer is that you are going to be >>> migrating to 'normal' Windows (or, that there are sever performance >>> issues). We have, for example, in two environments SBS2003 Standard but >>> have a second Exchange Server (Exchange 2003 in both cases). In another >>> environment, we have SBS2003 Premium but have MS SQL 2005 on another >>> box. In all cases everything works very very well. You do not *move* >>> anything....you simply do not use the services on the SBS2003 box. >>> Naturally, you would need to move the mailboxes (if we are talking about >>> Exchange) or migrate the data (if we are talking about SQL or >>> SharePoint). >>> >>> 3) Trusts - agreed. The SBS box has to be the "main" domain controller >>> in the forest root. You *MUST* have a single domain/tree/forest >>> environment as there is no possibility of a trust. Well, there are a >>> couple of exceptions, like when you are moving SBS2003 to new hardware >>> or when you are moving SBS2003 to SBS2008 (you install SBS2008 in >>> Migration Mode and have 21 days to complete everything....actually going >>> to be doing this in a couple of weeks). But, there can not be a child >>> domain or another tree in your SBS forest..... >>> >>> 4) Transition Pack - went away one year ago (okay, actually 10 months >>> ago) so that is not an option anymore. >>> >>> 5) Pretty sure that you mean SBS Premium.....not SBS Advanced (if we are >>> getting technical here....which apparently we are). >>> >>> 6) Exchange on a DC - always a concern. Why? You are very limited in >>> what you can do. You can not run dcpromo on that box >>> (okay...agreed,,,if you are doing that on an SBS box then running >>> Exchange on a Domain Controller is the least of your concerns at that >>> particular moment). If you do have an environment where you do have >>> multiple Domain Controllers | Global Catalog Servers then MS Exchange - >>> because it is installed on a DC - will only make use of *THAT* DC | GC >>> (DSProxy and DSAccess). So, if that DC | GC is down.......again, if >>> the SBS box is down then you do not really care about whether or not >>> Exchange is on a DC or not and which DCs \ GCs it *could* possibly >>> use...but it is still a concern. Also, store.exe consumes a TON of RAM. >>> And, if we are talking about SBS2003 Premium, then having MS Exchange >>> 2003 and MS SQL 2000 | MS SQL 2005 running on the same box is a *HUGE* >>> concern [think RAM....32-bit is limited to 4GB....we have a couple of >>> SBS 2003 Premium environments where they have 150MB of available RAM at >>> any given point because MS SQL is taking up a ton of RAM (use MS SQL >>> based applications that are RAM Resource HOGS) and MS Exchange is >>> taking up a ton of RAM....]. >>> >>> 7) Totally disagree with the last paragraph....have done it (well, >>> Windows Server 2003....no Windows Server 2008 as you indicate....) a >>> couple of times....in fact, we still manage an environment where we went >>> from SBS2003 to "normal" Windows 2003 | Exchange 2003. In that >>> environment we did not use the Transition Pack. Same in at least one >>> other. And, we have gone through that same process, only we did indeed >>> make use of the Transition Pack. >>> >>> In fact, in the environment where we did not use the transition >>> pack....several of the SBS features are still available. And, are being >>> used this very day. >>> >>> So, while it is fair that you state that my root issue is that I do not >>> understand SBS it is also fair that I disagree with your statement. >>> But, again, no offense taken. >>> >> >> Just thought to add the following... >> >> 1) b). I know you already knew this, but didn't explicitly state it. I >> just wanted to point out to others that since this is one domain, all DCs >> that are added as replicas into the SBS domain, should be GCs. Only >> exception to the rule is if there are multiple domains in the forest, >> which doesn't apply to SBS anyway. > > > Correct.....all DCs generally speaking should also be DCs. The one caveat > to that is if you have multiple domains (which we have clearly established > is not possible in SBS-land...) then the DC that holds the Domain-wide > DSMO Role of Infrastructure Master [there are two Forest-wide FSMO Roles > (Schema Master and Domain Naming Master) and there are three Domain-wide > FSMO Roles (PDC Emulator, RISD Master and Infratructure Master)...so, if > you had four domains in the forest you would have 14 roles - the two > Forest-wide and then the three Domain-wide for each of the four > Domains...12 + 2 = 14] should not be a GC...and that is because of the > Phantom Objects issue. However, unless I am terribly mistaken if all of > the Domain Controllers in the entire Forest are GCs as well then there is > no concern with the Phantom Objects issue. Well, there are a couple schools of thought on that. I've always relied on, and rather not have a GC on the IM to eliminate any possibility of the phantoms disappearing, as we know the IM maintains phantoms of objects in the other domains and won't enumerate or update changes it finds in the other domains due to the GC having a read only subset, making the IM think it has no work to do. I would just rather leave them separated. Call it 'old school big server land' thinking! :-) > > >> 6) Exchange on a DC: I agree, in a non-SBS environment, Exchange on a DC >> is the worst thing. Besides the store.exe process being eaten up and the >> DSAccess and DSProxy locked to itself for the GC (and if the AD services >> fail on the DC, Exchange flounders, even if there are other DCs/GCs), we >> can't forget that on a DC, the write-back cache is disabled in support of >> the transactional database method that AD uses. However, Exchange's >> transactional process is different, and relies on the write-cache being >> enabled. The result is a possible loss of emails if an issue were to >> occur such as a sudden power down of the DC/Exchange server. AD database >> will be ok, but the Exchange database *may* lose data. However, SBS was >> designed to work around this isssue. Same with SQL on it. > > > Agreed. Well stated. > > >> >> I know I am referencing information from "big server land," and some >> folks here will definitely remind me of that, but the rules still apply >> with all DCs being a GC in a single domain, whether big server land or >> SBS! >> >> Cheers! >> >> :-) >> >> Ace >> >> >> >
From: cctanaka on 15 Oct 2009 23:45 Hi, I have seen you understand about SBS. So I excuse to ask two questions: 1. Is it possible to have another DC (windows server 2008) in a SBS 2008 (Premium) network, so that I could have redundancy of DC (as a login authenticator for clients), DNS server, DHCP Server and Profile replication? If so in any of them, could you point some references? 2. In may test environment I have one SBS 2008 with exchange 2007. I added another member server (win 2008 std), then I made DCPROMO in this second server. I choose to make it a global catalog (only this, no dns server, neither RODC). After I reboot the machines, Exchange stop working. What coud it happen? How can Exchange work again? Thanks in advance. Carlos Tanaka -- cctanaka ------------------------------------------------------------------------ cctanaka's Profile: http://forums.techarena.in/members/144719.htm View this thread: http://forums.techarena.in/small-business-server/1256973.htm http://forums.techarena.in
From: Cary Shultz on 16 Oct 2009 04:51
Too Shey (or however you spell that!)....in-line...one more time! "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message news:OUK8JnfTKHA.4408(a)TK2MSFTNGP06.phx.gbl... > In-line, as well... > > "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message > news:uKhGwMfTKHA.1280(a)TK2MSFTNGP04.phx.gbl... >> Ace, in-line..... >> >> "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message >> news:%23uJw29eTKHA.764(a)TK2MSFTNGP02.phx.gbl... >>> "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message >>> news:OKmQOteTKHA.764(a)TK2MSFTNGP02.phx.gbl... >>>> D, >>>> >>>> I think that I understand SBS2003 and SBS2008 plenty well....but that >>>> is okay. I do not take offense to what you are saying... >>>> >>>> A couple of things that I noted: >>>> >>>> 1) you can indeed have multiple Domain Controllers in an SBS >>>> environment. Shoot, you can have an additional 25 if you wanted. You >>>> just need to make sure that you maintain the following: >>>> A) that the SBS box holds all five FSMO Roles >>>> B) that the SBS box is a Global Catalog Server >>>> C) that - if we are talking SBS2008 - the SBS box is a >>>> DHCP Server >>>> >>>> 2) You most certainly can have additional Exchange Servers | MS SQL >>>> Servers in an SBS environment. You just have to purchase the >>>> additional software and appropriate number of CALs as the second MS >>>> Exchange or MS SQL would clearly not be covered by the SBS CALs. Have >>>> it in many environments. Generally, the question is why would you do >>>> such a thing....and, generally, the answer is that you are going to be >>>> migrating to 'normal' Windows (or, that there are sever performance >>>> issues). We have, for example, in two environments SBS2003 Standard >>>> but have a second Exchange Server (Exchange 2003 in both cases). In >>>> another environment, we have SBS2003 Premium but have MS SQL 2005 on >>>> another box. In all cases everything works very very well. You do not >>>> *move* anything....you simply do not use the services on the SBS2003 >>>> box. Naturally, you would need to move the mailboxes (if we are talking >>>> about Exchange) or migrate the data (if we are talking about SQL or >>>> SharePoint). >>>> >>>> 3) Trusts - agreed. The SBS box has to be the "main" domain controller >>>> in the forest root. You *MUST* have a single domain/tree/forest >>>> environment as there is no possibility of a trust. Well, there are a >>>> couple of exceptions, like when you are moving SBS2003 to new hardware >>>> or when you are moving SBS2003 to SBS2008 (you install SBS2008 in >>>> Migration Mode and have 21 days to complete everything....actually >>>> going to be doing this in a couple of weeks). But, there can not be a >>>> child domain or another tree in your SBS forest..... >>>> >>>> 4) Transition Pack - went away one year ago (okay, actually 10 months >>>> ago) so that is not an option anymore. >>>> >>>> 5) Pretty sure that you mean SBS Premium.....not SBS Advanced (if we >>>> are getting technical here....which apparently we are). >>>> >>>> 6) Exchange on a DC - always a concern. Why? You are very limited in >>>> what you can do. You can not run dcpromo on that box >>>> (okay...agreed,,,if you are doing that on an SBS box then running >>>> Exchange on a Domain Controller is the least of your concerns at that >>>> particular moment). If you do have an environment where you do have >>>> multiple Domain Controllers | Global Catalog Servers then MS Exchange - >>>> because it is installed on a DC - will only make use of *THAT* DC | GC >>>> (DSProxy and DSAccess). So, if that DC | GC is down.......again, if >>>> the SBS box is down then you do not really care about whether or not >>>> Exchange is on a DC or not and which DCs \ GCs it *could* possibly >>>> use...but it is still a concern. Also, store.exe consumes a TON of >>>> RAM. And, if we are talking about SBS2003 Premium, then having MS >>>> Exchange 2003 and MS SQL 2000 | MS SQL 2005 running on the same box is >>>> a *HUGE* concern [think RAM....32-bit is limited to 4GB....we have a >>>> couple of SBS 2003 Premium environments where they have 150MB of >>>> available RAM at any given point because MS SQL is taking up a ton of >>>> RAM (use MS SQL based applications that are RAM Resource HOGS) and MS >>>> Exchange is taking up a ton of RAM....]. >>>> >>>> 7) Totally disagree with the last paragraph....have done it (well, >>>> Windows Server 2003....no Windows Server 2008 as you indicate....) a >>>> couple of times....in fact, we still manage an environment where we >>>> went from SBS2003 to "normal" Windows 2003 | Exchange 2003. In that >>>> environment we did not use the Transition Pack. Same in at least one >>>> other. And, we have gone through that same process, only we did indeed >>>> make use of the Transition Pack. >>>> >>>> In fact, in the environment where we did not use the transition >>>> pack....several of the SBS features are still available. And, are >>>> being used this very day. >>>> >>>> So, while it is fair that you state that my root issue is that I do not >>>> understand SBS it is also fair that I disagree with your statement. >>>> But, again, no offense taken. >>>> >>> >>> Just thought to add the following... >>> >>> 1) b). I know you already knew this, but didn't explicitly state it. I >>> just wanted to point out to others that since this is one domain, all >>> DCs that are added as replicas into the SBS domain, should be GCs. Only >>> exception to the rule is if there are multiple domains in the forest, >>> which doesn't apply to SBS anyway. >> >> >> Correct.....all DCs generally speaking should also be DCs. The one >> caveat to that is if you have multiple domains (which we have clearly >> established is not possible in SBS-land...) then the DC that holds the >> Domain-wide DSMO Role of Infrastructure Master [there are two Forest-wide >> FSMO Roles (Schema Master and Domain Naming Master) and there are three >> Domain-wide FSMO Roles (PDC Emulator, RISD Master and Infratructure >> Master)...so, if you had four domains in the forest you would have 14 >> roles - the two Forest-wide and then the three Domain-wide for each of >> the four Domains...12 + 2 = 14] should not be a GC...and that is because >> of the Phantom Objects issue. However, unless I am terribly mistaken if >> all of the Domain Controllers in the entire Forest are GCs as well then >> there is no concern with the Phantom Objects issue. > > > Well, there are a couple schools of thought on that. I've always relied > on, and rather not have a GC on the IM to eliminate any possibility of the > phantoms disappearing, as we know the IM maintains phantoms of objects in > the other domains and won't enumerate or update changes it finds in the > other domains due to the GC having a read only subset, making the IM think > it has no work to do. I would just rather leave them separated. Call it > 'old school big server land' thinking! :-) There ain't nothing wrong with old school! I find that it usually works very well. In fact, I usually implement 'old school' and hope that the "younger guys" do not change things. >> >> >>> 6) Exchange on a DC: I agree, in a non-SBS environment, Exchange on a >>> DC is the worst thing. Besides the store.exe process being eaten up and >>> the DSAccess and DSProxy locked to itself for the GC (and if the AD >>> services fail on the DC, Exchange flounders, even if there are other >>> DCs/GCs), we can't forget that on a DC, the write-back cache is disabled >>> in support of the transactional database method that AD uses. However, >>> Exchange's transactional process is different, and relies on the >>> write-cache being enabled. The result is a possible loss of emails if an >>> issue were to occur such as a sudden power down of the DC/Exchange >>> server. AD database will be ok, but the Exchange database *may* lose >>> data. However, SBS was designed to work around this isssue. Same with >>> SQL on it. >> >> >> Agreed. Well stated. >> >> >>> >>> I know I am referencing information from "big server land," and some >>> folks here will definitely remind me of that, but the rules still apply >>> with all DCs being a GC in a single domain, whether big server land or >>> SBS! >>> >>> Cheers! >>> >>> :-) >>> >>> Ace >>> >>> >>> >> > > > |