By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,407 Members | 2,842 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,407 IT Pros & Developers. It's quick & easy.

Which hardware upgrades are more important

P: n/a
I know this is a difficult one to answer, but I am interested in opinions on
what hardware upgrades would be recommended with the following.

Access 2000 running in a split config, but all in Terminal Server. Currently
15 users. This means that all files reside on the server and all processing
happens there. Back-end is currently Access, but it will be upsized to SQL
Server . So for this question assume SQL Server back-end.

So what priority would you give to things like memory, multiple processors,
processor speed, hard drive speed, graphics cards etc. And which are just
irrelevant and not worth worrying about, though I assume none are.

I know the Access recommended requirements. It is your real world experience
that I am more interested in.

Jeff

Jan 4 '06 #1
Share this Question
Share on Google+
33 Replies


P: n/a
Memory would be number 1 on the list as both TS snd SQL like lot's of
RAM. I would recommend a min of 4GB of RAM and as much processor as you
can get. This is especially true if you are going to run both on the
same server.

Jan 5 '06 #2

P: n/a
"Jeff" <je************@asken.com.au> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:
I know this is a difficult one to answer, but I am interested in
opinions on what hardware upgrades would be recommended with the
following.

Access 2000 running in a split config, but all in Terminal Server.
Currently 15 users. This means that all files reside on the server
and all processing happens there. Back-end is currently Access,
but it will be upsized to SQL Server . So for this question assume
SQL Server back-end.

So what priority would you give to things like memory, multiple
processors, processor speed, hard drive speed, graphics cards etc.
And which are just irrelevant and not worth worrying about, though
I assume none are.

I know the Access recommended requirements. It is your real world
experience that I am more interested in.


Access is the least of your worries.

I would never put SQL Server on the Terminal Server if it was
serving apps hosted on the TS -- I'd put it on another machine.

RAM is basically a TS issue. I don't know what the official
recommendations are, but I like to have 256MBs per concurrent user.
But perhaps you only need 64MBs. I don't know.

More is always better when it comes to RAM.

Don't forget about the bandwidth of your connection. One of my
clients recently put a gigabit switch on their incoming Internet
connection and it made TS access substantially more snappy.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #3

P: n/a
Something like the Blue Gene/L should be adequate.

(just a guess!)

Jan 5 '06 #4

P: n/a
Actually, that was one of the questions I was asked. The client is putting
in a second box, one with SQL Server and the original for all other apps.
He was wondering what is better - putting TS on both boxes or just on one,
and which one.

If on both boxes, TS on the SQL box would only service the database. The
other box and its install of TS would server all other apps. I thought TS on
both a bit of an overkill and suggested SQL on one box with nothing else,
and TS and all apps on the other box.

Save all the processing power of the SQL box for SQL.

Without a lot of experience here this seemed to make sense - but in this
industry 'sense' is not always correct.

Jeff

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...
"Jeff" <je************@asken.com.au> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:
I know this is a difficult one to answer, but I am interested in
opinions on what hardware upgrades would be recommended with the
following.

Access 2000 running in a split config, but all in Terminal Server.
Currently 15 users. This means that all files reside on the server
and all processing happens there. Back-end is currently Access,
but it will be upsized to SQL Server . So for this question assume
SQL Server back-end.

So what priority would you give to things like memory, multiple
processors, processor speed, hard drive speed, graphics cards etc.
And which are just irrelevant and not worth worrying about, though
I assume none are.

I know the Access recommended requirements. It is your real world
experience that I am more interested in.


Access is the least of your worries.

I would never put SQL Server on the Terminal Server if it was
serving apps hosted on the TS -- I'd put it on another machine.

RAM is basically a TS issue. I don't know what the official
recommendations are, but I like to have 256MBs per concurrent user.
But perhaps you only need 64MBs. I don't know.

More is always better when it comes to RAM.

Don't forget about the bandwidth of your connection. One of my
clients recently put a gigabit switch on their incoming Internet
connection and it made TS access substantially more snappy.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Jan 5 '06 #5

P: n/a
Say what?

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Something like the Blue Gene/L should be adequate.

(just a guess!)

Jan 5 '06 #6

P: n/a
Blue Gene/L is reputed to be the world's fastest super computer. My
statement reflects my concern that running fifteen concurrent instances
of Access and one of MS-SQL Server on one machine may be very
demanding. Might it be cheaper/faster to buy 15 Access licenses so that
each user can use his/her own client machine. I can see that this is
off-topic as it seems you have already decided your course, so just
ignore it.

Jan 5 '06 #7

P: n/a
You need 15 Access licenses to run 15 users on TS.

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Blue Gene/L is reputed to be the world's fastest super computer. My
statement reflects my concern that running fifteen concurrent instances
of Access and one of MS-SQL Server on one machine may be very
demanding. Might it be cheaper/faster to buy 15 Access licenses so that
each user can use his/her own client machine. I can see that this is
off-topic as it seems you have already decided your course, so just
ignore it.

Jan 5 '06 #8

P: n/a

"David W. Fenton" <XX*******@dfenton.com.invalid> wrote in message
news:Xn**********************************@127.0.0. 1...
"Jeff" <je************@asken.com.au> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:
I know this is a difficult one to answer, but I am interested in
opinions on what hardware upgrades would be recommended with the
following.

Access 2000 running in a split config, but all in Terminal Server.
Currently 15 users. This means that all files reside on the server
and all processing happens there. Back-end is currently Access,
but it will be upsized to SQL Server . So for this question assume
SQL Server back-end.

So what priority would you give to things like memory, multiple
processors, processor speed, hard drive speed, graphics cards etc.
And which are just irrelevant and not worth worrying about, though
I assume none are.

I know the Access recommended requirements. It is your real world
experience that I am more interested in.


Access is the least of your worries.

I would never put SQL Server on the Terminal Server if it was
serving apps hosted on the TS -- I'd put it on another machine.

RAM is basically a TS issue. I don't know what the official
recommendations are, but I like to have 256MBs per concurrent user.
But perhaps you only need 64MBs. I don't know.

More is always better when it comes to RAM.

Don't forget about the bandwidth of your connection. One of my
clients recently put a gigabit switch on their incoming Internet
connection and it made TS access substantially more snappy.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/


I treat each Access user as a power user when Microsoft's recommendations
for sizing TS.
Jan 5 '06 #9

P: n/a
paii, Ron wrote:
You need 15 Access licenses to run 15 users on TS.


Unless what is installed on the TS is the Access Runtime.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Jan 5 '06 #10

P: n/a
Lyle Fairfield wrote:
Blue Gene/L is reputed to be the world's fastest super computer. My
statement reflects my concern that running fifteen concurrent
instances of Access and one of MS-SQL Server on one machine may be
very demanding. Might it be cheaper/faster to buy 15 Access licenses
so that each user can use his/her own client machine. I can see that
this is off-topic as it seems you have already decided your course,
so just ignore it.


Our two main terminal servers typically have around 35 to 40 users
concurrently with the vast majority of those running Access apps (A2K
clients to server databases in this case). Others might be using a
published Delphi app which I would expect to be only a bit "lighter"
resource wise.

These are nice blade units but nothing "ultra". I believe they are dual
xeons with 2 GB of RAM each. There are occassions where we have to divert
everyone to a single box and things might slow down a bit while that is
going on, but otherwise performance has been very good.
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Jan 5 '06 #11

P: n/a
Do you think the single machine user could get some notion of what this
is like by opening 15 or 20 instances of an Access application and a
data editing form in same? But then how to get the 15 apps to do some
editing? I think code would not be fair, as code is going to do a
million things while fingers do one.
Did you test to see how this would work before implementation? How?
And the application. Is it flop hungry; is most of the work done on the
DB server?

Well, too many questions, I know. Maybe when you;re bored! :-)

Jan 5 '06 #12

P: n/a
paii, Ron wrote:
You need 15 Access licenses to run 15 users on TS.


I didn't know that. Then what is the purpose of using TS for 15 users?

--
Lyle Fairfield
Jan 5 '06 #13

P: n/a

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:DY**********@read1.cgocable.net...
paii, Ron wrote:
You need 15 Access licenses to run 15 users on TS.


I didn't know that. Then what is the purpose of using TS for 15 users?

--
Lyle Fairfield


It lets your users work from simple terminals and/or from remote locations.
Jan 5 '06 #14

P: n/a
Lyle Fairfield wrote:
paii, Ron wrote:
You need 15 Access licenses to run 15 users on TS.


I didn't know that. Then what is the purpose of using TS for 15 users?


One machine to configure instead of 15. Plus that one machine is sitting in
the IT department where I can get at it (and others cannot).

Better performance over low bandwidth connections.

The TS and Citrix people would go on about the myriad of advantages to the
thin client model, but I find most of that to be hype. I find the primary
PRO to be the low bandwidth performance as opposed to using a fat client
remotely and the primary CON to be all the headaches with printing and
Email.

Overall I would NOT recommend TS for use in a LAN environment where the
bandwidth issue is not present.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com


Jan 5 '06 #15

P: n/a
I understand the bit about simple terminals (but the last one of those
I saw was in the previous century), but the remote locations? You mean
the TS can find and connect to the DB while the Remote Locations can't?
Hmmm. And someone feels it's not secure enough to enable the DB server
over the NET as the TS is enabled? I disagree but it's your/their
decision.

Jan 5 '06 #16

P: n/a
Bri

Lyle Fairfield wrote:
I understand the bit about simple terminals (but the last one of those
I saw was in the previous century), but the remote locations? You mean
the TS can find and connect to the DB while the Remote Locations can't?
Hmmm. And someone feels it's not secure enough to enable the DB server
over the NET as the TS is enabled? I disagree but it's your/their
decision.


TS only send the screen info down the line and this can be set to send
the bare minimum (min colours, no fancy see as you drag, etc) so that
the response is acceptable over a modem (56k or less even). It doesn't
take a lot of data moving to the FE to exceed the screen data sent via TS.

Security of the data isn't really the issue. AFAIK, Both TS and a remote
connection to SQL Server can be secured to similar levels. Integrity of
the data is more important. One of my apps is used by workers in the
field where they have VERY unreliable phone lines. If a line drops while
they are working, they just dial up again and their TS session picks up
exactly where they left off. If they were pulling data (or worse sending
data for a write) from a local FE and the line goes down, then they
could lose or corrupt the current process.

TS also makes deploying an FE update much easier. All of the user's
profiles are on the same machine. The user doesn't have to download a
5-10 mb FE across to their local PC via a slow line.

Oh, and 'simple terminal' could be replaced with 'those older
PCs/Laptops we can now keep around for a while longer'.

--
Bri

Jan 5 '06 #17

P: n/a
Lyle Fairfield wrote:
I understand the bit about simple terminals (but the last one of those
I saw was in the previous century), but the remote locations? You mean
the TS can find and connect to the DB while the Remote Locations
can't? Hmmm. And someone feels it's not secure enough to enable the
DB server over the NET as the TS is enabled? I disagree but it's
your/their decision.


The TS is on the inside and can connect to the DB. The remote locations are
outside and cannot. This is similar to the way web apps work. The web
server has access to resources that the remote client does not and acts as
the go-between. A TS performs the same role and is more secure than letting
the remote users have direct access to the DB.

Keeping in mind that the TS is serving a published application. Not a full
desktop. The remote user has permissions to run only the published app and
has no access to anything except what that app provides. If we did this
over the internet we would of course use a VPN for the TS session.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Jan 5 '06 #18

P: n/a
I am accustomed to useing an MS-SQL server to which the remote client
can connect. I think I understand the TS model better now.

Jan 5 '06 #19

P: n/a
Lyle Fairfield wrote:
I am accustomed to useing an MS-SQL server to which the remote client
can connect. I think I understand the TS model better now.


That was the model I was originally using for my remote apps, but my system
(security) guys told me several years ago that I had to move away from that
for security concerns. For those apps I had to switch to sending
HTTPRequests to a web service instead of connecting directly to the SQL Box.

They would show me reports of the hundreds of malicious attempts per hour
that were hitting the SQL Server when it was exposed to the internet. AFAIK
none of them ever got in, but they were nervous about leaving it set up that
way.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Jan 5 '06 #20

P: n/a

"Rick Brandt" <ri*********@hotmail.com> wrote in message
news:UY*******************@newssvr29.news.prodigy. net...
Lyle Fairfield wrote:
paii, Ron wrote:
You need 15 Access licenses to run 15 users on TS.
I didn't know that. Then what is the purpose of using TS for 15 users?


One machine to configure instead of 15. Plus that one machine is sitting

in the IT department where I can get at it (and others cannot).

Better performance over low bandwidth connections.

The TS and Citrix people would go on about the myriad of advantages to the
thin client model, but I find most of that to be hype. I find the primary
PRO to be the low bandwidth performance as opposed to using a fat client
remotely and the primary CON to be all the headaches with printing and
Email.

Overall I would NOT recommend TS for use in a LAN environment where the
bandwidth issue is not present.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com


I would have to agree about TS on a LAN. We installed TS / Citrix about 6
years ago to replace W98, which improved performance. We are now switching
over to XP/Pro except for remote and shop access.
Jan 5 '06 #21

P: n/a
I don't pretend to know much about security.

But I do ask:

To get into a website I need (I think) a UserName and Password.
To get into an Internet enabled MS-SQL Server I need a Username and
Password.

After I get in, I suppose the UserName is likely to determine how much
damage I can do. I suppose the Server and Website are somewhat similar;
it's quite likely that my UserName may not let me do unlimited damage.

Companies like Interland rent these web-enabled MS-SQL Server DBs by
the thousands. I've had several over the years and have never lost
anything (then again I've never had much there worth stealing!). I've
never heard of these being broken into, although it's clear upon
examining the other (not my) dbs on the server that many of their
owners are very lax about security. I've never heard of any big
intrusion. Maybe they happen. I'm tempted to ask if someone can break
into one of mine which I'm not using at present, but maybe that's not
such a smart idea.

I've worked with MS-SQL servers in multi-million dollar corporations.
The security is ...well there isn't any. Generally anyone using any db
on any server has access to EVERYTHING if he/she knows where to look.
The logins are the Wndows logins so when someone goes to lunch ....
Of course, they pay their dbo's 60 grand a year ... maybe that's why.

Just rambling on...

Jan 5 '06 #22

P: n/a
Lyle Fairfield wrote:
I don't pretend to know much about security.

But I do ask:

To get into a website I need (I think) a UserName and Password.
To get into an Internet enabled MS-SQL Server I need a Username and
Password.

After I get in, I suppose the UserName is likely to determine how much
damage I can do. I suppose the Server and Website are somewhat
similar; it's quite likely that my UserName may not let me do
unlimited damage.

Companies like Interland rent these web-enabled MS-SQL Server DBs by
the thousands. I've had several over the years and have never lost
anything (then again I've never had much there worth stealing!). I've
never heard of these being broken into, although it's clear upon
examining the other (not my) dbs on the server that many of their
owners are very lax about security. I've never heard of any big
intrusion. Maybe they happen. I'm tempted to ask if someone can break
into one of mine which I'm not using at present, but maybe that's not
such a smart idea.

I've worked with MS-SQL servers in multi-million dollar corporations.
The security is ...well there isn't any. Generally anyone using any db
on any server has access to EVERYTHING if he/she knows where to look.
The logins are the Wndows logins so when someone goes to lunch ....
Of course, they pay their dbo's 60 grand a year ... maybe that's why.

Just rambling on...


I had all of these same questions when they told me that I needed to
re-write my external apps. "SQL Server is supposed to use 'REAL' security
so what's the problem with leaving the port open to the internet?"

I asked around a bit on the SS forums and mostly the responses I got agreed
that leaving the server accessible via the internet was a security risk.
Adding fuel to the fire was all of the MS security bulletins that were
coming around almost daily back then. Until I changed my apps one of our
systems guys made sure to CC me on every one of these that he recieved.

Of course most of those bulletins described exploits that could happen only
if you had no password on the default sa account (well duh!).

All in all I can't complain as I was forced to learn a bunch of new
technologies to make the switch and that's always a good thing.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Jan 5 '06 #23

P: n/a
"Jeff" <je************@asken.com.au> wrote in
news:43***********************@per-qv1-newsreader-01.iinet.net.au:
Actually, that was one of the questions I was asked. The client is
putting in a second box, one with SQL Server and the original for
all other apps. He was wondering what is better - putting TS on
both boxes or just on one, and which one.

If on both boxes, TS on the SQL box would only service the
database. The other box and its install of TS would server all
other apps. I thought TS on both a bit of an overkill and
suggested SQL on one box with nothing else, and TS and all apps on
the other box.
Since Win2K Server, all installations of Windows Server have
terminal server installed by default. However, the default
installation allows only administrative logon via remote desktop,
and limits it to two logons at a time. For administrative purposes,
that should be sufficient, without needing to install any additional
CALs. Users won't need to connect to the SQL Server via TS.
Save all the processing power of the SQL box for SQL.

Without a lot of experience here this seemed to make sense - but
in this industry 'sense' is not always correct.


Terminal Server is a power-hungry application. I would tend to put
it on a dedicated box.

Also, users are running programs in it, so your load is subject to a
lot of unpredictable factors. That's why I'd recommend SQL Server on
a separate box, because it isolates the database server from all the
activity taking place on the TS.

That said, one of my clients has MSDE installed on their terminal
server because it supports the Blackberry Enterprise Server software
that is running on the same server. That TS is used by only 10 users
total, and hardly ever more than a couple logged on at once, so the
load is very little. The Blackberry Enterprise Server is also a
pretty low-profile application (despite the impressive-sounding
name), so it and MSDE really don't require much in the way of power.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #24

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@g49g2000cwa.googlegr oups.com:
Blue Gene/L is reputed to be the world's fastest super computer.
My statement reflects my concern that running fifteen concurrent
instances of Access and one of MS-SQL Server on one machine may be
very demanding. Might it be cheaper/faster to buy 15 Access
licenses so that each user can use his/her own client machine. I
can see that this is off-topic as it seems you have already
decided your course, so just ignore it.


Lyle, stick to topics you have experience with.

You're clearly completely ignorant of all aspects of Terminal Server
hosting of Access applications, so you really have nothing of use to
offer here.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #25

P: n/a
"paii, Ron" <pa**@packairinc.com> wrote in
news:Yb********************@athenet.net:

"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:DY**********@read1.cgocable.net...
paii, Ron wrote:
> You need 15 Access licenses to run 15 users on TS.


I didn't know that. Then what is the purpose of using TS for 15
users?


It lets your users work from simple terminals and/or from remote
locations.


Shared data in one location, accessed by people anywhere.

They can be running any OS for which there is a Remote Desktop
client (this includes Macs, and may even include Linux).

All administration is centralized.

You avoid all issues of synchronizing data between multiple
locations.

Etc.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #26

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@g49g2000cwa.googlegr oups.com:
I understand the bit about simple terminals (but the last one of
those I saw was in the previous century), . . . .
This is not really a relevant consideration at all.
. . . but the remote locations? You mean
the TS can find and connect to the DB while the Remote Locations
can't? . . .
Of course.

With everything behind a firewall, you either expose the terminal
server port or a VPN port. Of course, with VPN, you could also use a
server port inside the VPN.

But there is no server port for Jet databases, so this enables
sharing of Jet apps from multiple locations, and requires none of
the overhead of administering a SQL Server installation.
Hmmm. And someone feels it's not secure enough to enable the DB
server over the NET as the TS is enabled? I disagree but it's
your/their decision.


It's idiotic, in my opinion, to expose a DB port or a TS port to the
open Internet. All connections ought to be through a VPN.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #27

P: n/a
Bri <no*@here.com> wrote in news:98dvf.138293$2k.84712@pd7tw1no:

Lyle Fairfield wrote:
I understand the bit about simple terminals (but the last one of
those I saw was in the previous century), but the remote
locations? You mean the TS can find and connect to the DB while
the Remote Locations can't? Hmmm. And someone feels it's not
secure enough to enable the DB server over the NET as the TS is
enabled? I disagree but it's your/their decision.
TS only send the screen info down the line and this can be set to
send the bare minimum (min colours, no fancy see as you drag, etc)
so that the response is acceptable over a modem (56k or less
even). It doesn't take a lot of data moving to the FE to exceed
the screen data sent via TS.


On connections with more bandwidth than dialup, the responsiveness
is quite close to what a local desktop feels like.
Security of the data isn't really the issue. AFAIK, Both TS and a
remote connection to SQL Server can be secured to similar levels.
. . .
But if your back end is Jet, the difference is gigantic -- there is
no way to serve up Jet data to an Access front end to remote
locations, unless you've got huge pipes for your WAN.
. . . Integrity of
the data is more important. One of my apps is used by workers in
the field where they have VERY unreliable phone lines. If a line
drops while they are working, they just dial up again and their TS
session picks up exactly where they left off. If they were pulling
data (or worse sending data for a write) from a local FE and the
line goes down, then they could lose or corrupt the current
process.
That's really only relevant for a non-client/server app, no? That
is, with Jet?
TS also makes deploying an FE update much easier. All of the
user's profiles are on the same machine. The user doesn't have to
download a 5-10 mb FE across to their local PC via a slow line.

Oh, and 'simple terminal' could be replaced with 'those older
PCs/Laptops we can now keep around for a while longer'.


It means you don't have to worry about what they have on the other
end.

All other options for sharing data are much more complicated.

Oh, and I believe that you don't have to have Access installed to be
able to run Access on the TS. You just have to have cross-compatible
Office licenses. I definitely know that you don't have to have the
*same* version of Access installed. I don't have A2K3, but I can run
it on one of my clients' Terminal Servers.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #28

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:XF*******************@newssvr13.news.prodigy. com:
Lyle Fairfield wrote:
I am accustomed to useing an MS-SQL server to which the remote
client can connect. I think I understand the TS model better now.


That was the model I was originally using for my remote apps, but
my system (security) guys told me several years ago that I had to
move away from that for security concerns. For those apps I had
to switch to sending HTTPRequests to a web service instead of
connecting directly to the SQL Box.

They would show me reports of the hundreds of malicious attempts
per hour that were hitting the SQL Server when it was exposed to
the internet. AFAIK none of them ever got in, but they were
nervous about leaving it set up that way.


I still believe it's completely idiotic to have either a Terminal
Server port or a SQL Server port exposed to the Internet.

*All* access to your network from remote users should come in via
your VPN. No ifs, ands, or buts.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #29

P: n/a
David W. Fenton wrote:
Lyle, stick to topics you have experience with.

You're clearly completely ignorant of all aspects of Terminal Server
hosting of Access applications, so you really have nothing of use to
offer here.


Could you, please, list such topics so that I might know those with
which I should stick?

Or, perhaps I could e-mail you for approval before posting?

Jan 5 '06 #30

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:
I don't pretend to know much about security.
And you clearly know next to nothing.
But I do ask:

To get into a website I need (I think) a UserName and Password.
To get into an Internet enabled MS-SQL Server I need a Username
and Password.
Both of which are subject to cracking attempts.

Secondly, if anyone has unsafe passwords, or someone forgets to lock
down the sa account (though recent installations of SQL Server won't
allow sa to have no password, which was the old default), or someone
clears the sa password for testing something and forgets to set it
back, or, or, or, or...
After I get in, I suppose the UserName is likely to determine how
much damage I can do. I suppose the Server and Website are
somewhat similar; it's quite likely that my UserName may not let
me do unlimited damage.
Is it not the case that most SQL Server security these days is
through a domain logon account? So, cracking the SQL Server logon is
cracking a domain logon. If it's only a user, no big deal, but
because of all the problems people have with non-admin logons
(QuickBooks, for instance, can't run without at least Power User
permissions), many sysadmins give admin access to all their users.
Companies like Interland rent these web-enabled MS-SQL Server DBs
by the thousands. I've had several over the years and have never
lost anything (then again I've never had much there worth
stealing!). I've never heard of these being broken into, although
it's clear upon examining the other (not my) dbs on the server
that many of their owners are very lax about security. I've never
heard of any big intrusion. Maybe they happen. I'm tempted to ask
if someone can break into one of mine which I'm not using at
present, but maybe that's not such a smart idea.
You don't remember Slammer? Plenty of people thought they were safe,
and they weren't. The specific vulnerability there was the default
blank admin password, which has been changed in more recent versions
of SQL Server, but that doesn't mean there aren't plenty of other
types of vulnerabilties still undiscovered.
I've worked with MS-SQL servers in multi-million dollar
corporations. The security is ...well there isn't any. Generally
anyone using any db on any server has access to EVERYTHING if
he/she knows where to look. The logins are the Wndows logins so
when someone goes to lunch .... Of course, they pay their dbo's 60
grand a year ... maybe that's why.


It makes no sense whatsoever to expose a known application to the
wild and woolly Internet.

There should be only one port open for remote access, and that's
your VPN (or, I guess, SSH) port.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #31

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:2y****************@newssvr11.news.prodigy.com :
Of course most of those bulletins described exploits that could
happen only if you had no password on the default sa account (well
duh!).


Well, at one time, there were updates to SQL Server that would clear
the sa password, whether you had it set or not.

This was bad design by MS, but the upshot of it was that SQL Servers
that were locked down by their sysadmins would end up wide open,
without their knowledge.

It makes no sense to expose a database to the Internet, as it's not
a public function.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Jan 5 '06 #32

P: n/a
"Lyle Fairfield" <ly***********@aim.com> schreef in bericht news:11**********************@g47g2000cwa.googlegr oups.com...
David W. Fenton wrote:
Lyle, stick to topics you have experience with.

You're clearly completely ignorant of all aspects of Terminal Server
hosting of Access applications, so you really have nothing of use to
offer here.


Could you, please, list such topics so that I might know those with
which I should stick?

Or, perhaps I could e-mail you for approval before posting?


Well Lyle, since you *should* or at least *could* know that David is 'in charge' here on this topic ...
maybe emailing him before posting is not a bad idea at all.
But I am afraid he will never approve *your* remarks or questions ...

So I guess you just have to be humble, like mister BIG is ...

Arno R
Jan 5 '06 #33

P: n/a
Bri

David W. Fenton wrote:
Bri <no*@here.com> wrote in news:98dvf.138293$2k.84712@pd7tw1no:
TS only send the screen info down the line and this can be set to
send the bare minimum (min colours, no fancy see as you drag, etc)
so that the response is acceptable over a modem (56k or less
even). It doesn't take a lot of data moving to the FE to exceed
the screen data sent via TS.


On connections with more bandwidth than dialup, the responsiveness
is quite close to what a local desktop feels like.


Agreed. I use it via cable modem and the field via phone modem and TS
can be tailored to both environments.
Security of the data isn't really the issue. AFAIK, Both TS and a
remote connection to SQL Server can be secured to similar levels.
. . .


But if your back end is Jet, the difference is gigantic -- there is
no way to serve up Jet data to an Access front end to remote
locations, unless you've got huge pipes for your WAN.


Agreed. Lyle was referring to remotely connecting to SQL Server, so I
was continueing with that line.

One client, before being convinced to use TS, connected their remote
office WAN via a broadband microwave link. The users still complained
that the app was almost unusable (MDB BE at the time, currently SQL
Server). We hooked up a demo of TS using the built-in admin remote
desktop. They couldn't get that TS box ordered fast enough! :{)
. . . Integrity of
the data is more important. ... and the
line goes down, then they could lose or corrupt the current
process.


That's really only relevant for a non-client/server app, no? That
is, with Jet?


Certainly more relevant with a Jet BE. With SQL Server (or other
Client/server BEs I assume) there is still a window of time between the
request and delivery where the data could be lost if the line goes down.
The current process is potentially lost, but there isn't the same
corruption issues that you have with Jet. With TS, their session
continues to run, so when they reconnect its just like they had just
like they had never left it.
Oh, and 'simple terminal' could be replaced with 'those older
PCs/Laptops we can now keep around for a while longer'.


It means you don't have to worry about what they have on the other
end.

All other options for sharing data are much more complicated.


Agreed.
Oh, and I believe that you don't have to have Access installed to be
able to run Access on the TS. You just have to have cross-compatible
Office licenses. I definitely know that you don't have to have the
*same* version of Access installed. I don't have A2K3, but I can run
it on one of my clients' Terminal Servers.


The TS session runs completely on the server. The licencing of Office
for the workstation is purely a legal issue not a technology issue.

--
Bri
Jan 6 '06 #34

This discussion thread is closed

Replies have been disabled for this discussion.