First of all... just wanted to say thanks very much to everyone who's responded. It's great to get the different perspectives and it's a constant learning experience... so thanks again :-)

I'm off on holiday for a week, off to warmer climes, so who knows what's changed by the time I get back.... I'm (excusing the pun) warming to the idea of the no DC on smaller sites. I'm using a rough rule of around 4kbps per user at the moment (e.g. around 50+ users to a 256kbps connection). Sadly, in Europe there's no bandwidth on tap ;-) Obviously contention on the wire is a factor, but I'm assuming this is a reasonable yardstick.

I like the risk assessment idea that Gil mentioned but I'm a little concerned (and cynical) that if you don't ask the right questions then the answers are pretty much academic. Sort of along the lines of....
Is it safe ?.. Is it safe ?.. yeah .. yeah .. it's safe.

I'll probably try and wangle a third-party assessment, just for objectivitys sake..

Mylo

Phil Renouf wrote:

I've seen 500 and 1000 user sites with no DC. They were on the end of decent network links, but nothing outrageuous. To determine if you really need a DC at a remote location I would sit down and look at the stability of your network link and its current utilization. Then spend some time thinking about how critical the site is and can they live with having no access to a DC for a few hours if the network link went down? I'd also look at the log on traffic vs replication traffic. If replication traffic would be higher than logon traffic then right there you have a very good argument for not putting a DC at that site. Phil

On 10/7/05, *Mylo* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    Mark,

    How many users to site are you talking about in the no local DC
    scenario. 10, 20..50 ?

    Cheers
    Mylo

    [EMAIL PROTECTED]
    <mailto:[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]>
    >[mailto:[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>] On Behalf Of joe
    >Sent: 07 October 2005 01:18
    >To: ActiveDir@mail.activedir.org
    <mailto: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]>
    >[mailto: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>] On Behalf Of Gil
    Kirkpatrick
    >Sent: Thursday, October 06, 2005 7:07 PM
    >To: ActiveDir@mail.activedir.org
    <mailto: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
    <http://www.cs.cmu.edu/%7ECompose/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]>
    >[mailto: [EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>] On Behalf Of Mylo
    >Sent: Thursday, October 06, 2005 11:44 AM
    >To: ActiveDir@mail.activedir.org
    <mailto: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
    <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/
    <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 <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