Logon/rename via VPN

This is an SBS2003 single-server domain.

I have a problem with a remote workstation. I added it to the domain when in
the office, then moved it to its remote site. It is connected now via a
hardware VPN box at each end. It has a static IP with DNS pointing to the LAN
IP of the server. I can successfully ping the server (at about 100ms
turnaround time per packet) and any other workstations on the office LAN via
DNS, but I have two problems:

1. Logon is generally extremely slow when logging onto the domain (but fast
when logging onto a local account) and, in fact, is entirely failing this
morning, so the user cannot log onto the domain.
2. I tried to rename the computer (standard method - local logon to the
workstation, then rename, then authenticate to AD when requested), but I get
the "error attempting to rename the computer. The user name could not be
found" error after a couple of minutes.

Any errors if using nslookup command? Or this link may help,

Windows slow issuesSlow logon to windows domain Possible solutions: 1) check DNS settings. 2) It is better to use its using the same DNS as the server i.e. local DNS not ...
http://www.chicagotech.net/winslow.htm


Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com
"Brian" <(E-Mail Removed)> wrote in message news:8FD93FBE-B8D6-4C94-B549-(E-Mail Removed)...
This is an SBS2003 single-server domain.

I have a problem with a remote workstation. I added it to the domain when in
the office, then moved it to its remote site. It is connected now via a
hardware VPN box at each end. It has a static IP with DNS pointing to the LAN
IP of the server. I can successfully ping the server (at about 100ms
turnaround time per packet) and any other workstations on the office LAN via
DNS, but I have two problems:

1. Logon is generally extremely slow when logging onto the domain (but fast
when logging onto a local account) and, in fact, is entirely failing this
morning, so the user cannot log onto the domain.
2. I tried to rename the computer (standard method - local logon to the
workstation, then rename, then authenticate to AD when requested), but I get
the "error attempting to rename the computer. The user name could not be
found" error after a couple of minutes.

Brian <(E-Mail Removed)> wrote:
> This is an SBS2003 single-server domain.
>
> I have a problem with a remote workstation. I added it to the domain
> when in the office, then moved it to its remote site. It is connected
> now via a hardware VPN box at each end. It has a static IP with DNS
> pointing to the LAN IP of the server. I can successfully ping the
> server (at about 100ms turnaround time per packet) and any other
> workstations on the office LAN via DNS, but I have two problems:
>
> 1. Logon is generally extremely slow when logging onto the domain
> (but fast when logging onto a local account) and, in fact, is
> entirely failing this morning, so the user cannot log onto the domain.

I don't know how many users/computers you have in this remote location, but
generally speaking, unless you have a huge fat leased line connecting the
two offices (no DSL, no VPN) this isn't going to work well.

it would be a good idea to stick a local DC/DNS/GC box on this network if
you want the users in this location to log into the domain at all. You can
use a cheapo workstation box running Win2k3 server for this purpose.

If you aren't going to have that in place, don't have these workstations
belong to your domain at all. You could install a Terminal Services box in
your main office, and have them access everything on the network that way.
In fact, even if you do install a local DC, note that accessing files across
a VPN connection just plain stinks, most of the time.

> 2. I tried to rename the computer (standard method - local logon to
> the workstation, then rename, then authenticate to AD when
> requested), but I get the "error attempting to rename the computer.
> The user name could not be found" error after a couple of minutes.

Don't try that unless your computer has a good, reliable connection to a DC
at the time.

No nslookup problems. It is perfectly functional & pretty fast.

DNS points to the SBS2003 server. I can ping any computer at the host office
by its DNS name and get a reply. Internet access is fast, so DNS responses
from the server are just fine.

The only place there is an issue is at logon. To rename the PC, I
evenentually removed it from the domain at the server, then at the
workstation, and re-added it. It took perhaps 5 minutes to get a response
from the server on the last item.

"Robert L [MVP - Networking]" wrote:

> Any errors if using nslookup command? Or this link may help,
>
> Windows slow issuesSlow logon to windows domain Possible solutions: 1) check DNS settings. 2) It is better to use its using the same DNS as the server i.e. local DNS not ...
> http://www.chicagotech.net/winslow.htm
>
>
> Bob Lin, MS-MVP, MCSE & CNE
> Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
> How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com
> "Brian" <(E-Mail Removed)> wrote in message news:8FD93FBE-B8D6-4C94-B549-(E-Mail Removed)...
> This is an SBS2003 single-server domain.
>
> I have a problem with a remote workstation. I added it to the domain when in
> the office, then moved it to its remote site. It is connected now via a
> hardware VPN box at each end. It has a static IP with DNS pointing to the LAN
> IP of the server. I can successfully ping the server (at about 100ms
> turnaround time per packet) and any other workstations on the office LAN via
> DNS, but I have two problems:
>
> 1. Logon is generally extremely slow when logging onto the domain (but fast
> when logging onto a local account) and, in fact, is entirely failing this
> morning, so the user cannot log onto the domain.
> 2. I tried to rename the computer (standard method - local logon to the
> workstation, then rename, then authenticate to AD when requested), but I get
> the "error attempting to rename the computer. The user name could not be
> found" error after a couple of minutes

1. I have only one user on the remote LAN because she works from her home.
Defnitely not worth setting up another server.

2.I know my method works, because I have another client who has a T-1 at
their host site (35 LAN stations) with two remote sites on < 1Mb DSL's and 4
remote LAN stations each. The remote users are able to work without a
problem, other than the obvious delay opening files from the shared folders
on the DC. The difference in my current case may be that the host site has a
DSL that averages about 600k (the remote site has a cable connection at 6
Mb/768k).

3. I need a VPN for two reasons

a. The remote user needs to print to her house from the host LAN (using
MAS90, a ProvideX-based accounting package), hosted on the DC, to a
multi-function laser printer at the remote office (her house). As I am sure
you are aware, support for many multi-function printers is very shaky or
nonexistent via RDP, so I elected to have the TS print directly to her
IP-based networked printer. This works just fine with no delays.
b. The user needs remote access to both Outlook & shared files hosted on the
server. I know I can leave off the domain membership & just write a batch
file for the user to map the drives (instead of using the AD login script),
but I'm not sure that would be much different.

4. She does run MAS90 via a terminal server at the host site, but I don't
really want to get into trying to license Word & Excel for the terminal
server, and she needs realtime access to those types of files in her home
folder & shared folders on the server.

The bottom line? Everything works fine except the logon process. Internet
access using the DC as her DNS server is perfectly fast; file access from the
DC is slow but adequate. The logon process, though, takes a good five
minutes. At the moment, my first step may just be to get the host site
upgraded to a cable connection at over 1Mb.

Someone told me there is a way to have "authentication lite" for remote
stations to speed up the logon process, but I have been unable to find
anything on this.

"Lanwench [MVP - Exchange]" wrote:

> Brian <(E-Mail Removed)> wrote:
> > This is an SBS2003 single-server domain.
> >
> > I have a problem with a remote workstation. I added it to the domain
> > when in the office, then moved it to its remote site. It is connected
> > now via a hardware VPN box at each end. It has a static IP with DNS
> > pointing to the LAN IP of the server. I can successfully ping the
> > server (at about 100ms turnaround time per packet) and any other
> > workstations on the office LAN via DNS, but I have two problems:
> >
> > 1. Logon is generally extremely slow when logging onto the domain
> > (but fast when logging onto a local account) and, in fact, is
> > entirely failing this morning, so the user cannot log onto the domain.
>
> I don't know how many users/computers you have in this remote location, but
> generally speaking, unless you have a huge fat leased line connecting the
> two offices (no DSL, no VPN) this isn't going to work well.
>
> it would be a good idea to stick a local DC/DNS/GC box on this network if
> you want the users in this location to log into the domain at all. You can
> use a cheapo workstation box running Win2k3 server for this purpose.
>
> If you aren't going to have that in place, don't have these workstations
> belong to your domain at all. You could install a Terminal Services box in
> your main office, and have them access everything on the network that way.
> In fact, even if you do install a local DC, note that accessing files across
> a VPN connection just plain stinks, most of the time.
>
> > 2. I tried to rename the computer (standard method - local logon to
> > the workstation, then rename, then authenticate to AD when
> > requested), but I get the "error attempting to rename the computer.
> > The user name could not be found" error after a couple of minutes.
>
> Don't try that unless your computer has a good, reliable connection to a DC
> at the time.
>
>
>
>

Followup: is there a way to log the authentication/negotiation process
verbosely with time stamps so that I can determine exacly where things are
stalling?

"Lanwench [MVP - Exchange]" wrote:

> Brian <(E-Mail Removed)> wrote:
> > This is an SBS2003 single-server domain.
> >
> > I have a problem with a remote workstation. I added it to the domain
> > when in the office, then moved it to its remote site. It is connected
> > now via a hardware VPN box at each end. It has a static IP with DNS
> > pointing to the LAN IP of the server. I can successfully ping the
> > server (at about 100ms turnaround time per packet) and any other
> > workstations on the office LAN via DNS, but I have two problems:
> >
> > 1. Logon is generally extremely slow when logging onto the domain
> > (but fast when logging onto a local account) and, in fact, is
> > entirely failing this morning, so the user cannot log onto the domain.
>
> I don't know how many users/computers you have in this remote location, but
> generally speaking, unless you have a huge fat leased line connecting the
> two offices (no DSL, no VPN) this isn't going to work well.
>
> it would be a good idea to stick a local DC/DNS/GC box on this network if
> you want the users in this location to log into the domain at all. You can
> use a cheapo workstation box running Win2k3 server for this purpose.
>
> If you aren't going to have that in place, don't have these workstations
> belong to your domain at all. You could install a Terminal Services box in
> your main office, and have them access everything on the network that way.
> In fact, even if you do install a local DC, note that accessing files across
> a VPN connection just plain stinks, most of the time.
>
> > 2. I tried to rename the computer (standard method - local logon to
> > the workstation, then rename, then authenticate to AD when
> > requested), but I get the "error attempting to rename the computer.
> > The user name could not be found" error after a couple of minutes.
>
> Don't try that unless your computer has a good, reliable connection to a DC
> at the time.
>
>
>
>

Brian <(E-Mail Removed)> wrote:
> 1. I have only one user on the remote LAN because she works from her
> home. Defnitely not worth setting up another server.

Yeah, I guess I can seethat.
>
> 2.I know my method works, because I have another client who has a T-1
> at their host site (35 LAN stations) with two remote sites on < 1Mb
> DSL's and 4 remote LAN stations each. The remote users are able to
> work without a problem, other than the obvious delay opening files
> from the shared folders on the DC. The difference in my current case
> may be that the host site has a DSL that averages about 600k (the
> remote site has a cable connection at 6 Mb/768k).

ADSL, I'm presuming. This will never be pretty.
>
> 3. I need a VPN for two reasons
>
> a. The remote user needs to print to her house from the host LAN
> (using MAS90, a ProvideX-based accounting package), hosted on the DC,
> to a multi-function laser printer at the remote office (her house).
> As I am sure you are aware, support for many multi-function printers
> is very shaky or nonexistent via RDP,

Yep....which is why I strongly discourage them. However, you can often find
a comparable DeskJet driver for any HP inkjet multifunction, and so on.

> so I elected to have the TS
> print directly to her IP-based networked printer. This works just
> fine with no delays.

Well, yes, but you shouldn't need a VPN for that. Printer redirection to a
network printer isn't a problem per se....

> b. The user needs remote access to both Outlook

.....RPC over HTTP will be useful there

> & shared files hosted
> on the server.

This won't be pretty, as mentioned....

> I know I can leave off the domain membership & just
> write a batch file for the user to map the drives (instead of using
> the AD login script), but I'm not sure that would be much different.

Yes, it will make a big difference.
>
> 4. She does run MAS90 via a terminal server at the host site, but I
> don't really want to get into trying to license Word & Excel for the
> terminal server,

Understood, but if you want good performance for any sort of file access,
I'd think this was the most logical path.

and she needs realtime access to those types of
> files in her home folder & shared folders on the server.

Realtime meaning ?
>
> The bottom line? Everything works fine except the logon process.

Whichis understandable.

> Internet access using the DC as her DNS server is perfectly fast;
> file access from the DC is slow but adequate. The logon process,
> though, takes a good five minutes. At the moment, my first step may
> just be to get the host site upgraded to a cable connection at over
> 1Mb.

That might help, but I'd still be skeptical.
>
> Someone told me there is a way to have "authentication lite" for
> remote stations to speed up the logon process, but I have been unable
> to find anything on this.

Not sure what they referred to. There are various things you can tweak via
group policy, but I'm not sure what you'll be able to do with this.
>

<snipped for length>

Thanks. See notes inline. It may be that increasing the bandwidth will
rectify the situation, but I can't know for sure until I try it.

"Lanwench [MVP - Exchange]" wrote:

> Brian <(E-Mail Removed)> wrote:
> > 1. I have only one user on the remote LAN because she works from her
> > home. Defnitely not worth setting up another server.
>
> Yeah, I guess I can seethat.
> >
> > 2.I know my method works, because I have another client who has a T-1
> > at their host site (35 LAN stations) with two remote sites on < 1Mb
> > DSL's and 4 remote LAN stations each. The remote users are able to
> > work without a problem, other than the obvious delay opening files
> > from the shared folders on the DC. The difference in my current case
> > may be that the host site has a DSL that averages about 600k (the
> > remote site has a cable connection at 6 Mb/768k).
>
> ADSL, I'm presuming. This will never be pretty.

Yes. Cheap DSL from the phone company. I wouldn't be so persistent at this
if it were not for the fact that I have several similar configurations
working without any problem for other clients, most notably the client that
has 2 remote LANs connected via VPN, 4 concurrent stations each. Logon takes
perhaps 60 seconds, and the only performance issue is access to shared
folders at the host site. The remote sites are about the same as this one;
the only difference is the T-1 at the host site, and that may well be my
bottleneck.

> >
> > 3. I need a VPN for two reasons
> >
> > a. The remote user needs to print to her house from the host LAN
> > (using MAS90, a ProvideX-based accounting package), hosted on the DC,
> > to a multi-function laser printer at the remote office (her house).
> > As I am sure you are aware, support for many multi-function printers
> > is very shaky or nonexistent via RDP,
>
> Yep....which is why I strongly discourage them. However, you can often find
> a comparable DeskJet driver for any HP inkjet multifunction, and so on.

I got tired of beating my head against the wall on all-in-one devices some
time back and gave up, always recommending instead plain laser printers
except in cases like this where an entire remote office needs to operate with
the space contraints of a home office.

>
> > so I elected to have the TS
> > print directly to her IP-based networked printer. This works just
> > fine with no delays.
>
> Well, yes, but you shouldn't need a VPN for that. Printer redirection to a
> network printer isn't a problem per se....

I plead ignorance here: I don't understand how to redirect a printer to a
remote LAN without the VPN. Or are you talking about just opening the client
printer connection through RDP? I thought that worked only to printers
connected locally to the client. Besides, there are times when other users on
the TS need to print to the remote office, and it's a pain for them to have
to ensure that the remote user is online so the printer is available.

> > b. The user needs remote access to both Outlook
>
> .....RPC over HTTP will be useful there

I've looked at that a little, and the initial setup docs start talking about
multiple servers. How workable (and difficult to configure) is it on a single
SBS2003 server?

> > & shared files hosted
> > on the server.
>
> This won't be pretty, as mentioned....
>
> > I know I can leave off the domain membership & just
> > write a batch file for the user to map the drives (instead of using
> > the AD login script), but I'm not sure that would be much different.
>
> Yes, it will make a big difference.

I understand it makes a huge difference with logon, but I don't think it
will make much difference with file access, since access is stilll remote.

> > 4. She does run MAS90 via a terminal server at the host site, but I
> > don't really want to get into trying to license Word & Excel for the
> > terminal server,
>
> Understood, but if you want good performance for any sort of file access,
> I'd think this was the most logical path.

Agreed, but that becomes a budget issue for fairly small businesses like
this one.

> and she needs realtime access to those types of
> > files in her home folder & shared folders on the server.
>
> Realtime meaning ?

Forget about the time. How about just "real". The organization has files
that need to be shared amongst users, including this remote user, and they
are stored on the DC for backup purposes.

> >
> > The bottom line? Everything works fine except the logon process.
>
> Whichis understandable.
>
> > Internet access using the DC as her DNS server is perfectly fast;
> > file access from the DC is slow but adequate. The logon process,
> > though, takes a good five minutes. At the moment, my first step may
> > just be to get the host site upgraded to a cable connection at over
> > 1Mb.
>
> That might help, but I'd still be skeptical.
> >
> > Someone told me there is a way to have "authentication lite" for
> > remote stations to speed up the logon process, but I have been unable
> > to find anything on this.
>
> Not sure what they referred to. There are various things you can tweak via
> group policy, but I'm not sure what you'll be able to do with this.
> >
>
> <snipped for length>
>
>
>

Brian <(E-Mail Removed)> wrote:
> Thanks. See notes inline. It may be that increasing the bandwidth will
> rectify the situation, but I can't know for sure until I try it.
>
> "Lanwench [MVP - Exchange]" wrote:
>
>> Brian <(E-Mail Removed)> wrote:
>>> 1. I have only one user on the remote LAN because she works from her
>>> home. Defnitely not worth setting up another server.
>>
>> Yeah, I guess I can seethat.
>>>
>>> 2.I know my method works, because I have another client who has a
>>> T-1 at their host site (35 LAN stations) with two remote sites on <
>>> 1Mb DSL's and 4 remote LAN stations each. The remote users are able
>>> to work without a problem, other than the obvious delay opening
>>> files from the shared folders on the DC. The difference in my
>>> current case may be that the host site has a DSL that averages
>>> about 600k (the remote site has a cable connection at 6 Mb/768k).
>>
>> ADSL, I'm presuming. This will never be pretty.
>
> Yes. Cheap DSL from the phone company. I wouldn't be so persistent at
> this if it were not for the fact that I have several similar
> configurations working without any problem for other clients, most
> notably the client that has 2 remote LANs connected via VPN, 4
> concurrent stations each. Logon takes perhaps 60 seconds, and the
> only performance issue is access to shared folders at the host site.
> The remote sites are about the same as this one; the only difference
> is the T-1 at the host site, and that may well be my bottleneck.

Could be....
>
>>>
>>> 3. I need a VPN for two reasons
>>>
>>> a. The remote user needs to print to her house from the host LAN
>>> (using MAS90, a ProvideX-based accounting package), hosted on the
>>> DC, to a multi-function laser printer at the remote office (her
>>> house). As I am sure you are aware, support for many
>>> multi-function printers is very shaky or nonexistent via RDP,
>>
>> Yep....which is why I strongly discourage them. However, you can
>> often find a comparable DeskJet driver for any HP inkjet
>> multifunction, and so on.
>
> I got tired of beating my head against the wall on all-in-one devices
> some time back and gave up, always recommending instead plain laser
> printers except in cases like this where an entire remote office
> needs to operate with the space contraints of a home office.

Yep.
>
>>
>>> so I elected to have the TS
>>> print directly to her IP-based networked printer. This works just
>>> fine with no delays.
>>
>> Well, yes, but you shouldn't need a VPN for that. Printer
>> redirection to a network printer isn't a problem per se....
>
> I plead ignorance here: I don't understand how to redirect a printer
> to a remote LAN without the VPN. Or are you talking about just
> opening the client printer connection through RDP?

Redirecting it to the remote session, yes.

> I thought that
> worked only to printers connected locally to the client.

Nope. See http://www.sessioncomputing.com/printing.htm - most specifically,
http://support.microsoft.com/?kbid=302361


> Besides,
> there are times when other users on the TS need to print to the
> remote office, and it's a pain for them to have to ensure that the
> remote user is online so the printer is available.

How often does this really need to happen?
Again, there's nothing wrong with keeping your VPN even if you use it only
to get her to TS & Exchange, but that won't help w/your file access
performance problems.

>
>>> b. The user needs remote access to both Outlook
>>
>> .....RPC over HTTP will be useful there
>
> I've looked at that a little, and the initial setup docs start
> talking about multiple servers. How workable (and difficult to
> configure) is it on a single SBS2003 server?

Piece of cake. Take a look at http://yourserver/remote - there are
instructions (customized to your server/domain) for setting this up.
>
>>> & shared files hosted
>>> on the server.
>>
>> This won't be pretty, as mentioned....
>>
>>> I know I can leave off the domain membership & just
>>> write a batch file for the user to map the drives (instead of using
>>> the AD login script), but I'm not sure that would be much different.
>>
>> Yes, it will make a big difference.
>
> I understand it makes a huge difference with logon, but I don't think
> it will make much difference with file access, since access is stilll
> remote.

Yep.
>
>>> 4. She does run MAS90 via a terminal server at the host site, but I
>>> don't really want to get into trying to license Word & Excel for the
>>> terminal server,
>>
>> Understood, but if you want good performance for any sort of file
>> access, I'd think this was the most logical path.
>
> Agreed, but that becomes a budget issue for fairly small businesses
> like this one.

How much time are they spending trying to get the existing setup working?
Seems it would be more efficient (and therefore, cheaper) to throw some
money at the problem to make it go away. Every time you have a new remote
office/user, you're going to run into this sort of issue - so why not set it
up properly once, and never worry about it again?
>
>> and she needs realtime access to those types of
>>> files in her home folder & shared folders on the server.
>>
>> Realtime meaning ?
>
> Forget about the time. How about just "real". The organization has
> files that need to be shared amongst users, including this remote
> user, and they are stored on the DC for backup purposes.

Again, TS is your best bet, unless you're going to use DFS or other
replication services to get your data out to remote servers (which would
mean a local DC / file/print server in each office).
>
>>>
>>> The bottom line? Everything works fine except the logon process.
>>
>> Whichis understandable.
>>
>>> Internet access using the DC as her DNS server is perfectly fast;
>>> file access from the DC is slow but adequate. The logon process,
>>> though, takes a good five minutes. At the moment, my first step may
>>> just be to get the host site upgraded to a cable connection at over
>>> 1Mb.
>>
>> That might help, but I'd still be skeptical.
>>>
>>> Someone told me there is a way to have "authentication lite" for
>>> remote stations to speed up the logon process, but I have been
>>> unable to find anything on this.
>>
>> Not sure what they referred to. There are various things you can
>> tweak via group policy, but I'm not sure what you'll be able to do
>> with this.
>>>
>>
>> <snipped for length>

Thanks again. Lots of good info here.

"Lanwench [MVP - Exchange]" wrote:

> Brian <(E-Mail Removed)> wrote:
> > Thanks. See notes inline. It may be that increasing the bandwidth will
> > rectify the situation, but I can't know for sure until I try it.
> >
> > "Lanwench [MVP - Exchange]" wrote:
> >
> >> Brian <(E-Mail Removed)> wrote:
> >>> 1. I have only one user on the remote LAN because she works from her
> >>> home. Defnitely not worth setting up another server.
> >>
> >> Yeah, I guess I can seethat.
> >>>
> >>> 2.I know my method works, because I have another client who has a
> >>> T-1 at their host site (35 LAN stations) with two remote sites on <
> >>> 1Mb DSL's and 4 remote LAN stations each. The remote users are able
> >>> to work without a problem, other than the obvious delay opening
> >>> files from the shared folders on the DC. The difference in my
> >>> current case may be that the host site has a DSL that averages
> >>> about 600k (the remote site has a cable connection at 6 Mb/768k).
> >>
> >> ADSL, I'm presuming. This will never be pretty.
> >
> > Yes. Cheap DSL from the phone company. I wouldn't be so persistent at
> > this if it were not for the fact that I have several similar
> > configurations working without any problem for other clients, most
> > notably the client that has 2 remote LANs connected via VPN, 4
> > concurrent stations each. Logon takes perhaps 60 seconds, and the
> > only performance issue is access to shared folders at the host site.
> > The remote sites are about the same as this one; the only difference
> > is the T-1 at the host site, and that may well be my bottleneck.
>
> Could be....
> >
> >>>
> >>> 3. I need a VPN for two reasons
> >>>
> >>> a. The remote user needs to print to her house from the host LAN
> >>> (using MAS90, a ProvideX-based accounting package), hosted on the
> >>> DC, to a multi-function laser printer at the remote office (her
> >>> house). As I am sure you are aware, support for many
> >>> multi-function printers is very shaky or nonexistent via RDP,
> >>
> >> Yep....which is why I strongly discourage them. However, you can
> >> often find a comparable DeskJet driver for any HP inkjet
> >> multifunction, and so on.
> >
> > I got tired of beating my head against the wall on all-in-one devices
> > some time back and gave up, always recommending instead plain laser
> > printers except in cases like this where an entire remote office
> > needs to operate with the space contraints of a home office.
>
> Yep.
> >
> >>
> >>> so I elected to have the TS
> >>> print directly to her IP-based networked printer. This works just
> >>> fine with no delays.
> >>
> >> Well, yes, but you shouldn't need a VPN for that. Printer
> >> redirection to a network printer isn't a problem per se....
> >
> > I plead ignorance here: I don't understand how to redirect a printer
> > to a remote LAN without the VPN. Or are you talking about just
> > opening the client printer connection through RDP?
>
> Redirecting it to the remote session, yes.
>
> > I thought that
> > worked only to printers connected locally to the client.
>
> Nope. See http://www.sessioncomputing.com/printing.htm - most specifically,
> http://support.microsoft.com/?kbid=302361
>
>
> > Besides,
> > there are times when other users on the TS need to print to the
> > remote office, and it's a pain for them to have to ensure that the
> > remote user is online so the printer is available.
>
> How often does this really need to happen?
> Again, there's nothing wrong with keeping your VPN even if you use it only
> to get her to TS & Exchange, but that won't help w/your file access
> performance problems.
>
> >
> >>> b. The user needs remote access to both Outlook
> >>
> >> .....RPC over HTTP will be useful there
> >
> > I've looked at that a little, and the initial setup docs start
> > talking about multiple servers. How workable (and difficult to
> > configure) is it on a single SBS2003 server?
>
> Piece of cake. Take a look at http://yourserver/remote - there are
> instructions (customized to your server/domain) for setting this up.
> >
> >>> & shared files hosted
> >>> on the server.
> >>
> >> This won't be pretty, as mentioned....
> >>
> >>> I know I can leave off the domain membership & just
> >>> write a batch file for the user to map the drives (instead of using
> >>> the AD login script), but I'm not sure that would be much different.
> >>
> >> Yes, it will make a big difference.
> >
> > I understand it makes a huge difference with logon, but I don't think
> > it will make much difference with file access, since access is stilll
> > remote.
>
> Yep.
> >
> >>> 4. She does run MAS90 via a terminal server at the host site, but I
> >>> don't really want to get into trying to license Word & Excel for the
> >>> terminal server,
> >>
> >> Understood, but if you want good performance for any sort of file
> >> access, I'd think this was the most logical path.
> >
> > Agreed, but that becomes a budget issue for fairly small businesses
> > like this one.
>
> How much time are they spending trying to get the existing setup working?
> Seems it would be more efficient (and therefore, cheaper) to throw some
> money at the problem to make it go away. Every time you have a new remote
> office/user, you're going to run into this sort of issue - so why not set it
> up properly once, and never worry about it again?
> >
> >> and she needs realtime access to those types of
> >>> files in her home folder & shared folders on the server.
> >>
> >> Realtime meaning ?
> >
> > Forget about the time. How about just "real". The organization has
> > files that need to be shared amongst users, including this remote
> > user, and they are stored on the DC for backup purposes.
>
> Again, TS is your best bet, unless you're going to use DFS or other
> replication services to get your data out to remote servers (which would
> mean a local DC / file/print server in each office).
> >
> >>>
> >>> The bottom line? Everything works fine except the logon process.
> >>
> >> Whichis understandable.
> >>
> >>> Internet access using the DC as her DNS server is perfectly fast;
> >>> file access from the DC is slow but adequate. The logon process,
> >>> though, takes a good five minutes. At the moment, my first step may
> >>> just be to get the host site upgraded to a cable connection at over
> >>> 1Mb.
> >>
> >> That might help, but I'd still be skeptical.
> >>>
> >>> Someone told me there is a way to have "authentication lite" for
> >>> remote stations to speed up the logon process, but I have been
> >>> unable to find anything on this.
> >>
> >> Not sure what they referred to. There are various things you can
> >> tweak via group policy, but I'm not sure what you'll be able to do
> >> with this.
> >>>
> >>
> >> <snipped for length>
>
>
>
>