SBS2003 | Windows Server 2008 - Exchange 2007
|
From: Ace Fekay [MCT] on 16 Oct 2009 10:42 Actually, I believe it's touch�. Great conversation! Cheers! :-) "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message news:eq8Yk3jTKHA.4000(a)TK2MSFTNGP05.phx.gbl... > 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 >>>> >>>> >>>> >>> >> >> >> >
From: Cary Shultz on 16 Oct 2009 13:17 Yeppers. it is.... Hey, have you noticed that D. Gabriel has yet to respond? That is okay.... Cary "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message news:e4pRm7mTKHA.504(a)TK2MSFTNGP06.phx.gbl... > Actually, I believe it's touch�. > > Great conversation! > > Cheers! > > :-) > > "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message > news:eq8Yk3jTKHA.4000(a)TK2MSFTNGP05.phx.gbl... >> 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 >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > >
From: Ace Fekay [MCT] on 16 Oct 2009 21:37 "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message news:u0B3hSoTKHA.4704(a)TK2MSFTNGP02.phx.gbl... I don't think D. Gabriel will respond. Interesting that his/her response as such that it was a subtle attack on your knowledge, you should see the childish remark someone made against Meinolf in the General group. Two in one week. Hmm... Must be a full moon ... Ace > Yeppers. it is.... > > Hey, have you noticed that D. Gabriel has yet to respond? That is > okay.... > > Cary > > > "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message > news:e4pRm7mTKHA.504(a)TK2MSFTNGP06.phx.gbl... >> Actually, I believe it's touch�. >> >> Great conversation! >> >> Cheers! >> >> :-) >> >> "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message >> news:eq8Yk3jTKHA.4000(a)TK2MSFTNGP05.phx.gbl... >>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> >
From: Cary Shultz on 17 Oct 2009 09:22 No worries, Ace! I was not offended (and I am not so sure that it was so subtle...his/her first sentence pretty much was cut and dry). I can see the thought process on my post.....was asking about something that I have yet to do and wanted to make sure that - although this is an environment that we just took over and have little to do with the current situation - I did not make something worse (this particular environment is simply amazing....I will not bore you with the seven or eight *MAJOR* things that are back-a$$wards...).... Now, Meinolf.....someone made a childish remark about Meinolf? Them's fightin' words.....let me at 'em... Cary "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message news:%23aU4gpsTKHA.4144(a)TK2MSFTNGP02.phx.gbl... > "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message > news:u0B3hSoTKHA.4704(a)TK2MSFTNGP02.phx.gbl... > > I don't think D. Gabriel will respond. Interesting that his/her response > as such that it was a subtle attack on your knowledge, you should see the > childish remark someone made against Meinolf in the General group. Two in > one week. Hmm... Must be a full moon ... > > Ace > > >> Yeppers. it is.... >> >> Hey, have you noticed that D. Gabriel has yet to respond? That is >> okay.... >> >> Cary >> >> >> "Ace Fekay [MCT]" <aceman(a)mvps.RemoveThisPart.org> wrote in message >> news:e4pRm7mTKHA.504(a)TK2MSFTNGP06.phx.gbl... >>> Actually, I believe it's touch�. >>> >>> Great conversation! >>> >>> Cheers! >>> >>> :-) >>> >>> "Cary Shultz" <cshultz(a)outsourceit.com> wrote in message >>> news:eq8Yk3jTKHA.4000(a)TK2MSFTNGP05.phx.gbl... >>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > >
From: cctanaka on 17 Oct 2009 15:42
Hi Ace, The SBS 2008 DC has the following configuration: Name: micro21 IPv4: 192.168.43.21 Mask: 255.255.255.0 IPv6: fe80::3985:7e5c:901f:dc18%10 and: fe80::5574:89c9:7014:55bd%10 DNS: fe80::5574:89c9:7014:55bd%10 and: 192.168.43.21 Gateway: 192.168.43.254 (a router box) The Server 2008 member server: Name: micro31 IPv4: 192.168.43.31 Mask: 255.255.255.0 IPv6: fe80::e8b3:5e7d:ee33:f324%10 DNS: fe80::5574:89c9:7014:55bd%10 and: fe80::e8b3:5e7d:ee33:f324%10 and: 192.168.43.21 and: 192.168.43.31 Gateway: 192.168.43.254 (a router box) it is not a DNS Server yet, but I have already inserted IP addresses of this machine. Thanks again. -- 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 |