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/

Reply via email to