Remote Users

We have a few office users who regularly travel with their laptops.
They use their laptops for both office and remote use. They log in to
our Windows Server 2003 A/D domain in the office, but still use the
same login credentials on the road. Obviously they can't connect to
our domain while hooked up to some hotel ISP, but they still login
using those credentials nonetheless.

I am thinking maybe I should set up another profile for the remote
users on their laptop. One that logs into the laptop locally.

I think this might solve some of VPN errors they get when trying to
access network drives across the VPN. They get the "this drive cannot
be opened...name or resource already in use..." error.

I think this happens because the user is logging into the laptop(from
a remote location) with the A/D domain credentials, and they are also
connecting to the network resource with the same credentials.

Any thoughts?

Thanks

cmt <(E-Mail Removed)> wrote:
> We have a few office users who regularly travel with their laptops.
> They use their laptops for both office and remote use. They log in to
> our Windows Server 2003 A/D domain in the office, but still use the
> same login credentials on the road. Obviously they can't connect to
> our domain while hooked up to some hotel ISP, but they still login
> using those credentials nonetheless.
>
> I am thinking maybe I should set up another profile for the remote
> users on their laptop. One that logs into the laptop locally.
>
> I think this might solve some of VPN errors they get when trying to
> access network drives across the VPN. They get the "this drive cannot
> be opened...name or resource already in use..." error.
>
> I think this happens because the user is logging into the laptop(from
> a remote location) with the A/D domain credentials, and they are also
> connecting to the network resource with the same credentials.
>
> Any thoughts?
>
> Thanks

Well, I would keep the setup you have now, because these computers *do* at
times connect directly to the network/domain ...if they didn't, I'd have 'em
use local accounts only.

You really don't want to create local login accounts for them, I think -
they'll have two Windows profiles (or you have to try scary registry
things).

I suspect the issue is that they have persistent/locally created network
drive mappings. I'd give them each a little batch file, put it on the
desktop, & tell 'em to run it after enabling the VPN connection....e.g.,

net use x: /del
net use x: \\server\share /persistent:no
net use y: /del
net use y: \\server\anothershare /persistent:no

See if that helps.

On Mar 23, 10:15 am, "Lanwench [MVP - Exchange]"
<lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
> cmt <chrismt...@gmail.com> wrote:
> > We have a few office users who regularly travel with their laptops.
> > They use their laptops for both office and remote use. They log in to
> > our Windows Server 2003 A/D domain in the office, but still use the
> > same login credentials on the road. Obviously they can't connect to
> > our domain while hooked up to some hotel ISP, but they still login
> > using those credentials nonetheless.
>
> > I am thinking maybe I should set up another profile for the remote
> > users on their laptop. One that logs into the laptop locally.
>
> > I think this might solve some of VPN errors they get when trying to
> > access network drives across the VPN. They get the "this drive cannot
> > be opened...name or resource already in use..." error.
>
> > I think this happens because the user is logging into the laptop(from
> > a remote location) with the A/D domain credentials, and they are also
> > connecting to the network resource with the same credentials.
>
> > Any thoughts?
>
> > Thanks
>
> Well, I would keep the setup you have now, because these computers *do* at
> times connect directly to the network/domain ...if they didn't, I'd have 'em
> use local accounts only.
>
> You really don't want to create local login accounts for them, I think -
> they'll have two Windows profiles (or you have to try scary registry
> things).
>
> I suspect the issue is that they have persistent/locally created network
> drive mappings. I'd give them each a little batch file, put it on the
> desktop, & tell 'em to run it after enabling the VPN connection....e.g.,
>
> net use x: /del
> net use x: \\server\share /persistent:no
> net use y: /del
> net use y: \\server\anothershare /persistent:no
>
> See if that helps.- Hide quoted text -
>
> - Show quoted text -

So write a custom batch script that first deletes any possible network
drives, and then reconnects them AFTER the connection to the VPN is
complete?

cmt <(E-Mail Removed)> wrote:
> On Mar 23, 10:15 am, "Lanwench [MVP - Exchange]"
> <lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
>> cmt <chrismt...@gmail.com> wrote:
>>> We have a few office users who regularly travel with their laptops.
>>> They use their laptops for both office and remote use. They log in
>>> to our Windows Server 2003 A/D domain in the office, but still use
>>> the same login credentials on the road. Obviously they can't
>>> connect to our domain while hooked up to some hotel ISP, but they
>>> still login using those credentials nonetheless.
>>
>>> I am thinking maybe I should set up another profile for the remote
>>> users on their laptop. One that logs into the laptop locally.
>>
>>> I think this might solve some of VPN errors they get when trying to
>>> access network drives across the VPN. They get the "this drive
>>> cannot be opened...name or resource already in use..." error.
>>
>>> I think this happens because the user is logging into the
>>> laptop(from a remote location) with the A/D domain credentials, and
>>> they are also connecting to the network resource with the same
>>> credentials.
>>
>>> Any thoughts?
>>
>>> Thanks
>>
>> Well, I would keep the setup you have now, because these computers
>> *do* at times connect directly to the network/domain ...if they
>> didn't, I'd have 'em use local accounts only.
>>
>> You really don't want to create local login accounts for them, I
>> think - they'll have two Windows profiles (or you have to try scary
>> registry things).
>>
>> I suspect the issue is that they have persistent/locally created
>> network drive mappings. I'd give them each a little batch file, put
>> it on the desktop, & tell 'em to run it after enabling the VPN
>> connection....e.g.,
>>
>> net use x: /del
>> net use x: \\server\share /persistent:no
>> net use y: /del
>> net use y: \\server\anothershare /persistent:no
>>
>> See if that helps.- Hide quoted text -
>>
>> - Show quoted text -
>
> So write a custom batch script that first deletes any possible network
> drives, and then reconnects them AFTER the connection to the VPN is
> complete?

If you use what I wrote above, all the user has to do is enable the VPN
tunnel and run the batch file manually. It's not the most elegant solution,
but it does work.

On Mar 25, 10:03 am, "Lanwench [MVP - Exchange]"
<lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
> cmt <chrismt...@gmail.com> wrote:
> > On Mar 23, 10:15 am, "Lanwench [MVP - Exchange]"
> > <lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
> >> cmt <chrismt...@gmail.com> wrote:
> >>> We have a few office users who regularly travel with their laptops.
> >>> They use their laptops for both office and remote use. They log in
> >>> to our Windows Server 2003 A/D domain in the office, but still use
> >>> the same login credentials on the road. Obviously they can't
> >>> connect to our domain while hooked up to some hotel ISP, but they
> >>> still login using those credentials nonetheless.
>
> >>> I am thinking maybe I should set up another profile for the remote
> >>> users on their laptop. One that logs into the laptop locally.
>
> >>> I think this might solve some of VPN errors they get when trying to
> >>> access network drives across the VPN. They get the "this drive
> >>> cannot be opened...name or resource already in use..." error.
>
> >>> I think this happens because the user is logging into the
> >>> laptop(from a remote location) with the A/D domain credentials, and
> >>> they are also connecting to the network resource with the same
> >>> credentials.
>
> >>> Any thoughts?
>
> >>> Thanks
>
> >> Well, I would keep the setup you have now, because these computers
> >> *do* at times connect directly to the network/domain ...if they
> >> didn't, I'd have 'em use local accounts only.
>
> >> You really don't want to create local login accounts for them, I
> >> think - they'll have two Windows profiles (or you have to try scary
> >> registry things).
>
> >> I suspect the issue is that they have persistent/locally created
> >> network drive mappings. I'd give them each a little batch file, put
> >> it on the desktop, & tell 'em to run it after enabling the VPN
> >> connection....e.g.,
>
> >> net use x: /del
> >> net use x: \\server\share /persistent:no
> >> net use y: /del
> >> net use y: \\server\anothershare /persistent:no
>
> >> See if that helps.- Hide quoted text -
>
> >> - Show quoted text -
>
> > So write a custom batch script that first deletes any possible network
> > drives, and then reconnects them AFTER the connection to the VPN is
> > complete?
>
> If you use what I wrote above, all the user has to do is enable the VPN
> tunnel and run the batch file manually. It's not the most elegant solution,
> but it does work.


What if accessing the share requires a username and password? I can't
figure out how to get it work because of that issue.

Thanks!

cmt <(E-Mail Removed)> wrote:

<snip>

>>
>> If you use what I wrote above, all the user has to do is enable the
>> VPN tunnel and run the batch file manually. It's not the most
>> elegant solution, but it does work.
>
>
> What if accessing the share requires a username and password? I can't
> figure out how to get it work because of that issue.
>
> Thanks!


Well:

a) presuming they've logged into the domain using their cached credentials,
and those credentials would give them access if they were on the LAN, they
shouldn't be prompted at all

b) if it *did* prompt them, they could enter the domain username once
<enter> and type in the password once <enter> and it would persist
throughout their connection.

You really might just try this yourself to see how it works. It's pretty
easy.

On Mar 27, 8:23 pm, "Lanwench [MVP - Exchange]"
<lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
> cmt <chrismt...@gmail.com> wrote:
>
> <snip>
>
>
>
> >> If you use what I wrote above, all the user has to do is enable the
> >> VPN tunnel and run the batch file manually. It's not the most
> >> elegant solution, but it does work.
>
> > What if accessing the share requires a username and password? I can't
> > figure out how to get it work because of that issue.
>
> > Thanks!
>
> Well:
>
> a) presuming they've logged into the domain using their cached credentials,
> and those credentials would give them access if they were on the LAN, they
> shouldn't be prompted at all
>
> b) if it *did* prompt them, they could enter the domain username once
> <enter> and type in the password once <enter> and it would persist
> throughout their connection.
>
> You really might just try this yourself to see how it works. It's pretty
> easy.

I actually have tried this at home. The problem is, when remote, the
users just log into the VPN(Cisco PIX), but they do not log into the
domain. Although they *DO* log into their laptop with the same
credentials as they would the domain, they just can't connect to the
domain because they are remote.

I guess I'm just trying to figure out the best way for my remote users
to connect to our domain resources(networked drives and Exchange).

So far success has been limited because they often receive the error
"cannot connect to this device because the name is already in use..."
Or they just can't connect at all.

Thanks!

cmt <(E-Mail Removed)> wrote:
> On Mar 27, 8:23 pm, "Lanwench [MVP - Exchange]"
> <lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
>> cmt <chrismt...@gmail.com> wrote:
>>
>> <snip>
>>
>>
>>
>>>> If you use what I wrote above, all the user has to do is enable the
>>>> VPN tunnel and run the batch file manually. It's not the most
>>>> elegant solution, but it does work.
>>
>>> What if accessing the share requires a username and password? I
>>> can't figure out how to get it work because of that issue.
>>
>>> Thanks!
>>
>> Well:
>>
>> a) presuming they've logged into the domain using their cached
>> credentials, and those credentials would give them access if they
>> were on the LAN, they shouldn't be prompted at all
>>
>> b) if it *did* prompt them, they could enter the domain username once
>> <enter> and type in the password once <enter> and it would persist
>> throughout their connection.
>>
>> You really might just try this yourself to see how it works. It's
>> pretty easy.
>
> I actually have tried this at home. The problem is, when remote, the
> users just log into the VPN(Cisco PIX),

They don't really 'log in' to this - it's their VPN endpoint.

> but they do not log into the
> domain. Although they *DO* log into their laptop with the same
> credentials as they would the domain, they just can't connect to the
> domain because they are remote.

They can, if the tunnel is available, and they can resolve names on the
remote network (DNS and probably also WINS).
>
> I guess I'm just trying to figure out the best way for my remote users
> to connect to our domain resources(networked drives

VPN access to files usually stinks, in my opinion (mainly from a performance
standpoint). Terminal Services (or even remote desktop to WinXP Pro boxen on
your network) is far better.

> and Exchange).

RPC over HTTP, using OL2003 or 2007 on WinXP or Vista (presuming you're
running E2003/2007 on W2003)
>
> So far success has been limited because they often receive the error
> "cannot connect to this device because the name is already in use..."

What happened when you tried it using the batch file syntax I provided
earlier? Exact error messages would help.

>
> Or they just can't connect at all.
>
> Thanks!

On Mar 28, 1:44 pm, "Lanwench [MVP - Exchange]"
<lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
> cmt <chrismt...@gmail.com> wrote:
> > On Mar 27, 8:23 pm, "Lanwench [MVP - Exchange]"
> > <lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
> >> cmt <chrismt...@gmail.com> wrote:
>
> >> <snip>
>
> >>>> If you use what I wrote above, all the user has to do is enable the
> >>>> VPN tunnel and run the batch file manually. It's not the most
> >>>> elegant solution, but it does work.
>
> >>> What if accessing the share requires a username and password? I
> >>> can't figure out how to get it work because of that issue.
>
> >>> Thanks!
>
> >> Well:
>
> >> a) presuming they've logged into the domain using their cached
> >> credentials, and those credentials would give them access if they
> >> were on the LAN, they shouldn't be prompted at all
>
> >> b) if it *did* prompt them, they could enter the domain username once
> >> <enter> and type in the password once <enter> and it would persist
> >> throughout their connection.
>
> >> You really might just try this yourself to see how it works. It's
> >> pretty easy.
>
> > I actually have tried this at home. The problem is, when remote, the
> > users just log into the VPN(Cisco PIX),
>
> They don't really 'log in' to this - it's their VPN endpoint.
>
> > but they do not log into the
> > domain. Although they *DO* log into their laptop with the same
> > credentials as they would the domain, they just can't connect to the
> > domain because they are remote.
>
> They can, if the tunnel is available, and they can resolve names on the
> remote network (DNS and probably also WINS).
>
>
>
> > I guess I'm just trying to figure out the best way for my remote users
> > to connect to our domain resources(networked drives
>
> VPN access to files usually stinks, in my opinion (mainly from a performance
> standpoint). Terminal Services (or even remote desktop to WinXP Pro boxen on
> your network) is far better.
>
> > and Exchange).
>
> RPC over HTTP, using OL2003 or 2007 on WinXP or Vista (presuming you're
> running E2003/2007 on W2003)
>
>
>
> > So far success has been limited because they often receive the error
> > "cannot connect to this device because the name is already in use..."
>
> What happened when you tried it using the batch file syntax I provided
> earlier? Exact error messages would help.
>
>
>
> > Or they just can't connect at all.
>
> > Thanks!


The little batch file you gave me works wonderfully for me at home.
But some users are getting this error:

The local devise name is already in use. the connection has not been
restored.

They get that error when they run the script. But I can't figure out
why it would give that to them.

cmt <(E-Mail Removed)> wrote:
> On Mar 28, 1:44 pm, "Lanwench [MVP - Exchange]"
> <lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
>> cmt <chrismt...@gmail.com> wrote:
>>> On Mar 27, 8:23 pm, "Lanwench [MVP - Exchange]"
>>> <lanwe...@heybuddy.donotsendme.unsolicitedmail.aty ahoo.com> wrote:
>>>> cmt <chrismt...@gmail.com> wrote:
>>
>>>> <snip>
>>
>>>>>> If you use what I wrote above, all the user has to do is enable
>>>>>> the VPN tunnel and run the batch file manually. It's not the most
>>>>>> elegant solution, but it does work.
>>
>>>>> What if accessing the share requires a username and password? I
>>>>> can't figure out how to get it work because of that issue.
>>
>>>>> Thanks!
>>
>>>> Well:
>>
>>>> a) presuming they've logged into the domain using their cached
>>>> credentials, and those credentials would give them access if they
>>>> were on the LAN, they shouldn't be prompted at all
>>
>>>> b) if it *did* prompt them, they could enter the domain username
>>>> once <enter> and type in the password once <enter> and it would
>>>> persist throughout their connection.
>>
>>>> You really might just try this yourself to see how it works. It's
>>>> pretty easy.
>>
>>> I actually have tried this at home. The problem is, when remote,
>>> the users just log into the VPN(Cisco PIX),
>>
>> They don't really 'log in' to this - it's their VPN endpoint.
>>
>>> but they do not log into the
>>> domain. Although they *DO* log into their laptop with the same
>>> credentials as they would the domain, they just can't connect to the
>>> domain because they are remote.
>>
>> They can, if the tunnel is available, and they can resolve names on
>> the remote network (DNS and probably also WINS).
>>
>>
>>
>>> I guess I'm just trying to figure out the best way for my remote
>>> users to connect to our domain resources(networked drives
>>
>> VPN access to files usually stinks, in my opinion (mainly from a
>> performance standpoint). Terminal Services (or even remote desktop
>> to WinXP Pro boxen on your network) is far better.
>>
>>> and Exchange).
>>
>> RPC over HTTP, using OL2003 or 2007 on WinXP or Vista (presuming
>> you're running E2003/2007 on W2003)
>>
>>
>>
>>> So far success has been limited because they often receive the error
>>> "cannot connect to this device because the name is already in
>>> use..."
>>
>> What happened when you tried it using the batch file syntax I
>> provided earlier? Exact error messages would help.
>>
>>
>>
>>> Or they just can't connect at all.
>>
>>> Thanks!
>
>
> The little batch file you gave me works wonderfully for me at home.
> But some users are getting this error:
>
> The local devise name is already in use. the connection has not been
> restored.
>
> They get that error when they run the script. But I can't figure out
> why it would give that to them.

try:

net use * /del /y

then the net use commands to map the drives.