How to do this?

Discussion in 'ASP .Net Security' started by John, Dec 22, 2003.

  1. John

    John Guest

    Hi

    We have an SBS2000 server which has an access database running internally,
    supporting around 20 users. The server is connected to a broadband
    connection. Is it viable for us to run an asp.net web site on the same
    server that allows visitors (around ten on average) to view the content of
    the internal database? As you can see there are several issues here;
    performance of server, security, broadband bandwidth, access etc.

    If this is not feasible, what would be the recommended way to achieve this?
    It is not possible to rewrite access database for SQL server just now.

    Thanks

    Regards
    John, Dec 22, 2003
    #1
    1. Advertising

  2. > supporting around 20 users. The server is connected to a broadband
    > connection. Is it viable for us to run an asp.net web site on the same
    > server that allows visitors (around ten on average) to view the content of
    > the internal database?


    Yes - its viable, but with access its not really recommended. If they all
    connect together then you will get concurrency problems, as long as the
    connected users remains low then you should be OK. 10 might be pushing it
    for Access - you will have to try it and see.

    As you can see there are several issues here;
    > performance of server,

    Depends on how big your scripts are, and what they do - and on how well ou
    understand web system design.

    security,
    A doozy - you have lots of service packing and server hardening to do. Hope
    you have a good firewall too.

    broadband bandwidth,
    Not likely to be an issue with such a small user base.

    access etc.
    Read up on certificates, or work out a way to pass authentication details in
    a secure way. Depends on how sensitive or mission critical your data is -
    do you allow read, or read/write access etc.

    Good luck.....
    --
    Regards

    John Timney (Microsoft ASP.NET MVP)
    ----------------------------------------------
    <shameless_author_plug>
    Professional .NET for Java Developers with C#
    ISBN:1-861007-91-4
    Professional Windows Forms
    ISBN: 1861005547
    Professional JSP 2nd Edition
    ISBN: 1861004958
    Professional JSP
    ISBN: 1861003625
    Beginning JSP Web Development
    ISBN: 1861002092
    </shameless_author_plug>
    ----------------------------------------------

    "John" <> wrote in message
    news:...
    > Hi
    >
    > We have an SBS2000 server which has an access database running internally,
    > supporting around 20 users. The server is connected to a broadband
    > connection. Is it viable for us to run an asp.net web site on the same
    > server that allows visitors (around ten on average) to view the content of
    > the internal database? As you can see there are several issues here;
    > performance of server, security, broadband bandwidth, access etc.
    >
    > If this is not feasible, what would be the recommended way to achieve

    this?
    > It is not possible to rewrite access database for SQL server just now.
    >
    > Thanks
    >
    > Regards
    >
    >
    >
    John Timney \(Microsoft MVP\), Dec 22, 2003
    #2
    1. Advertising

  3. Picking up on a good firewall, what would you recommend?

    "John Timney (Microsoft MVP)" <> wrote in message
    news:%...
    > > supporting around 20 users. The server is connected to a broadband
    > > connection. Is it viable for us to run an asp.net web site on the same
    > > server that allows visitors (around ten on average) to view the content

    of
    > > the internal database?

    >
    > Yes - its viable, but with access its not really recommended. If they all
    > connect together then you will get concurrency problems, as long as the
    > connected users remains low then you should be OK. 10 might be pushing it
    > for Access - you will have to try it and see.
    >
    > As you can see there are several issues here;
    > > performance of server,

    > Depends on how big your scripts are, and what they do - and on how well ou
    > understand web system design.
    >
    > security,
    > A doozy - you have lots of service packing and server hardening to do.

    Hope
    > you have a good firewall too.
    >
    > broadband bandwidth,
    > Not likely to be an issue with such a small user base.
    >
    > access etc.
    > Read up on certificates, or work out a way to pass authentication details

    in
    > a secure way. Depends on how sensitive or mission critical your data is -
    > do you allow read, or read/write access etc.
    >
    > Good luck.....
    > --
    > Regards
    >
    > John Timney (Microsoft ASP.NET MVP)
    > ----------------------------------------------
    > <shameless_author_plug>
    > Professional .NET for Java Developers with C#
    > ISBN:1-861007-91-4
    > Professional Windows Forms
    > ISBN: 1861005547
    > Professional JSP 2nd Edition
    > ISBN: 1861004958
    > Professional JSP
    > ISBN: 1861003625
    > Beginning JSP Web Development
    > ISBN: 1861002092
    > </shameless_author_plug>
    > ----------------------------------------------
    >
    > "John" <> wrote in message
    > news:...
    > > Hi
    > >
    > > We have an SBS2000 server which has an access database running

    internally,
    > > supporting around 20 users. The server is connected to a broadband
    > > connection. Is it viable for us to run an asp.net web site on the same
    > > server that allows visitors (around ten on average) to view the content

    of
    > > the internal database? As you can see there are several issues here;
    > > performance of server, security, broadband bandwidth, access etc.
    > >
    > > If this is not feasible, what would be the recommended way to achieve

    > this?
    > > It is not possible to rewrite access database for SQL server just now.
    > >
    > > Thanks
    > >
    > > Regards
    > >
    > >
    > >

    >
    >
    Colin Basterfield, Dec 22, 2003
    #3
  4. > Not to mention, SBS2k would not allow you to expose a SQL server to be a
    > public backend to a database [however SBS2k3 does allow this]
    > Can you flip it to msde?


    Is it my understanding that you wouldn't be able to, for example display a
    datagrid with info from this database with SBS2k?

    Colin

    "Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" <>
    wrote in message news:%...
    > Not to mention, SBS2k would not allow you to expose a SQL server to be a
    > public backend to a database [however SBS2k3 does allow this]
    > Can you flip it to msde?
    >
    > John Timney (Microsoft MVP) wrote:
    > >>supporting around 20 users. The server is connected to a broadband
    > >>connection. Is it viable for us to run an asp.net web site on the same
    > >>server that allows visitors (around ten on average) to view the content

    of
    > >>the internal database?

    > >
    > >
    > > Yes - its viable, but with access its not really recommended. If they

    all
    > > connect together then you will get concurrency problems, as long as the
    > > connected users remains low then you should be OK. 10 might be pushing

    it
    > > for Access - you will have to try it and see.
    > >
    > > As you can see there are several issues here;
    > >
    > >>performance of server,

    > >
    > > Depends on how big your scripts are, and what they do - and on how well

    ou
    > > understand web system design.
    > >
    > > security,
    > > A doozy - you have lots of service packing and server hardening to do.

    Hope
    > > you have a good firewall too.
    > >
    > > broadband bandwidth,
    > > Not likely to be an issue with such a small user base.
    > >
    > > access etc.
    > > Read up on certificates, or work out a way to pass authentication

    details in
    > > a secure way. Depends on how sensitive or mission critical your data

    is -
    > > do you allow read, or read/write access etc.
    > >
    > > Good luck.....
    > > --
    > > Regards
    > >
    > > John Timney (Microsoft ASP.NET MVP)
    > > ----------------------------------------------
    > > <shameless_author_plug>
    > > Professional .NET for Java Developers with C#
    > > ISBN:1-861007-91-4
    > > Professional Windows Forms
    > > ISBN: 1861005547
    > > Professional JSP 2nd Edition
    > > ISBN: 1861004958
    > > Professional JSP
    > > ISBN: 1861003625
    > > Beginning JSP Web Development
    > > ISBN: 1861002092
    > > </shameless_author_plug>
    > > ----------------------------------------------
    > >
    > > "John" <> wrote in message
    > > news:...
    > >
    > >>Hi
    > >>
    > >>We have an SBS2000 server which has an access database running

    internally,
    > >>supporting around 20 users. The server is connected to a broadband
    > >>connection. Is it viable for us to run an asp.net web site on the same
    > >>server that allows visitors (around ten on average) to view the content

    of
    > >>the internal database? As you can see there are several issues here;
    > >>performance of server, security, broadband bandwidth, access etc.
    > >>
    > >>If this is not feasible, what would be the recommended way to achieve

    > >
    > > this?
    > >
    > >>It is not possible to rewrite access database for SQL server just now.
    > >>
    > >>Thanks
    > >>
    > >>Regards
    > >>
    > >>
    > >>

    > >
    > >
    > >

    >
    > --
    > http://www.sbslinks.com/really.htm
    >
    Colin Basterfield, Dec 22, 2003
    #4
  5. John

    John Guest

    We are using access. Is it possible/better to have another win2k machine in
    the domain to run the web site off it? Will sbs2000 route internet traffic
    to/from this member pc running IIS without problem?

    Regards

    "Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" <>
    wrote in message news:%...
    > Not to mention, SBS2k would not allow you to expose a SQL server to be a
    > public backend to a database [however SBS2k3 does allow this]
    > Can you flip it to msde?
    >
    > John Timney (Microsoft MVP) wrote:
    > >>supporting around 20 users. The server is connected to a broadband
    > >>connection. Is it viable for us to run an asp.net web site on the same
    > >>server that allows visitors (around ten on average) to view the content

    of
    > >>the internal database?

    > >
    > >
    > > Yes - its viable, but with access its not really recommended. If they

    all
    > > connect together then you will get concurrency problems, as long as the
    > > connected users remains low then you should be OK. 10 might be pushing

    it
    > > for Access - you will have to try it and see.
    > >
    > > As you can see there are several issues here;
    > >
    > >>performance of server,

    > >
    > > Depends on how big your scripts are, and what they do - and on how well

    ou
    > > understand web system design.
    > >
    > > security,
    > > A doozy - you have lots of service packing and server hardening to do.

    Hope
    > > you have a good firewall too.
    > >
    > > broadband bandwidth,
    > > Not likely to be an issue with such a small user base.
    > >
    > > access etc.
    > > Read up on certificates, or work out a way to pass authentication

    details in
    > > a secure way. Depends on how sensitive or mission critical your data

    is -
    > > do you allow read, or read/write access etc.
    > >
    > > Good luck.....
    > > --
    > > Regards
    > >
    > > John Timney (Microsoft ASP.NET MVP)
    > > ----------------------------------------------
    > > <shameless_author_plug>
    > > Professional .NET for Java Developers with C#
    > > ISBN:1-861007-91-4
    > > Professional Windows Forms
    > > ISBN: 1861005547
    > > Professional JSP 2nd Edition
    > > ISBN: 1861004958
    > > Professional JSP
    > > ISBN: 1861003625
    > > Beginning JSP Web Development
    > > ISBN: 1861002092
    > > </shameless_author_plug>
    > > ----------------------------------------------
    > >
    > > "John" <> wrote in message
    > > news:...
    > >
    > >>Hi
    > >>
    > >>We have an SBS2000 server which has an access database running

    internally,
    > >>supporting around 20 users. The server is connected to a broadband
    > >>connection. Is it viable for us to run an asp.net web site on the same
    > >>server that allows visitors (around ten on average) to view the content

    of
    > >>the internal database? As you can see there are several issues here;
    > >>performance of server, security, broadband bandwidth, access etc.
    > >>
    > >>If this is not feasible, what would be the recommended way to achieve

    > >
    > > this?
    > >
    > >>It is not possible to rewrite access database for SQL server just now.
    > >>
    > >>Thanks
    > >>
    > >>Regards
    > >>
    > >>
    > >>

    > >
    > >
    > >

    >
    > --
    > http://www.sbslinks.com/really.htm
    >
    John, Dec 22, 2003
    #5
  6. John

    Mark Mancini Guest

    a better solution......

    Is this an Access db? You can easily port it to MySQL and php and put it on
    a webserver for clients to access as well as yourslef. You can get PHP
    programmers cheap!

    --
    Sincerely,
    Mark Mancini, CCA, CCNA, Master CIW&CI, CNE 4&5, MCSE+I 4&2000
    www.MCSE2000.com
    www.AppLauncher.com



    "John" <> wrote in message
    news:...
    > Hi
    >
    > We have an SBS2000 server which has an access database running internally,
    > supporting around 20 users. The server is connected to a broadband
    > connection. Is it viable for us to run an asp.net web site on the same
    > server that allows visitors (around ten on average) to view the content of
    > the internal database? As you can see there are several issues here;
    > performance of server, security, broadband bandwidth, access etc.
    >
    > If this is not feasible, what would be the recommended way to achieve

    this?
    > It is not possible to rewrite access database for SQL server just now.
    >
    > Thanks
    >
    > Regards
    >
    >
    >
    Mark Mancini, Dec 23, 2003
    #6
  7. John

    John Guest

    We will then have to change the internal access app which has taken years to
    develop.

    Regards


    "Mark Mancini" <> wrote in message
    news:...
    > a better solution......
    >
    > Is this an Access db? You can easily port it to MySQL and php and put it

    on
    > a webserver for clients to access as well as yourslef. You can get PHP
    > programmers cheap!
    >
    > --
    > Sincerely,
    > Mark Mancini, CCA, CCNA, Master CIW&CI, CNE 4&5, MCSE+I 4&2000
    > www.MCSE2000.com
    > www.AppLauncher.com
    >
    >
    >
    > "John" <> wrote in message
    > news:...
    > > Hi
    > >
    > > We have an SBS2000 server which has an access database running

    internally,
    > > supporting around 20 users. The server is connected to a broadband
    > > connection. Is it viable for us to run an asp.net web site on the same
    > > server that allows visitors (around ten on average) to view the content

    of
    > > the internal database? As you can see there are several issues here;
    > > performance of server, security, broadband bandwidth, access etc.
    > >
    > > If this is not feasible, what would be the recommended way to achieve

    > this?
    > > It is not possible to rewrite access database for SQL server just now.
    > >
    > > Thanks
    > >
    > > Regards
    > >
    > >
    > >

    >
    >
    John, Dec 23, 2003
    #7
  8. Since this is SBS 2000 you are hosting from, I'll start by clarifying to
    anyone who isn't familiar with the SBS platform (but maybe was cross-posted
    into this discussion) that the SBS suite include ISA Server (firewall), SQL
    Server, Exchange Server and the SBS is required to be the root AD server as
    a Domain Controller.

    I'm replying at this point of the thread just to "include" the previous
    comments made by others. As John Timney stated succinctly, I wools say you
    probably can do this technically, you probably shouldn't do it
    professionally.

    SBS is a very busy box by default, a lot of stuff going on. Some people
    consider SBS to be a house of cards, ready to collapse if you aren't
    careful. I don't really subscribe to that thought, but it's a fair comment,
    particularly when you start to extend the included technologies in the way
    you have indicated....frankly, in the wrong way.

    SBS 2000 is intended to be a server that is a gateway to the web as a
    firewall via ISA, and to provide intranet functionality to the LAN with up
    to 50 users. This is what you are doing. The problem is that you are then
    wanting to do all that....and next you want to make it a fully functional
    public web server, except you don't want to do that in the efficient way
    that webservers would be designed....using SQL under the hood, nor are you
    proposing to do that in the secure manner that represents a best
    practice....a web server in DMZ.

    Therefore, if I were being called in as a consultant, I would look at what
    you are outlining and play the devils advocate of why this is a bad idea.
    You are taking technology and not using it the way any best practice for the
    individual components would be recommended. This is a lot like not using
    best practices like never use a sharp knife and cut toward your hand, never
    user a screwdriver as a chisel, never store dangerous chemicals in a reach
    of children in your house. It's fine if you say...but I'm only slicing
    butter, I'm just knocking caulk off of a tile, and I don't have any kids.

    Let's look at a few of the best practice concepts that you aren't following:

    - Don't expose shared resources on a DC to the web
    - Don't expose and intranet site to the web
    - Always place public IIS webserver in DMZ
    - Isolate your front-end and backend web servers, and use a secure method
    for handling the backend server such as SQL
    - Minimize the functions on a webserver so that you can lock it down as much
    as possible if it's exposed to the public, and particularly don't install
    any applications not required for it's role as a web server.
    - Don't run ISA on a server on a DNS server, DC, Exchange Server, or SQL
    Server, and particularly not on one that you are exposing. (This is that
    special rule about SBS servers where you are violating every rule of
    deployment with ISA, except that the SBS product is tuned to use ISA as a
    firewall to protect this server in those roles. However, at the point that
    you expose all of these functions to traffic entering from all interfaces,
    you really have gone over the edge of sanity in deployment.
    - Don't place business critical assets on a server directly hosting public
    and non-authenticated access.
    - Avoid placing business critical assets required to keep your company
    running hour by hour in a role that increases the risk of critical failures,
    or extended recovery times. Diffuse your risk by protecting and simplifying
    the most critical assets you have to improve your management options, and
    critical response repair options.

    I know, this is the point where someone asking the questions you are asking
    typically says "But if all this is such a bad set of practices, them MS
    should be telling people that they can buy an SBS to run their whole office
    from in this way." Well, yeah, that's true, and I personally wish that MS
    didn't give people the impression that what you are asking is even
    plausible, much less supported. The fact is that SBS includes a broad range
    of products, but I can assure you that it's not the thought that MS dev has
    that anyone is going to deploy a server using everything that is possible to
    do with any individual component, and yet do all of those things
    concurrently on a single machine. It's not that the technology would prevent
    it, it's more that common sense would suggest to you that at some point you
    have to look at the cost of the entire company depending upon a group of
    critical technologies.....and you have to see that you are overextending.

    A company with 20 users internally and another 10 users remotely is
    presumably paying something on the order of $3000-8000 per day in salary,
    right? Oh, I suppose it could be less than that, but realistically, if this
    company existed only to pay 20 people $5/hr each, and it had no other
    business assets, therefore no other cashflow considerations, well then you
    might have an argument for why you don't see the return on investment
    arguments for adding more assets in order to better protect the assets you
    are already producing income with.

    Far to many small businesses fail to realize when they are underfunding
    their business in terms of technology investments. Many SMBs see only cost
    with the equipment, and they don't see productivity, or perhaps they don't
    see how to measure the productivity as a separate distinction from "what if
    this stopped working". The fact that SBS is as reliable as it is makes it
    seem that it would be reasonable to run this one server right up to the
    point that you have the CPU at 70%, the disk drives at 80% capacity, and the
    users all being delayed just about 30 milliseconds less than the time it
    takes for them to not lose their attention to their tasks. That's just
    insane. There's no room to grow the business, or extend to the next
    opportunity.

    It's inherent in any business that there's a point where you have to look at
    what you have that is working really well and then decide that you don't
    push it further, you reinvest in the next place to grow the next thing to
    support your business needs continuing to be met without increasing risk or
    dramatically complicating the complexity of maintaining the overall
    environment.


    With all these things considered in total, I think you really should be
    looking at a minimum of one more server, possible two, plus another firewall
    to create a DMZ. You probably need a dedicated IIS server if that's the best
    way to deploy your applications forward to the web. However, I would
    question whether or not you really are doing yourself a favor by using a web
    server interface to front end an Access database if the Access database is
    really that critical to your customer solution and not something you can
    work around with separate SQL presentation. Maybe you need to look at
    putting a Terminal Server in for the external connections, but this could
    depend upon whether the remote connections are by trusted and authenticated
    users, or not.

    The situation you describe sounds to me more like a scenario where I'm not
    sure that you are looking at a big enough picture to understand what your
    best options are for the company.....not for the technology, but for the
    company. I would be inclined to want to know more about where this company
    is going...and coming from...to understand if the way that you are handling
    this process is leading you into a box you will regret, and maybe your best
    options need to be putting a lot more on the table than just another IIS
    server.
    Jeff Middleton [SBS-MVP], Dec 23, 2003
    #8
  9. For DSL the Thompson Alcatel 510v4 is good and cheap - very easy to
    configure and has built in router / DHCP etc.

    --
    Regards

    John Timney (Microsoft ASP.NET MVP)
    ----------------------------------------------
    <shameless_author_plug>
    Professional .NET for Java Developers with C#
    ISBN:1-861007-91-4
    Professional Windows Forms
    ISBN: 1861005547
    Professional JSP 2nd Edition
    ISBN: 1861004958
    Professional JSP
    ISBN: 1861003625
    Beginning JSP Web Development
    ISBN: 1861002092
    </shameless_author_plug>
    ----------------------------------------------

    "Colin Basterfield" <> wrote in message
    news:...
    > Picking up on a good firewall, what would you recommend?
    >
    > "John Timney (Microsoft MVP)" <> wrote in message
    > news:%...
    > > > supporting around 20 users. The server is connected to a broadband
    > > > connection. Is it viable for us to run an asp.net web site on the same
    > > > server that allows visitors (around ten on average) to view the

    content
    > of
    > > > the internal database?

    > >
    > > Yes - its viable, but with access its not really recommended. If they

    all
    > > connect together then you will get concurrency problems, as long as the
    > > connected users remains low then you should be OK. 10 might be pushing

    it
    > > for Access - you will have to try it and see.
    > >
    > > As you can see there are several issues here;
    > > > performance of server,

    > > Depends on how big your scripts are, and what they do - and on how well

    ou
    > > understand web system design.
    > >
    > > security,
    > > A doozy - you have lots of service packing and server hardening to do.

    > Hope
    > > you have a good firewall too.
    > >
    > > broadband bandwidth,
    > > Not likely to be an issue with such a small user base.
    > >
    > > access etc.
    > > Read up on certificates, or work out a way to pass authentication

    details
    > in
    > > a secure way. Depends on how sensitive or mission critical your data

    is -
    > > do you allow read, or read/write access etc.
    > >
    > > Good luck.....
    > > --
    > > Regards
    > >
    > > John Timney (Microsoft ASP.NET MVP)
    > > ----------------------------------------------
    > > <shameless_author_plug>
    > > Professional .NET for Java Developers with C#
    > > ISBN:1-861007-91-4
    > > Professional Windows Forms
    > > ISBN: 1861005547
    > > Professional JSP 2nd Edition
    > > ISBN: 1861004958
    > > Professional JSP
    > > ISBN: 1861003625
    > > Beginning JSP Web Development
    > > ISBN: 1861002092
    > > </shameless_author_plug>
    > > ----------------------------------------------
    > >
    > > "John" <> wrote in message
    > > news:...
    > > > Hi
    > > >
    > > > We have an SBS2000 server which has an access database running

    > internally,
    > > > supporting around 20 users. The server is connected to a broadband
    > > > connection. Is it viable for us to run an asp.net web site on the same
    > > > server that allows visitors (around ten on average) to view the

    content
    > of
    > > > the internal database? As you can see there are several issues here;
    > > > performance of server, security, broadband bandwidth, access etc.
    > > >
    > > > If this is not feasible, what would be the recommended way to achieve

    > > this?
    > > > It is not possible to rewrite access database for SQL server just now.
    > > >
    > > > Thanks
    > > >
    > > > Regards
    > > >
    > > >
    > > >

    > >
    > >

    >
    >
    John Timney \(Microsoft MVP\), Dec 23, 2003
    #9
  10. John

    John Guest

    Thanks for the very comprehensive analysis of the situation. Appreciate that
    very much.

    As for access, all we are looking for is some very selected information to
    be *viewed only* by some external users, so hopefully the load on access
    will not too bad. In that case, would another server machine with IIS do the
    trick (presumably it has to be win2k server and not win2k professional)?
    Also, presumably it will be a member of the sbs domain. Also I presume the
    best way is to get a second broadband connection for the new web server?

    Thanks

    Regards



    "Jeff Middleton [SBS-MVP]" <> wrote in message
    news:...
    > Since this is SBS 2000 you are hosting from, I'll start by clarifying to
    > anyone who isn't familiar with the SBS platform (but maybe was

    cross-posted
    > into this discussion) that the SBS suite include ISA Server (firewall),

    SQL
    > Server, Exchange Server and the SBS is required to be the root AD server

    as
    > a Domain Controller.
    >
    > I'm replying at this point of the thread just to "include" the previous
    > comments made by others. As John Timney stated succinctly, I wools say you
    > probably can do this technically, you probably shouldn't do it
    > professionally.
    >
    > SBS is a very busy box by default, a lot of stuff going on. Some people
    > consider SBS to be a house of cards, ready to collapse if you aren't
    > careful. I don't really subscribe to that thought, but it's a fair

    comment,
    > particularly when you start to extend the included technologies in the way
    > you have indicated....frankly, in the wrong way.
    >
    > SBS 2000 is intended to be a server that is a gateway to the web as a
    > firewall via ISA, and to provide intranet functionality to the LAN with up
    > to 50 users. This is what you are doing. The problem is that you are then
    > wanting to do all that....and next you want to make it a fully functional
    > public web server, except you don't want to do that in the efficient way
    > that webservers would be designed....using SQL under the hood, nor are you
    > proposing to do that in the secure manner that represents a best
    > practice....a web server in DMZ.
    >
    > Therefore, if I were being called in as a consultant, I would look at what
    > you are outlining and play the devils advocate of why this is a bad idea.
    > You are taking technology and not using it the way any best practice for

    the
    > individual components would be recommended. This is a lot like not using
    > best practices like never use a sharp knife and cut toward your hand,

    never
    > user a screwdriver as a chisel, never store dangerous chemicals in a reach
    > of children in your house. It's fine if you say...but I'm only slicing
    > butter, I'm just knocking caulk off of a tile, and I don't have any kids.
    >
    > Let's look at a few of the best practice concepts that you aren't

    following:
    >
    > - Don't expose shared resources on a DC to the web
    > - Don't expose and intranet site to the web
    > - Always place public IIS webserver in DMZ
    > - Isolate your front-end and backend web servers, and use a secure method
    > for handling the backend server such as SQL
    > - Minimize the functions on a webserver so that you can lock it down as

    much
    > as possible if it's exposed to the public, and particularly don't install
    > any applications not required for it's role as a web server.
    > - Don't run ISA on a server on a DNS server, DC, Exchange Server, or SQL
    > Server, and particularly not on one that you are exposing. (This is that
    > special rule about SBS servers where you are violating every rule of
    > deployment with ISA, except that the SBS product is tuned to use ISA as a
    > firewall to protect this server in those roles. However, at the point that
    > you expose all of these functions to traffic entering from all interfaces,
    > you really have gone over the edge of sanity in deployment.
    > - Don't place business critical assets on a server directly hosting public
    > and non-authenticated access.
    > - Avoid placing business critical assets required to keep your company
    > running hour by hour in a role that increases the risk of critical

    failures,
    > or extended recovery times. Diffuse your risk by protecting and

    simplifying
    > the most critical assets you have to improve your management options, and
    > critical response repair options.
    >
    > I know, this is the point where someone asking the questions you are

    asking
    > typically says "But if all this is such a bad set of practices, them MS
    > should be telling people that they can buy an SBS to run their whole

    office
    > from in this way." Well, yeah, that's true, and I personally wish that MS
    > didn't give people the impression that what you are asking is even
    > plausible, much less supported. The fact is that SBS includes a broad

    range
    > of products, but I can assure you that it's not the thought that MS dev

    has
    > that anyone is going to deploy a server using everything that is possible

    to
    > do with any individual component, and yet do all of those things
    > concurrently on a single machine. It's not that the technology would

    prevent
    > it, it's more that common sense would suggest to you that at some point

    you
    > have to look at the cost of the entire company depending upon a group of
    > critical technologies.....and you have to see that you are overextending.
    >
    > A company with 20 users internally and another 10 users remotely is
    > presumably paying something on the order of $3000-8000 per day in salary,
    > right? Oh, I suppose it could be less than that, but realistically, if

    this
    > company existed only to pay 20 people $5/hr each, and it had no other
    > business assets, therefore no other cashflow considerations, well then you
    > might have an argument for why you don't see the return on investment
    > arguments for adding more assets in order to better protect the assets you
    > are already producing income with.
    >
    > Far to many small businesses fail to realize when they are underfunding
    > their business in terms of technology investments. Many SMBs see only cost
    > with the equipment, and they don't see productivity, or perhaps they don't
    > see how to measure the productivity as a separate distinction from "what

    if
    > this stopped working". The fact that SBS is as reliable as it is makes it
    > seem that it would be reasonable to run this one server right up to the
    > point that you have the CPU at 70%, the disk drives at 80% capacity, and

    the
    > users all being delayed just about 30 milliseconds less than the time it
    > takes for them to not lose their attention to their tasks. That's just
    > insane. There's no room to grow the business, or extend to the next
    > opportunity.
    >
    > It's inherent in any business that there's a point where you have to look

    at
    > what you have that is working really well and then decide that you don't
    > push it further, you reinvest in the next place to grow the next thing to
    > support your business needs continuing to be met without increasing risk

    or
    > dramatically complicating the complexity of maintaining the overall
    > environment.
    >
    >
    > With all these things considered in total, I think you really should be
    > looking at a minimum of one more server, possible two, plus another

    firewall
    > to create a DMZ. You probably need a dedicated IIS server if that's the

    best
    > way to deploy your applications forward to the web. However, I would
    > question whether or not you really are doing yourself a favor by using a

    web
    > server interface to front end an Access database if the Access database is
    > really that critical to your customer solution and not something you can
    > work around with separate SQL presentation. Maybe you need to look at
    > putting a Terminal Server in for the external connections, but this could
    > depend upon whether the remote connections are by trusted and

    authenticated
    > users, or not.
    >
    > The situation you describe sounds to me more like a scenario where I'm not
    > sure that you are looking at a big enough picture to understand what your
    > best options are for the company.....not for the technology, but for the
    > company. I would be inclined to want to know more about where this company
    > is going...and coming from...to understand if the way that you are

    handling
    > this process is leading you into a box you will regret, and maybe your

    best
    > options need to be putting a lot more on the table than just another IIS
    > server.
    >
    >
    >
    John, Dec 23, 2003
    #10
  11. To address your follow-up questions, I'm sort of having to buy into some
    conditions that are complex to swallow without more details. For instance,
    typically one things of an Access database as either a relational database
    with the Tables, Forms and Reports in a single MDB file, or you might have a
    front-end/Back-end arrangement to split the security and management apart.
    Regardless, I would normally think that you would not expect to do things
    like ODBC in order to hook to the backend database from more than one
    frontend. Therefore, when you speak of splitting a frontend to an IIS
    server, the question would return to "what are you trying to accomplish"
    because if you are looking to increase security, you have to consider that
    you would need to figure out how to secure the ability to hook from inside
    the LAN and from outside the LAN to the same database, and yet secure it. If
    the theory is that you are going to authenticate your users, my question
    would return to questioning if a basic IIS server facing the public really
    simplifies your problem or creates it.

    One option would be to devise a way to provide a secure connection to the
    remote users, but I don't have the information to know if you are referring
    to 10 people at a different site, or if it's ten specific computers that
    travel, or if we are talking an average of 10 customers from various places
    that changes day to day. There's a lot here that sort of defies the simple
    answer.

    As for putting the server in DMZ and part of the domain, this is going to be
    entirely debatable to how you would plan to address the previous topic.

    This is why I was suggesting at the end of my last post that I would expect
    to backaway from the technology a little bit to look at the business plan
    first, then let the technical requirements feed the discussion of what
    should be done to meet the business needs and still secure all aspects, and
    address the technical issues you can't change (like switching to SQL from
    Access which is probably the single most valuable change you could make in
    this situation).

    There's plenty of room for debate on how you would address a redesign of
    this package, but one possible way of going after it might be to actually
    use a Terminal Server hiding behind an IIS Server using TSAC plug-in. I
    suggest this only because it moves the data access back into a world very
    familiar to Access, it provides you the opportunity to make the IIS server a
    forward placed DMZ server where you authenticate first and then get a tunnel
    into the TS. It means that your development remains firmly in the world of
    Access, without pushing you to deal with lowest common denominator
    conditions on trying to front a website on an Access database that you have
    overloaded and really need to have on SQL. My thinking is that a pretty
    cheap webserver in DMZ, plus a fairly simple TS Apps mode server would
    address everything fairly well without making the security more of a
    nightmare than the definition of the problem itself has created....sharing
    an Access database inside and outside the LAN from your PDC acting as the
    firewall. At least the use of a DMZ webserver filters the traffic at the
    front firewall, you then authenticate at the webserver, you have the option
    to authenticate again at the TS, the TS can be behind the second firewall
    and part of your domain, and the IIS can be which ever way you want to go on
    domain membership or not.

    Once your TS session is running, you have no special development issues to
    deal with in Access other than what you are already doing for your LAN based
    users....you simple make your remote users limited to read-only on the forms
    and reports, and lock them out of direct access to the tables. From a cost
    standpoint, you have a fairly reasonable solution and you have spread the
    load around. You could even put the Access database on the TS itself and
    make all users run a TS session to hit the database file directly, though
    here again you will reveal that 30 users on a single Access database may be
    getting a bit on the highend, but at least you wouldn't be putting that
    traffic load on the SBS itself anymore. You would have IIS load of the SBS,
    the file service off, and you could choose to use ISA for the firewall or
    not for the TS tunneling system. Invested cost in this would be starting at
    about $4000 for the pair of servers (other than Windows and TS CALs).

    After you have devised whatever you consider to be your "best idea", if it's
    something like what I proposed or something different, you will at least
    have something you can put a cost on and compare to the other options you
    previously discussed and you can make a reality check decision. It wouldn't
    surprise me in the least if someone else reading this thread in a different
    group were to post back with totally opposite ideas about how to do this, or
    even arguing that ~your way~ makes more sense to them. To such a comment, I
    would only say that I spend the majority of my IT life supporting SBS based
    sites, and designing them for stability and security based upon relative ROI
    considerations. Everything about this would be a compromise because that's
    what running an SMB business or being a consultant is all about....being
    successful at getting your best ROI in a compromise situation.


    "John" <> wrote in message
    news:...
    > Thanks for the very comprehensive analysis of the situation. Appreciate

    that
    > very much.
    >
    > As for access, all we are looking for is some very selected information to
    > be *viewed only* by some external users, so hopefully the load on access
    > will not too bad. In that case, would another server machine with IIS do

    the
    > trick (presumably it has to be win2k server and not win2k professional)?
    > Also, presumably it will be a member of the sbs domain. Also I presume the
    > best way is to get a second broadband connection for the new web server?
    >
    > Thanks
    >
    > Regards
    >
    >
    >
    > "Jeff Middleton [SBS-MVP]" <> wrote in message
    > news:...
    > > Since this is SBS 2000 you are hosting from, I'll start by clarifying to
    > > anyone who isn't familiar with the SBS platform (but maybe was

    > cross-posted
    > > into this discussion) that the SBS suite include ISA Server (firewall),

    > SQL
    > > Server, Exchange Server and the SBS is required to be the root AD server

    > as
    > > a Domain Controller.
    > >
    > > I'm replying at this point of the thread just to "include" the previous
    > > comments made by others. As John Timney stated succinctly, I wools say

    you
    > > probably can do this technically, you probably shouldn't do it
    > > professionally.
    > >
    > > SBS is a very busy box by default, a lot of stuff going on. Some people
    > > consider SBS to be a house of cards, ready to collapse if you aren't
    > > careful. I don't really subscribe to that thought, but it's a fair

    > comment,
    > > particularly when you start to extend the included technologies in the

    way
    > > you have indicated....frankly, in the wrong way.
    > >
    > > SBS 2000 is intended to be a server that is a gateway to the web as a
    > > firewall via ISA, and to provide intranet functionality to the LAN with

    up
    > > to 50 users. This is what you are doing. The problem is that you are

    then
    > > wanting to do all that....and next you want to make it a fully

    functional
    > > public web server, except you don't want to do that in the efficient way
    > > that webservers would be designed....using SQL under the hood, nor are

    you
    > > proposing to do that in the secure manner that represents a best
    > > practice....a web server in DMZ.
    > >
    > > Therefore, if I were being called in as a consultant, I would look at

    what
    > > you are outlining and play the devils advocate of why this is a bad

    idea.
    > > You are taking technology and not using it the way any best practice for

    > the
    > > individual components would be recommended. This is a lot like not using
    > > best practices like never use a sharp knife and cut toward your hand,

    > never
    > > user a screwdriver as a chisel, never store dangerous chemicals in a

    reach
    > > of children in your house. It's fine if you say...but I'm only slicing
    > > butter, I'm just knocking caulk off of a tile, and I don't have any

    kids.
    > >
    > > Let's look at a few of the best practice concepts that you aren't

    > following:
    > >
    > > - Don't expose shared resources on a DC to the web
    > > - Don't expose and intranet site to the web
    > > - Always place public IIS webserver in DMZ
    > > - Isolate your front-end and backend web servers, and use a secure

    method
    > > for handling the backend server such as SQL
    > > - Minimize the functions on a webserver so that you can lock it down as

    > much
    > > as possible if it's exposed to the public, and particularly don't

    install
    > > any applications not required for it's role as a web server.
    > > - Don't run ISA on a server on a DNS server, DC, Exchange Server, or SQL
    > > Server, and particularly not on one that you are exposing. (This is that
    > > special rule about SBS servers where you are violating every rule of
    > > deployment with ISA, except that the SBS product is tuned to use ISA as

    a
    > > firewall to protect this server in those roles. However, at the point

    that
    > > you expose all of these functions to traffic entering from all

    interfaces,
    > > you really have gone over the edge of sanity in deployment.
    > > - Don't place business critical assets on a server directly hosting

    public
    > > and non-authenticated access.
    > > - Avoid placing business critical assets required to keep your company
    > > running hour by hour in a role that increases the risk of critical

    > failures,
    > > or extended recovery times. Diffuse your risk by protecting and

    > simplifying
    > > the most critical assets you have to improve your management options,

    and
    > > critical response repair options.
    > >
    > > I know, this is the point where someone asking the questions you are

    > asking
    > > typically says "But if all this is such a bad set of practices, them MS
    > > should be telling people that they can buy an SBS to run their whole

    > office
    > > from in this way." Well, yeah, that's true, and I personally wish that

    MS
    > > didn't give people the impression that what you are asking is even
    > > plausible, much less supported. The fact is that SBS includes a broad

    > range
    > > of products, but I can assure you that it's not the thought that MS dev

    > has
    > > that anyone is going to deploy a server using everything that is

    possible
    > to
    > > do with any individual component, and yet do all of those things
    > > concurrently on a single machine. It's not that the technology would

    > prevent
    > > it, it's more that common sense would suggest to you that at some point

    > you
    > > have to look at the cost of the entire company depending upon a group of
    > > critical technologies.....and you have to see that you are

    overextending.
    > >
    > > A company with 20 users internally and another 10 users remotely is
    > > presumably paying something on the order of $3000-8000 per day in

    salary,
    > > right? Oh, I suppose it could be less than that, but realistically, if

    > this
    > > company existed only to pay 20 people $5/hr each, and it had no other
    > > business assets, therefore no other cashflow considerations, well then

    you
    > > might have an argument for why you don't see the return on investment
    > > arguments for adding more assets in order to better protect the assets

    you
    > > are already producing income with.
    > >
    > > Far to many small businesses fail to realize when they are underfunding
    > > their business in terms of technology investments. Many SMBs see only

    cost
    > > with the equipment, and they don't see productivity, or perhaps they

    don't
    > > see how to measure the productivity as a separate distinction from "what

    > if
    > > this stopped working". The fact that SBS is as reliable as it is makes

    it
    > > seem that it would be reasonable to run this one server right up to the
    > > point that you have the CPU at 70%, the disk drives at 80% capacity, and

    > the
    > > users all being delayed just about 30 milliseconds less than the time it
    > > takes for them to not lose their attention to their tasks. That's just
    > > insane. There's no room to grow the business, or extend to the next
    > > opportunity.
    > >
    > > It's inherent in any business that there's a point where you have to

    look
    > at
    > > what you have that is working really well and then decide that you don't
    > > push it further, you reinvest in the next place to grow the next thing

    to
    > > support your business needs continuing to be met without increasing risk

    > or
    > > dramatically complicating the complexity of maintaining the overall
    > > environment.
    > >
    > >
    > > With all these things considered in total, I think you really should be
    > > looking at a minimum of one more server, possible two, plus another

    > firewall
    > > to create a DMZ. You probably need a dedicated IIS server if that's the

    > best
    > > way to deploy your applications forward to the web. However, I would
    > > question whether or not you really are doing yourself a favor by using a

    > web
    > > server interface to front end an Access database if the Access database

    is
    > > really that critical to your customer solution and not something you can
    > > work around with separate SQL presentation. Maybe you need to look at
    > > putting a Terminal Server in for the external connections, but this

    could
    > > depend upon whether the remote connections are by trusted and

    > authenticated
    > > users, or not.
    > >
    > > The situation you describe sounds to me more like a scenario where I'm

    not
    > > sure that you are looking at a big enough picture to understand what

    your
    > > best options are for the company.....not for the technology, but for the
    > > company. I would be inclined to want to know more about where this

    company
    > > is going...and coming from...to understand if the way that you are

    > handling
    > > this process is leading you into a box you will regret, and maybe your

    > best
    > > options need to be putting a lot more on the table than just another IIS
    > > server.
    > >
    > >
    > >

    >
    >
    Jeff Middleton [SBS-MVP], Dec 23, 2003
    #11
  12. John

    John Guest

    Thanks again for taking the time to explain things in detail. In access we
    have a front-end/back-end situation where all tables are in the back end and
    everything else; forms, queries, are in the front end. Is it feasible to
    move the backend tables to the SQL Server and link the sql server tables in
    the access front end? It will not help access desktop app as all processing
    will still be done by access but the web app can presumably benefit from
    tables being on the SQL Server? Then over time we can re-write the desktop
    app to be native sql.

    Thanks

    Regards


    "Jeff Middleton [SBS-MVP]" <> wrote in message
    news:%...
    > To address your follow-up questions, I'm sort of having to buy into some
    > conditions that are complex to swallow without more details. For instance,
    > typically one things of an Access database as either a relational database
    > with the Tables, Forms and Reports in a single MDB file, or you might have

    a
    > front-end/Back-end arrangement to split the security and management apart.
    > Regardless, I would normally think that you would not expect to do things
    > like ODBC in order to hook to the backend database from more than one
    > frontend. Therefore, when you speak of splitting a frontend to an IIS
    > server, the question would return to "what are you trying to accomplish"
    > because if you are looking to increase security, you have to consider that
    > you would need to figure out how to secure the ability to hook from inside
    > the LAN and from outside the LAN to the same database, and yet secure it.

    If
    > the theory is that you are going to authenticate your users, my question
    > would return to questioning if a basic IIS server facing the public really
    > simplifies your problem or creates it.
    >
    > One option would be to devise a way to provide a secure connection to the
    > remote users, but I don't have the information to know if you are

    referring
    > to 10 people at a different site, or if it's ten specific computers that
    > travel, or if we are talking an average of 10 customers from various

    places
    > that changes day to day. There's a lot here that sort of defies the

    simple
    > answer.
    >
    > As for putting the server in DMZ and part of the domain, this is going to

    be
    > entirely debatable to how you would plan to address the previous topic.
    >
    > This is why I was suggesting at the end of my last post that I would

    expect
    > to backaway from the technology a little bit to look at the business plan
    > first, then let the technical requirements feed the discussion of what
    > should be done to meet the business needs and still secure all aspects,

    and
    > address the technical issues you can't change (like switching to SQL from
    > Access which is probably the single most valuable change you could make in
    > this situation).
    >
    > There's plenty of room for debate on how you would address a redesign of
    > this package, but one possible way of going after it might be to actually
    > use a Terminal Server hiding behind an IIS Server using TSAC plug-in. I
    > suggest this only because it moves the data access back into a world very
    > familiar to Access, it provides you the opportunity to make the IIS server

    a
    > forward placed DMZ server where you authenticate first and then get a

    tunnel
    > into the TS. It means that your development remains firmly in the world of
    > Access, without pushing you to deal with lowest common denominator
    > conditions on trying to front a website on an Access database that you

    have
    > overloaded and really need to have on SQL. My thinking is that a pretty
    > cheap webserver in DMZ, plus a fairly simple TS Apps mode server would
    > address everything fairly well without making the security more of a
    > nightmare than the definition of the problem itself has created....sharing
    > an Access database inside and outside the LAN from your PDC acting as the
    > firewall. At least the use of a DMZ webserver filters the traffic at the
    > front firewall, you then authenticate at the webserver, you have the

    option
    > to authenticate again at the TS, the TS can be behind the second firewall
    > and part of your domain, and the IIS can be which ever way you want to go

    on
    > domain membership or not.
    >
    > Once your TS session is running, you have no special development issues to
    > deal with in Access other than what you are already doing for your LAN

    based
    > users....you simple make your remote users limited to read-only on the

    forms
    > and reports, and lock them out of direct access to the tables. From a cost
    > standpoint, you have a fairly reasonable solution and you have spread the
    > load around. You could even put the Access database on the TS itself and
    > make all users run a TS session to hit the database file directly, though
    > here again you will reveal that 30 users on a single Access database may

    be
    > getting a bit on the highend, but at least you wouldn't be putting that
    > traffic load on the SBS itself anymore. You would have IIS load of the

    SBS,
    > the file service off, and you could choose to use ISA for the firewall or
    > not for the TS tunneling system. Invested cost in this would be starting

    at
    > about $4000 for the pair of servers (other than Windows and TS CALs).
    >
    > After you have devised whatever you consider to be your "best idea", if

    it's
    > something like what I proposed or something different, you will at least
    > have something you can put a cost on and compare to the other options you
    > previously discussed and you can make a reality check decision. It

    wouldn't
    > surprise me in the least if someone else reading this thread in a

    different
    > group were to post back with totally opposite ideas about how to do this,

    or
    > even arguing that ~your way~ makes more sense to them. To such a comment,

    I
    > would only say that I spend the majority of my IT life supporting SBS

    based
    > sites, and designing them for stability and security based upon relative

    ROI
    > considerations. Everything about this would be a compromise because that's
    > what running an SMB business or being a consultant is all about....being
    > successful at getting your best ROI in a compromise situation.
    >
    >
    > "John" <> wrote in message
    > news:...
    > > Thanks for the very comprehensive analysis of the situation. Appreciate

    > that
    > > very much.
    > >
    > > As for access, all we are looking for is some very selected information

    to
    > > be *viewed only* by some external users, so hopefully the load on access
    > > will not too bad. In that case, would another server machine with IIS do

    > the
    > > trick (presumably it has to be win2k server and not win2k professional)?
    > > Also, presumably it will be a member of the sbs domain. Also I presume

    the
    > > best way is to get a second broadband connection for the new web server?
    > >
    > > Thanks
    > >
    > > Regards
    > >
    > >
    > >
    > > "Jeff Middleton [SBS-MVP]" <> wrote in message
    > > news:...
    > > > Since this is SBS 2000 you are hosting from, I'll start by clarifying

    to
    > > > anyone who isn't familiar with the SBS platform (but maybe was

    > > cross-posted
    > > > into this discussion) that the SBS suite include ISA Server

    (firewall),
    > > SQL
    > > > Server, Exchange Server and the SBS is required to be the root AD

    server
    > > as
    > > > a Domain Controller.
    > > >
    > > > I'm replying at this point of the thread just to "include" the

    previous
    > > > comments made by others. As John Timney stated succinctly, I wools say

    > you
    > > > probably can do this technically, you probably shouldn't do it
    > > > professionally.
    > > >
    > > > SBS is a very busy box by default, a lot of stuff going on. Some

    people
    > > > consider SBS to be a house of cards, ready to collapse if you aren't
    > > > careful. I don't really subscribe to that thought, but it's a fair

    > > comment,
    > > > particularly when you start to extend the included technologies in the

    > way
    > > > you have indicated....frankly, in the wrong way.
    > > >
    > > > SBS 2000 is intended to be a server that is a gateway to the web as a
    > > > firewall via ISA, and to provide intranet functionality to the LAN

    with
    > up
    > > > to 50 users. This is what you are doing. The problem is that you are

    > then
    > > > wanting to do all that....and next you want to make it a fully

    > functional
    > > > public web server, except you don't want to do that in the efficient

    way
    > > > that webservers would be designed....using SQL under the hood, nor are

    > you
    > > > proposing to do that in the secure manner that represents a best
    > > > practice....a web server in DMZ.
    > > >
    > > > Therefore, if I were being called in as a consultant, I would look at

    > what
    > > > you are outlining and play the devils advocate of why this is a bad

    > idea.
    > > > You are taking technology and not using it the way any best practice

    for
    > > the
    > > > individual components would be recommended. This is a lot like not

    using
    > > > best practices like never use a sharp knife and cut toward your hand,

    > > never
    > > > user a screwdriver as a chisel, never store dangerous chemicals in a

    > reach
    > > > of children in your house. It's fine if you say...but I'm only slicing
    > > > butter, I'm just knocking caulk off of a tile, and I don't have any

    > kids.
    > > >
    > > > Let's look at a few of the best practice concepts that you aren't

    > > following:
    > > >
    > > > - Don't expose shared resources on a DC to the web
    > > > - Don't expose and intranet site to the web
    > > > - Always place public IIS webserver in DMZ
    > > > - Isolate your front-end and backend web servers, and use a secure

    > method
    > > > for handling the backend server such as SQL
    > > > - Minimize the functions on a webserver so that you can lock it down

    as
    > > much
    > > > as possible if it's exposed to the public, and particularly don't

    > install
    > > > any applications not required for it's role as a web server.
    > > > - Don't run ISA on a server on a DNS server, DC, Exchange Server, or

    SQL
    > > > Server, and particularly not on one that you are exposing. (This is

    that
    > > > special rule about SBS servers where you are violating every rule of
    > > > deployment with ISA, except that the SBS product is tuned to use ISA

    as
    > a
    > > > firewall to protect this server in those roles. However, at the point

    > that
    > > > you expose all of these functions to traffic entering from all

    > interfaces,
    > > > you really have gone over the edge of sanity in deployment.
    > > > - Don't place business critical assets on a server directly hosting

    > public
    > > > and non-authenticated access.
    > > > - Avoid placing business critical assets required to keep your company
    > > > running hour by hour in a role that increases the risk of critical

    > > failures,
    > > > or extended recovery times. Diffuse your risk by protecting and

    > > simplifying
    > > > the most critical assets you have to improve your management options,

    > and
    > > > critical response repair options.
    > > >
    > > > I know, this is the point where someone asking the questions you are

    > > asking
    > > > typically says "But if all this is such a bad set of practices, them

    MS
    > > > should be telling people that they can buy an SBS to run their whole

    > > office
    > > > from in this way." Well, yeah, that's true, and I personally wish that

    > MS
    > > > didn't give people the impression that what you are asking is even
    > > > plausible, much less supported. The fact is that SBS includes a broad

    > > range
    > > > of products, but I can assure you that it's not the thought that MS

    dev
    > > has
    > > > that anyone is going to deploy a server using everything that is

    > possible
    > > to
    > > > do with any individual component, and yet do all of those things
    > > > concurrently on a single machine. It's not that the technology would

    > > prevent
    > > > it, it's more that common sense would suggest to you that at some

    point
    > > you
    > > > have to look at the cost of the entire company depending upon a group

    of
    > > > critical technologies.....and you have to see that you are

    > overextending.
    > > >
    > > > A company with 20 users internally and another 10 users remotely is
    > > > presumably paying something on the order of $3000-8000 per day in

    > salary,
    > > > right? Oh, I suppose it could be less than that, but realistically, if

    > > this
    > > > company existed only to pay 20 people $5/hr each, and it had no other
    > > > business assets, therefore no other cashflow considerations, well then

    > you
    > > > might have an argument for why you don't see the return on investment
    > > > arguments for adding more assets in order to better protect the assets

    > you
    > > > are already producing income with.
    > > >
    > > > Far to many small businesses fail to realize when they are

    underfunding
    > > > their business in terms of technology investments. Many SMBs see only

    > cost
    > > > with the equipment, and they don't see productivity, or perhaps they

    > don't
    > > > see how to measure the productivity as a separate distinction from

    "what
    > > if
    > > > this stopped working". The fact that SBS is as reliable as it is makes

    > it
    > > > seem that it would be reasonable to run this one server right up to

    the
    > > > point that you have the CPU at 70%, the disk drives at 80% capacity,

    and
    > > the
    > > > users all being delayed just about 30 milliseconds less than the time

    it
    > > > takes for them to not lose their attention to their tasks. That's just
    > > > insane. There's no room to grow the business, or extend to the next
    > > > opportunity.
    > > >
    > > > It's inherent in any business that there's a point where you have to

    > look
    > > at
    > > > what you have that is working really well and then decide that you

    don't
    > > > push it further, you reinvest in the next place to grow the next thing

    > to
    > > > support your business needs continuing to be met without increasing

    risk
    > > or
    > > > dramatically complicating the complexity of maintaining the overall
    > > > environment.
    > > >
    > > >
    > > > With all these things considered in total, I think you really should

    be
    > > > looking at a minimum of one more server, possible two, plus another

    > > firewall
    > > > to create a DMZ. You probably need a dedicated IIS server if that's

    the
    > > best
    > > > way to deploy your applications forward to the web. However, I would
    > > > question whether or not you really are doing yourself a favor by using

    a
    > > web
    > > > server interface to front end an Access database if the Access

    database
    > is
    > > > really that critical to your customer solution and not something you

    can
    > > > work around with separate SQL presentation. Maybe you need to look at
    > > > putting a Terminal Server in for the external connections, but this

    > could
    > > > depend upon whether the remote connections are by trusted and

    > > authenticated
    > > > users, or not.
    > > >
    > > > The situation you describe sounds to me more like a scenario where I'm

    > not
    > > > sure that you are looking at a big enough picture to understand what

    > your
    > > > best options are for the company.....not for the technology, but for

    the
    > > > company. I would be inclined to want to know more about where this

    > company
    > > > is going...and coming from...to understand if the way that you are

    > > handling
    > > > this process is leading you into a box you will regret, and maybe your

    > > best
    > > > options need to be putting a lot more on the table than just another

    IIS
    > > > server.
    > > >
    > > >
    > > >

    > >
    > >

    >
    >
    John, Dec 23, 2003
    #12
  13. John

    Mark Mancini Guest

    Ok, so how much and how long do you think it will take to do this? I am
    sure that it is less than you think.

    --
    Sincerely,
    Mark Mancini, CCA, CCNA, Master CIW&CI, CNE 4&5, MCSE+I 4&2000
    www.MCSE2000.com
    www.AppLauncher.com



    "John" <> wrote in message
    news:...
    > We will then have to change the internal access app which has taken years

    to
    > develop.
    >
    > Regards
    >
    >
    > "Mark Mancini" <> wrote in message
    > news:...
    > > a better solution......
    > >
    > > Is this an Access db? You can easily port it to MySQL and php and put

    it
    > on
    > > a webserver for clients to access as well as yourslef. You can get PHP
    > > programmers cheap!
    > >
    > > --
    > > Sincerely,
    > > Mark Mancini, CCA, CCNA, Master CIW&CI, CNE 4&5, MCSE+I 4&2000
    > > www.MCSE2000.com
    > > www.AppLauncher.com
    > >
    > >
    > >
    > > "John" <> wrote in message
    > > news:...
    > > > Hi
    > > >
    > > > We have an SBS2000 server which has an access database running

    > internally,
    > > > supporting around 20 users. The server is connected to a broadband
    > > > connection. Is it viable for us to run an asp.net web site on the same
    > > > server that allows visitors (around ten on average) to view the

    content
    > of
    > > > the internal database? As you can see there are several issues here;
    > > > performance of server, security, broadband bandwidth, access etc.
    > > >
    > > > If this is not feasible, what would be the recommended way to achieve

    > > this?
    > > > It is not possible to rewrite access database for SQL server just now.
    > > >
    > > > Thanks
    > > >
    > > > Regards
    > > >
    > > >
    > > >

    > >
    > >

    >
    >
    Mark Mancini, Dec 26, 2003
    #13
  14. John

    Mark Mancini Guest

    how much are you going to spend on time and firewall and I am thinking this
    will still be cheaper.

    --
    Sincerely,
    Mark Mancini, CCA, CCNA, Master CIW&CI, CNE 4&5, MCSE+I 4&2000
    www.MCSE2000.com
    www.AppLauncher.com



    "John" <> wrote in message
    news:...
    > We will then have to change the internal access app which has taken years

    to
    > develop.
    >
    > Regards
    >
    >
    > "Mark Mancini" <> wrote in message
    > news:...
    > > a better solution......
    > >
    > > Is this an Access db? You can easily port it to MySQL and php and put

    it
    > on
    > > a webserver for clients to access as well as yourslef. You can get PHP
    > > programmers cheap!
    > >
    > > --
    > > Sincerely,
    > > Mark Mancini, CCA, CCNA, Master CIW&CI, CNE 4&5, MCSE+I 4&2000
    > > www.MCSE2000.com
    > > www.AppLauncher.com
    > >
    > >
    > >
    > > "John" <> wrote in message
    > > news:...
    > > > Hi
    > > >
    > > > We have an SBS2000 server which has an access database running

    > internally,
    > > > supporting around 20 users. The server is connected to a broadband
    > > > connection. Is it viable for us to run an asp.net web site on the same
    > > > server that allows visitors (around ten on average) to view the

    content
    > of
    > > > the internal database? As you can see there are several issues here;
    > > > performance of server, security, broadband bandwidth, access etc.
    > > >
    > > > If this is not feasible, what would be the recommended way to achieve

    > > this?
    > > > It is not possible to rewrite access database for SQL server just now.
    > > >
    > > > Thanks
    > > >
    > > > Regards
    > > >
    > > >
    > > >

    > >
    > >

    >
    >
    Mark Mancini, Dec 26, 2003
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page