Halbertech,
Here's my take, my friend.
Number one, is that I would never move a client off of SBS to Standard
server. Instead, take the route of the Transition Pack licenses. Once
you reach 75 connections (CALs) (max for SBS), then you buy these, and
it gives you license to turn your SBS in to a full-blown Std server
(while keeping the cool stuff like RWW, network fax, etc). This also
allows you to seperate Exchange onto a seperate server (because it also
gives you license for Exchange Std). So, if it's not too late, I would
go that route. It's okay to buy a member server Win2K3 or Win2K if you
need a 2nd server on your network. So you can have pretty sophisticated
and large SBS networks.
If you have already thrown the SBS out of the picture (unless you can
resurrect it), then here are your best options:
1.) VPN!! - I think this is the best answer for what you want to do.
It's the closest in simplicity to RWW. Setup your server to provide
pptp VPN access (in RRAS). Then help each of your people create the VPN
dial-up connection on their home computers. From there, all they have
to do is connect to the VPN, run Remote Desktop Connection, type in
their computer name (the name of the computer which is on business
network they are wanting to access), and click connect.
OR
To make things simpler, just save the settings as .rdp files, so that
they just double click on the icon for the RDP file to connect to their
computer at work. (You could create these RDP files just as easily from
any computer and email them to your people [distribute via disks,
whatever..] [as long as you know their computer names] ).
OR
If you want to make it even simpler for them, you could help them
create the VPN dial-up connection, put the RDP file on the computer,
then make a batch file which uses RASDIAL and MSTSC. These are both
pretty versatile from the command line. Then all they ever have to do
is click on an icon you make for them called "Remote Web Workplace" (ha
ha), and it will automatically connect to the VPN, and their computer
via RDC. Once that they log off of their RDP session to their work
computer, the batch file can then close the VPN connection (it runs in
the background waiting, the whole time that they're connected to the
VPN). Pretty slick, but requires a bit more overhead. I have a setup
almost identical to this w/ about 50 remote users.
A couple of notes about this:
a. Connecting typing the computer name will only work if:
i. Your network at the office is in a domain enviornment,
using your DC as DNS.
ii. The VPN dial-up connections use that same DNS server over
the VPN (they will by default.
b. This creates double encryption (VPN tunnel & RDP session inside
VPN tunnel).
i. Requires more processor overhead (encrypt & decrypt twice
on client computer, once on server, once on computer on office LAN).
More processing will always introduce more delay, but in reality, your
users (or even us as administrators) won't really notice.
ii. Decreases available bandwidth. You have to allow for more
packet header overhead, when your packet looks like:
Frame - IP - TCP - PPTP - RDP - Data
as opposed to what you would get w/o the VPN
Frame - IP - TCP - RDP - Data
I can't tell you off the top of my head what the impact
would be, but again, I don't think it would be significant enough to
matter if you have a T1 (or 1.5Mbps DSL) (it doesn't w/ our 50 users).
Now to the next option:
2.) Terminal Server - Get a 2nd server to act at a TS for all remote
access. Simplifies things even more, in some ways, however requires
hardware & server 2000 or 2K3 License, plus TS CALs if you are using
Win2K3 TS. (My friend, I really would have stuck w/ SBS, and added a
member server [you don't even have to buy CALs for a member server in
an SBS enviornment]). Anyway, just load your apps onto the TS, and
you're pretty much good to go (after allowing users, etc).
3.) Custom port fowards on your router. I wouldn't bother changing the
ports on each client computer (via the registry). Just do it at the
router. Of course, internal computers must have static IP's w/ this
option, whereas with option 1 they don't because they are being
resolved by the DNS on your DC.
The nice thing about option 2 & 3, is that you should get a bit more
robustness, since you are making more available bandwidth, and
requiring less processing (delay).
However, if this is majorly sensitive data, and you have an enemy
computer hacker, then you would still want to go w/ the VPN. This is
because there is currently still a vulnerability w/ TS, where
specialized programs can be used to view all data traveling to and from
the TS session. One program in particular is called Cain & Abel. As far
as I know, they can't interact w/ a session, but if they can see your
password keystrokes sent to the server, then you're in trouble.
I would say that tons of TS's don't use VPN, because the odd's are very
good that somebody is going to do this. It's not well known either (but
I guess I'm helping that out here ;-)).
Anyway, I hope that this info helps. Feel free to reply w/ more
questions if needed. Best to reply to the news group, so that everybody
can benifit from the discussion. (I know googling newsgoups can really
save my day sometimes!!).
See ya later,
Doug Mortensen
Network Consultant
CCNA, MCP, A+, MS Small Business Specialist
Similar Threads
Linear Mode
