Re: How to do this?

From: John (john_at_nospam.infovis.co.uk)
Date: 12/23/03 

Date: Tue, 23 Dec 2003 20:15:19 -0000

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]" <jeff@cfisolutions.com> wrote in message
news:%23O73IoXyDHA.1740@TK2MSFTNGP09.phx.gbl...
> 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" <john@nospam.infovis.co.uk> wrote in message
> news:eFxFsXXyDHA.3772@TK2MSFTNGP11.phx.gbl...
> > 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]" <jeff@cfisolutions.com> wrote in message
> > news:uBN6eYWyDHA.1196@TK2MSFTNGP12.phx.gbl...
> > > 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.
> > >
> > >
> > >
> >
> >
>
>