Repost: User Independent Mapped Drive

Currently, I'm managing a network that has (about) 5 different
physical locations. The network has been configured as one giant
domain. Most users stay at one specific office, but there are times
when a user from one location will be sent to a different location
for
coverage purposes.

Each location has it's own OU in AD. Right now, we have a GPO for each
OU that runs a batch file (when the user logs on) to map the drives.
The problem is that when a user goes to a different office, they need
to map to the server of the office they're currently in and NOT the
server of where they're from.


Moving the Users from one OU to another isn't feasible, as the company
(in the future) would like to be able to have a user visit several
different offices a day without having to call support to change their
mappings.


A quick work around we've been using is put a batch file in the
startup folder of each PC (so no matter who logs on the mappings are
correct), but I know that this is not a long term solution.


I have tried putting the batch file to map the drives as a startup
script (vs. a login script which is based on user and not PC), but the
script doesn't map the drives.


So at this point I'm stumped. The short summary of what I'm trying to
do is create a script (or batch file) that will always map the same
drives base on computer location and not user location via the
server.

The last time I posted this, someone asked me if the sites were
defined in "Sites and Services" in the AD, and they are.

One other bit of info. I've looked into DFS, and it would not work in
this situation. The files for the programs are specific to each
location. DFS would also have a negative effect on network speed (as
the servers in each location have the files the users need).


Thanks!

hi,
if on site and services are defined the sites for each location go to site
and services, right click on a site and choose group policies, create a new
one or edit one if exists and on user configuration->windows
settings->scripts(logon/logoff) add on logon your script with the according
mapped drive. that will be applied on all users wich are login on that site.

--
Dragos CAMARA
MCSA Windows 2003 server


"(E-Mail Removed)" wrote:

> Currently, I'm managing a network that has (about) 5 different
> physical locations. The network has been configured as one giant
> domain. Most users stay at one specific office, but there are times
> when a user from one location will be sent to a different location
> for
> coverage purposes.
>
> Each location has it's own OU in AD. Right now, we have a GPO for each
> OU that runs a batch file (when the user logs on) to map the drives.
> The problem is that when a user goes to a different office, they need
> to map to the server of the office they're currently in and NOT the
> server of where they're from.
>
>
> Moving the Users from one OU to another isn't feasible, as the company
> (in the future) would like to be able to have a user visit several
> different offices a day without having to call support to change their
> mappings.
>
>
> A quick work around we've been using is put a batch file in the
> startup folder of each PC (so no matter who logs on the mappings are
> correct), but I know that this is not a long term solution.
>
>
> I have tried putting the batch file to map the drives as a startup
> script (vs. a login script which is based on user and not PC), but the
> script doesn't map the drives.
>
>
> So at this point I'm stumped. The short summary of what I'm trying to
> do is create a script (or batch file) that will always map the same
> drives base on computer location and not user location via the
> server.
>
> The last time I posted this, someone asked me if the sites were
> defined in "Sites and Services" in the AD, and they are.
>
> One other bit of info. I've looked into DFS, and it would not work in
> this situation. The files for the programs are specific to each
> location. DFS would also have a negative effect on network speed (as
> the servers in each location have the files the users need).
>
>
> Thanks!
>
>