Terminal services and VB.Net Solution?

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

I created an Access 2007 application for my customer. The application is
shared by three employees on a server. It maintains a contact list including
financial data and social security numbers. Only the office manager
generates reports in Access from this client data.

Now they want to share this Access application with employees at a remote
office. They expect to have a maximum of 30 employees editing the client
list in both the local and remote offices. So, I'm looking for a solution
that will allow for growth -- so that more users can securely edit their
contact list - both locally and remotely.

Do you think the following is a good solution?

1) Convert the Access front-end to .Net by programming it in Visual Basic
2008 Express. This front end will then create a connection to the client
list data as needed -- get the data or save changes -- then drop the
connection.

2) Convert the Access 2007 back-end to SQL Server 2008 Express by using the
Access upsize wizard.

3) Keep the reports in Access 2007. Connect the Access reports to the
client list data in SQL Server 2008 Express. Only the office manager needs
to generate reports. I understand that there are 10 connections available
in SQL Server 2008 Express. So, one seat could be sacrificed for generating
reports.

4) Hire a networking consultant to...
** Buy and set up a second server in their local office (with RAID for
mirroring)
** Install Windows Server 2008 on the new server
** Set up 20 terminal services seats for remote access on the new server.
** Install SQL Server 2008 Express on the new server
** Set up daily backups of the new server.
** Broadband internet connection should be at least 1 meg up or better at
local office where the new server will be located.

Does all of the above software operate smoothly together under .Net
Framework 3.5 ? If yes, is there any software that each terminal services
installation seat needs to drop on?

I will be very grateful to hear any recommendations.

[Andrew Morton]

Dweeberella wrote:

I created an Access 2007 application for my customer. The
application is shared by three employees on a server. It maintains a
contact list including financial data and social security numbers.
Only the office manager generates reports in Access from this client
data.

Now they want to share this Access application with employees at a
remote office. They expect to have a maximum of 30 employees editing
the client list in both the local and remote offices. So, I'm
looking for a solution that will allow for growth -- so that more
users can securely edit their contact list - both locally and
remotely.

Have you considered making it into an ASP.NET application instead? That way
you wouldn't need 20 terminal services seats, or even a new server, if you
have a web server running IIS somewhere already.

Andrew

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you for your input, Andrew. Actually, we were thinking of going with
ASP.Net. But I talked to the owner of a web host who was adamant that
hosting data online is a security risk. He said that hosting online should
only be used for data that you want to share with the world. The purpose of
this application is to maintain a list of social security numbers and other
client financial data. So, security is a big concern.

[Cor Ligthert[MVP]]

And you think your current situation is more save?

Probably that is why most banks, on line shops etc are not using it.

Just my thought reading your message

Cor

"Dweeberella" <Dw*********@discussions.microsoft.comwrote in message
news:D6**********************************@microsof t.com...

Thank you for your input, Andrew. Actually, we were thinking of going
with
ASP.Net. But I talked to the owner of a web host who was adamant that
hosting data online is a security risk. He said that hosting online
should
only be used for data that you want to share with the world. The purpose
of
this application is to maintain a list of social security numbers and
other
client financial data. So, security is a big concern.

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you for your response, Cor.

Do you mean that most banks use ASP.Net for remote access to a secure
network? Or do you mean that most banks use terminal services?

I'm trying to plan a secure situation as we expand users of our database and
make the application available to a remote office. So we don't have anything
up yet except a Microsoft Access database used only in one office on a server
-- no remote users yet -- and only 3 users but they want to plan for up to 30
users.

"Cor Ligthert[MVP]" wrote:

And you think your current situation is more save?
Probably that is why most banks, on line shops etc are not using it.
Just my thought reading your message
Cor

[Miro]

i do not want to put words in Cor's mouth but from what I understand:

I understood Cor's answer that when you do online banking, its a stype of
'programming' of ASP.net - not a winforms.

If banks are not worried about security for your banking information - and
thats banking information - you might be a bit 'over worried' about your
data.
Properly setup - your data would be safe online imho.

You can just as well maybe programing it ASP style, and let them run it
through terminal service or perhaps even a vpn, and when the time comes -
just pop it over on the net once they are more comfortable.

Miro

"Dweeberella" <Dw*********@discussions.microsoft.comwrote in message
news:EA**********************************@microsof t.com...

Thank you for your response, Cor.

Do you mean that most banks use ASP.Net for remote access to a secure
network? Or do you mean that most banks use terminal services?

I'm trying to plan a secure situation as we expand users of our database
and
make the application available to a remote office. So we don't have
anything
up yet except a Microsoft Access database used only in one office on a
server
-- no remote users yet -- and only 3 users but they want to plan for up to
30
users.

"Cor Ligthert[MVP]" wrote:

>And you think your current situation is more save?
Probably that is why most banks, on line shops etc are not using it.
Just my thought reading your message
Cor

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you to all those that responded to my inquiry. You have influenced me
to propose using ASP.net.

I talked to a networking consultant who proposed forcing remote users to
connect up via VPN before allowing them access to our internal website and
ASP.Net application. Then the ASP.net application will not be exposed
directly to the internet. We will use password authentication and encryption
for the internal website. We will use an SSL certificate for that.

There will be multiple levels of security...
1) Remote users first need to login via VPN to the local server.
2)Then, remote users need to startup the correct internal URL to get my
ASP.Net app started.
3)Then, remote users need to enter the correct login and password to
actually get into my app.

ASP.net puts less of a drain on the server than Access does. So, there
should be no need to get a second server.

I'll keep the reporting functions in Access -- since there is only one user
for the reports. So, the Access reports will only take up one of the 10
concurrent connections offered in SQL Server 2008 Express.

How does this solution sound?

[Mr. Arnold]

"Dweeberella" <Dw*********@discussions.microsoft.comwrote in message
news:52**********************************@microsof t.com...

Thank you to all those that responded to my inquiry. You have influenced
me
to propose using ASP.net.

I talked to a networking consultant who proposed forcing remote users to
connect up via VPN before allowing them access to our internal website and
ASP.Net application. Then the ASP.net application will not be exposed
directly to the internet. We will use password authentication and
encryption
for the internal website. We will use an SSL certificate for that.

There will be multiple levels of security...
1) Remote users first need to login via VPN to the local server.
2)Then, remote users need to startup the correct internal URL to get my
ASP.Net app started.
3)Then, remote users need to enter the correct login and password to
actually get into my app.

ASP.net puts less of a drain on the server than Access does. So, there
should be no need to get a second server.

I'll keep the reporting functions in Access -- since there is only one
user
for the reports. So, the Access reports will only take up one of the 10
concurrent connections offered in SQL Server 2008 Express.

How does this solution sound?

Myself, I would use IIS, Windows Communication Foundation Web service on IIS
with the security protocols that WCF uses, SQL Server on the back-end and
using a Windows Desktop VB.net client solution.

The Windows Desktop solution would be deployed to a terminal server such as
Citrix Terminal server using the Cirtix VPN Web browser client session on
the client side in communications with the Citrix terminal server that would
allow multiple user sessions to run the Windows Desktop solution, as if they
were at their desktop running the solution.

1) User has to login to the Citrix terminal server using NT authentication.
2) The client application would be using a possible role based security for
each user that would be using SQL Server to hold user credentials.
3) The user would be in a Citrix VPN terminal session using a Citrix Web
browser VPN client side software at the their workstation.

It's bank. Doesn't the bank have MS SQL Server a server on the network.

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you Mr. Arnold for your proposed security solution.

My network consultant proposed activating VPN which he says is already
available in Windows server. Why is Citrix VPN better than that?

You propose using VB.Net rather than ASP.Net. For VB.Net, we don't need
IIS activated, right? It sounds to me like a more secure solution is to keep
IIS deactivated and use VB.Net rather than ASP.Net. What do you think?

How does SSL fit in with this? We don't need an SSL certificate if we use
VB.Net rather than ASP.Net, right?

[Mr. Arnold]

"Dweeberella" <Dw*********@discussions.microsoft.comwrote in message
news:13**********************************@microsof t.com...

Thank you Mr. Arnold for your proposed security solution.

My network consultant proposed activating VPN which he says is already
available in Windows server. Why is Citrix VPN better than that?

<http://74.125.45.104/search?q=cache:1DFCgafThkwJ:www.seceidos.de/fileadmin/media/documents/Citrix_Access_Gateway_7-0_Enterprise_Edition_-_Technical_Presentation__englisch_.ppt+citrix+vpn+ session+with+browser&hl=en&ct=clnk&cd=4&gl=us>

The client on the other end is using a *browser session* to login into the
Citrix Terminal server with a VPN connection and using NT authentication to
login to the NT based O/S server running Citrix Terminal server. I would
assume that the NT server O/S machine running Citrix Terminal server would
be on a local NT domain.

That means the user uses a Citrix browser VPN client session to login to the
Citrix terminal server desktop to run your Windows Desktop solution, with
your desktop solution using a user-id and psw to log into your Windows
desktop solution using .Net role-based security to authentication the user
logging into the desktop solution, after he or she logged into the Citrix
Terminal server.

>
You propose using VB.Net rather than ASP.Net. For VB.Net, we don't need
IIS activated, right? It sounds to me like a more secure solution is to
keep
IIS deactivated and use VB.Net rather than ASP.Net. What do you think?

ASP.NET Active Server Pages is using IIS and VB.Net or C#.Net as the Code
Behind file solution language.

With a VB.NET Windows Desktop solution running on a terminal server such as
Citrix or other VPN solution is a more secure solution for your internal
company solution that must be run by other users outside of your local NT
domain, and your desktop solution doesn't need IIS.

>
How does SSL fit in with this? We don't need an SSL certificate if we
use
VB.Net rather than ASP.Net, right?

With Citrix software, one can be in a SSL session with a client Web browser
and the Citrix terminal server.

The thing you should recognize is that the user is using a browser session
to access the Citrix Terminal server and running the solution on the Citrix
Terminal server desktop as if the user was running it from his workstation
desktop, with the connection between the Citrix Terminal server and the
user's Citrix terminal client session being in a secure connection.

I am just giving you more options. However, I have seen Citrix being used
internally across multiple company NT domains, and by users in remote
locations using dial-up, BB, and DSL within the same company infrastructure
to access a solution on a global wide bases used by internal company users.
It just happened that the solution was running on 20 Citrix terminal servers
in a Citrix terminal server farm. You may not get to that capacity. :)

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you, Mr. Arnold.

I talked to a network consultant yesterday. He recommended that we use the
VPN functionality that comes with Windows server to have the remote office
connect up with the local office. He said that my client should install
firewall hardware at the local office and also at the remote office -- a
firewall like Cisco or SonicWall.

He said there is no additional VPN licensing required for each remote user
with this solution -- if I understood him correctly. He said that if we go
with Citrix VPN that there would be expensive licensing issues. He said we
didn't need Citrix because Windows server comes with its own VPN
functionality.

I have been getting different answers about the VPN security part of this
from different networking consultants. So, I just proposed to the client
that they set up VPN. Their IT guy who set up their server can figure out
how to get it done. But, I think I understand that we will not need
terminal services -- just VPN. We are going to need to host up to 30 users
of the application. And, possibly more later.

I proposed that I migrate their application from Access to VB.Net with SQL
Server 2008 Express back end. With a VB.Net rather than an ASP.Net
solution, we won't need to activate IIS. I proposed keeping their reports
in Access linking to data in SQL Server 2008 Express. They only need to
have one person run reports at a time -- so that only takes up one of the 10
connections available in SQL Server 2008 Express.

So, I hope that we're set...

One networking consultant recommended that we install RAID -- for mirroring
the activity on one hard drive to a second hard drive on the existing server.
And, he suggested setting up a regular backup of the server. So, I might
ask if the client wants to do that.

[Mr. Arnold]

"Dweeberella" <Dw*********@discussions.microsoft.comwrote in message
news:74**********************************@microsof t.com...

Thank you, Mr. Arnold.

I talked to a network consultant yesterday. He recommended that we use
the
VPN functionality that comes with Windows server to have the remote office
connect up with the local office. He said that my client should install
firewall hardware at the local office and also at the remote office -- a
firewall like Cisco or SonicWall.

Those solutions have a VPN licensing issue, like a 10 user VPN license,
which one can buy more licenses if need be.

Then there are router/hardware solutions that are dedicated to VPN.

>
He said there is no additional VPN licensing required for each remote user
with this solution -- if I understood him correctly. He said that if we
go
with Citrix VPN that there would be expensive licensing issues. He said
we
didn't need Citrix because Windows server comes with its own VPN
functionality.

It's at the computer/machine level. And all machines connecting to that
server would have to negotiate and use the VPN protocol as opposed to a
hardware VPN solution like router to router where the client machines don't
need to negotiate the VPN protocol.

>
I have been getting different answers about the VPN security part of this
from different networking consultants. So, I just proposed to the client
that they set up VPN. Their IT guy who set up their server can figure out
how to get it done. But, I think I understand that we will not need
terminal services -- just VPN. We are going to need to host up to 30
users
of the application. And, possibly more later.

What are you going to do then install the VB.NET solution you mention below
on each user's workstation?

>
I proposed that I migrate their application from Access to VB.Net with SQL
Server 2008 Express back end. With a VB.Net rather than an ASP.Net
solution, we won't need to activate IIS.

No you don't need IIS if you're using a VB.Net Windows desktop solution. But
it comes down to where is the Windows desktop solution going to be
installed/hosted.

Is it going to be installed/hosted on each possible non-secure user
workstation and they run it from their workstation?

Is the solution going to be installed/hosted on a terminal server such as
Windows terminal server or otherwise and the user uses termainal server
software Windows or otherwise to run the solution on a terminal server
session with remote sessions?

I proposed keeping their reports
in Access linking to data in SQL Server 2008 Express. They only need to
have one person run reports at a time -- so that only takes up one of the
10
connections available in SQL Server 2008 Express.

You got 20 possible users with a possibility of more users using the
solution. Someone is not going to be allowed to connect, and your
application is going to blow if you don't handle it properly, which could
lead to your users thinking that the solution was not developed properly.

Maybe, you need to deal with the SQL Server issues now and come away from
SQL Server Express.

>
So, I hope that we're set...

One networking consultant recommended that we install RAID -- for
mirroring
the activity on one hard drive to a second hard drive on the existing
server.
And, he suggested setting up a regular backup of the server. So, I
might
ask if the client wants to do that.

The client would be a fool not to want a failover solution implemented.

[Andrew Morton]

Dweeberella wrote:

I talked to a network consultant yesterday. He recommended that we
use the VPN functionality that comes with Windows server to have the
remote office connect up with the local office. He said that my
client should install firewall hardware at the local office and also
at the remote office -- a firewall like Cisco or SonicWall.

Is the "client" actually part of your company, such that you could set up an
intranet over VPN? Or is the customer someone separate from your company,
but with a branch office that they want to connect with?

Assuming the customer can set up an intranet over VPN, then you would make
the functionality available using ASP.NET, thus making no installation
necessary at the remote site, and with no external access possible (assuming
you set up IIS to accept connections for that web site from a particular
range of IP addresses only, and you don't expose IIS to the Internet).

All the remote site would need would be a VPN and browsers. No need for a
terminal server. No need for CALs for SQL Server.

All access to the Internet should, of course, be through a firewall
appliance of some sort, under any circumstances. Some firewall appliances
also do VPN, e.g. Watchguard.

Andrew

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

>Those solutions have a VPN licensing issue, like a 10 user VPN license,
which one can buy more licenses if need be.

So, Windows Server does have VPN licensing costs.

>Then there are router/hardware solutions that are dedicated to VPN.

Are there any additional VPN licensing costs if we go with a hardware VPN
solution like a Cisco or SonicWall firewall at the local and remote
locations?
If we use a hardware VPN connection then we would avoid the Windows Server
VPN licensing costs?
Is the hardware VPN solution a more secure solution than the Windows Server
VPN solution?

>No you don't need IIS if you're using a VB.Net Windows desktop solution. But it comes down to where is the Windows desktop solution going to be installed/hosted.

It sounds like ASP.Net with IIS is the best solution. That way we can avoid
having to pay for terminal services licensing. And, it sounds like it will
be a simpler solution to deploy because there will be no need to distribute
the front end.

>Maybe, you need to deal with the SQL Server issues now and come away from SQL Server Express.

Only 1 of the 10 connections would be monopolized by the Access reports.
They don't run reports very often so even that connection wouldn't be in use
very often.

I'm planning to do the .net programming so that I create a connection to the
back end, bring over the data, then drop the connection. So, there should be
split second use of each of the remaining connections and it will be very
rare that more than one or two of those connections would be used at the same
time even if we had 30 or more users of the .Net front end.

>The client would be a fool not to want a failover solution implemented.

So, it sounds like RAID is a very, very good idea.

Thank you, Mr. Arnold.

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you, Andrew

>Is the "client" actually part of your company, such that you could set up an

intranet over VPN? Or is the customer someone separate from your company,
but with a branch office that they want to connect with?

My customer could set up an intranet if they chose to do so. I am a
consulting programmer for this customer. They want to connect up an office
locally with a remote office. How does setting up an intranet differ from
setting up VPN?

>Assuming the customer can set up an intranet over VPN, then you would make

the functionality available using ASP.NET, thus making no installation
necessary at the remote site, and with no external access possible (assuming
you set up IIS to accept connections for that web site from a particular
range of IP addresses only, and you don't expose IIS to the Internet).

Thank you for this security input, Andrew. We will ensure that the remote
office has a static IP address and only allow that specific IP address to VPN
into the local office. We will ensure that IIS is not exposed to the
Internet.

>All the remote site would need would be a VPN and browsers. No need for a

terminal server. No need for CALs for SQL Server. All access to the
Internet should, of course, be through a firewall appliance of some sort,
under any circumstances. Some firewall appliances
also do VPN, e.g. Watchguard.

Do you think Watchguard is better than Cisco and SonicWall?
These are all hardware firewalls and also all do VPN?
We won't need to use Windows Server VPN if we use a VPN hardware solution?
No VPN licensing required for each remote user with a hardware VPN/firewall?

[Mr. Arnold]

"Dweeberella" <Dw*********@discussions.microsoft.comwrote in message
news:60**********************************@microsof t.com...

Those solutions have a VPN licensing issue, like a 10 user VPN license,

which one can buy more licenses if need be.

So, Windows Server does have VPN licensing costs.

No Windows server using VPN would not be a licensing costs, as it's already
part of the server O/S.

>

>>Then there are router/hardware solutions that are dedicated to VPN.

Are there any additional VPN licensing costs if we go with a hardware VPN
solution like a Cisco or SonicWall firewall at the local and remote
locations?

Yes there would be additional costs. Firewall solutions are firewall
solutions and VPN in a firewall solution would be an additional costs.

If we use a hardware VPN connection then we would avoid the Windows Server
VPN licensing costs?

If you use a hardware solution, the Windows server would not need a VPN
solution period.

In its simplest form.

http://www.homenethelp.com/vpn/

Is the hardware VPN solution a more secure solution than the Windows
Server
VPN solution?

Anything that is standalone and doesn't need the Windows O/S to host it is
more secure.

>

>>No you don't need IIS if you're using a VB.Net Windows desktop solution.
But it comes down to where is the Windows desktop solution going to be
installed/hosted.

It sounds like ASP.Net with IIS is the best solution. That way we can
avoid
having to pay for terminal services licensing. And, it sounds like it
will
be a simpler solution to deploy because there will be no need to
distribute
the front end.

ASP.NET is going to use C#.Net or VB.net with a *Code Behind File* using
ADO.NET to access SQL Server.

[=?Utf-8?B?RHdlZWJlcmVsbGE=?=]

Thank you, Mr. Arnold.

I especially appreciated the info on http://www.homenethelp.com/vpn/