We had a pretty inefficient model for small site deployment, so we recently revamped it to the one mentioned below. So far, the DC-less sites have been quite small, no more than 10 users. However, I'd be comfortable letting that go up as far as 100 or so users - but we do have very good WAN connectivity.
As I mentioned though, a major factor in this is whether or not there's going to be an Exchange server locally. If our messaging team have decided that they want a local Exchange server on that site, then we have to put a GC there too. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: 07 October 2005 13:59 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Server Roles Mark, How many users to site are you talking about in the no local DC scenario. 10, 20..50 ? Cheers Mylo [EMAIL PROTECTED] wrote: >I've looked at using Virtual Server for small sites and it makes sense >to me. The only drawback is that all your eggs are in one basket - >lose the host and you lose everything. The same's true for patching as >you'll need downtime on all of the guest machines when the host is >updated. > >One nice advantage of using Virtual Server in this scenario is the >ability to access the Virtual Server Administration Console and >therefore have complete remote control over the virtual hardware and >the console. This is ideal for small sites with no local >admin/technical staff. > >I have to agree with Joe about whether you actually need a DC or not >though. At a number of sites we've chosen not to deploy a local DC at >all. In fact, we tend to tie the DC deployment decision into whether >or not that site is going to have Exchange server locally. > >Regards, >Mark. > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of joe >Sent: 07 October 2005 01:18 >To: ActiveDir@mail.activedir.org >Subject: RE: [ActiveDir] Server Roles > >Mylo, > >I pretty much agree with Gil but I don't think most people or orgs have >the slightest idea how to evaluate their environments for risks. Plus >too many people have the mindset that if they don't know of a way to >hack something, no way exists. If this is the direction taken, bring >someone else in to do it. Even if you do that it still may not work out >well though because of assumptions that are made during the analysis >that don't end up being true in implementation. "Oh yeah, of course we >look at the logs.... " "Of course we patch right away and watch the >security bulletins...". The fewer vectors available to compromise tends >to mean the less chance of being compromised. >I think max paranoa is the safer path. > >IIS on a DC makes me very queasy. Granted it is based on the history of >IIS and it is "all fixed" now, but consider... How many exploits do you >need against your DCs before it is considered too many? Is a single >compromise acceptable? I don't mind losing most one off servers, it >hurts but I can survive. If someone walked through a hole on a DC or a >cert server your base security for the entire environment, all servers >and clients, has been compromised and you can not easily have much >faith in those pieces any longer. I can rebuild an IIS server in a >couple of hours, how fast can you rebuild from scratch your domain >structure? Your Cert structure? > >Exchange... Well I have all sorts of love for Exchange but right off, >if Exchange is running on a GC, you have no fault tolerance or load >balancing for directory work, that is the one and only GC that will >ever be used. The Exchange provider should be complaining about that >all alone. Failover to another GC in another site may suck, but at >least it is possible. > >If someone insists that they can only have one server at a site, at >this time my recommendation is that it not be a DC. If you keep your >GPOs in check this shouldn't be a serious issue unless you have a >crappy network. >DCs are a special case and should be treated specially, it isn't just >some extra service on a machine. Services I will run on a DC are things >like WINS and DNS and quite honestly I don't much like DNS on DCs >either. It bothers me to run a service on the machine that the DC is >completely dependent on. >With WINS, I always deployed LMHOSTS files on the DCs, that way if WINS >failed, things still worked. > > joe > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Gil >Kirkpatrick >Sent: Thursday, October 06, 2005 7:07 PM >To: ActiveDir@mail.activedir.org >Subject: RE: [ActiveDir] Server Roles > >As you mentioned, this topic has been debated frequently on this list. >Running other services on a DC raises the hackles on the back of my >neck, and I expect that most on the list will have similar reactions. >And you've listed most of the reasons why the proposed deployment would >be a bad idea. But truthfully, the "right" answer has to be based on a >proper risk assessment for your client's environment. I think in the >past most people either a) never did a risk assessment, or b) didn't >understand the risks with branch office DCs running multiple services. >Consequently, most AD professionals now default to "its pure insanity" >when asked about this kind of deployment. The answer of course, as with >most everything, is "it depends". > >Because every organization has different perceptions of and >sensitivities to different kinds of threats (some organizations have a >high tolerance for service failure, but a low tolerance for >trade-secret theft, for instance), and because the threat profile is >different for each organization (how protected are the remote DCs? How >accessible is the network? How effective is patch deployment?) the only >way to evaluate the proposed deployment is to do a proper risk analysis >in the context of the organizational environment. > >So if I were faced with this situation, I would recommend a threat >assessment and risk analysis project to evaluate the risks associated >with this sort of deployment. A good paper is Butler and Fishbeck's >Multi-Attribute Risk Assessment >http://www.cs.cmu.edu/~Compose/paper_abstracts/butler-fishbeck-02.html, >but your favorite CISSP text covers it as well. Because you understand >the threats and risks in the proposed deployment, you can make sure >that they are properly represented in the analysis, and the customer >can weigh the >(definite) costs of additional servers against the (potential) costs of >a security failure. > >That all being said, I think that running Exchange, SMS, or IIS on a DC >is a Really Bad Idea (tm). > >My $.25... > >-gil > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Mylo >Sent: Thursday, October 06, 2005 11:44 AM >To: ActiveDir@mail.activedir.org >Subject: [ActiveDir] Server Roles > >Hi All, > >It's a well trodden path (in these forums anyway) that I'm about to >discuss but I'd like to get our resident experts 10 cents worth on a >rather interesting issue I've run into.. I'm working at a client, >reviewing an AD design, where 2 support providers are providing a >migration path to an AD2003/Exchange 2003 solution (from NT4/Ex5.5). >One > >of the providers is responsible for AD (desktop/SMS/File and Print) >design and the other E-Mail design/deployment. This is a single >forest/single domain solution where both have agreed to work in >concert, > >together in the spirit of harmony and SLA's... There's a possibility >that proxy tools may be used (e.g. Aelita/Quest type tooling) to 'limit' > >or delegate AD activities for each party, with these interfaces largely >limited to managing AD delegation of OU/user/group/machine objects ... >resource management (AV/Backup/SMS/DHCP/DNS/WINS etc) still requires >native or 3rd party tooling. > >The problem lies in the fact that the client (on the advice of the >support >provider) has opted for consolidating File and print / SMS/ AD roles >onto a single server at sites of up to around 200 users. Above this >size the solution scales out to multiple servers, but continues to >adhere to the principal of dual role, namely placing File and Print >together with domain controllers and/or SMS and IIS together with a domain controller. >In the legacy solution these roles were separated onto different serves >and the file and print locally managed (also meaning that there's an >awful lot of crap that will be migrated into AD as a result of >combining these roles into one box) ... The combined role > >approach was given the green light largely for (I believe) cost >reasons, > >but I do have *ahem* a number of concerns with this approach. > >Security >===== >- multiple roles on a single server and no-no's such as placing IIS and >SMS on a DC >- it tends to look at security from a 'top down' perspective (i.e. it's >a single AD provider therefore we're safe)... i don't think this flies >simply because of the implications of using 3rd party s/w such as >anti-virus and backup on dual-role servers where local admin rights are >required, which equates to domain admin rights; providing a rather >scary escalation path to being able to doing anything to anybody in the >domain. Scenarios where the AD provider outsources to another party >(e.g. in smaller countries)....if A (the client) trusts B (the support >provider) who trusts C (outsourcee), should A trust C? ... I knew >trusts > >would come in handy one day :-) > >Stability >===== >- Print Services on domain controllers >- Migrating clutter off the legacy file and print into AD (10,000's >local/global groups) >- If there's a mail server on-site with a combined server then e-Mail >availability is linked to the whim and stability of file and print >services/IIS/SMS etc. >- Backup/Restore .. increased chance of human error where day-to-day >restore operations associated with File and Print may result in key >files being overwritten (relating to DC operations) > >Availability >======= >- Reboots during the day are likely to be more numerous through bulking >up roles... affecting the whole office (e.g. AD replication gets >stuck, > >BITS kills IIS etc.) > >Accountability >========= >- Difficult to prove anything was done by anybody at any time. > >Performance >========= >- Means enabling write caching on a DC for the benefit of file and >print > >services (i.e. read-optimised RAID versus write-optimised RAID) > >Possible solutions >============ >1. Use VS2005 and virtual machines >2. Place File and Print alone on smaller sites with no DC, say up to 25 >users and above that use separate DC and File and Print/SMS roles on >separate servers . >3. Buy SBS for each smaller site and setup x number of trusts to the >central sites :0) 4. Live with it and stop worrying > >Am I being overly paranoid with this dual/triple role thing or is this >really as bad as it looks ? Does anyone actually advocate this as a >solution if they were given a greenfields choice? >I'd appreciate your candour and feedback... > >Thanks, >Mylo >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/ > >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/ > > >----------------------------------------------------------------------- >- For more information about Barclays Capital, please visit our web >site at http://www.barcap.com. > > >Internet communications are not secure and therefore the Barclays Group >does not accept legal responsibility for the contents of this message. >Although the Barclays Group operates anti-virus programmes, it does not >accept responsibility for any damage whatsoever that is caused by >viruses being passed. Any views or opinions presented are solely those >of the author and do not necessarily represent those of the Barclays >Group. Replies to this email may be monitored by the Barclays Group >for operational or business reasons. > >----------------------------------------------------------------------- >- > >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/ 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/