Network drive mapping with %USERNAME%.
Solved
lsda26
-
kelux Posted messages 3065 Registration date Status Contributeur Last intervention -
kelux Posted messages 3065 Registration date Status Contributeur Last intervention -
Hello,
I have a doubt about the use of the environment variable %USERNAME%.
I created a share on my Windows 2008 R2 file server with full control access for my user "toto".
Thanks to a GPO and a logon script, I am mapping several network drives.
However, there is one network drive that is not being created, which is as follows:
When I try to manually map the drive on the user's machine, it still doesn't work. Message: "The specified network resource or device is no longer available."
Nevertheless, with the command:
So my question is: Can you use the environment variable %USERNAME% in a network path for mapping a network drive?
Configuration: Windows 7 / Firefox 24.0
I have a doubt about the use of the environment variable %USERNAME%.
I created a share on my Windows 2008 R2 file server with full control access for my user "toto".
Thanks to a GPO and a logon script, I am mapping several network drives.
However, there is one network drive that is not being created, which is as follows:
net use Y: \\serveurfic\users\%USERNAME%
When I try to manually map the drive on the user's machine, it still doesn't work. Message: "The specified network resource or device is no longer available."
Nevertheless, with the command:
net use Y: \\serveurfic\users\totothe mapping of the network drive works correctly.
So my question is: Can you use the environment variable %USERNAME% in a network path for mapping a network drive?
Configuration: Windows 7 / Firefox 24.0
2 réponses
Hello,
Can we use the environment variable %USERNAME% in a network path for mounting a network drive?
Yes.
The issue might lie elsewhere.
- The network hasn't fully "mounted," and the script is running. (You need to check a GPO setting: "wait for the network blablabla...."
- The login script should be run for users rather than machines (understanding "user context" and not "machine context": is the GPO linked to an OU containing users or machines?). This is a very good lead.
- Is the Y: drive available when the script executes? (i.e., the letter is not being used by another device. At worst, change the letter for testing...)
- Avoid short "netbios" names when pointing to a server, especially in scripts. Using the FQDN is recommended: in terms of resolution, it forces DNS in this case, not netbios (WINS/Broadcast/Hosts, etc.); in terms of future migration: if the server name changes, just keep this alias pointing to the new server... so no need to modify the script.
- Mapped drives should be disconnected at session logoff.
It's best to use
Or also the
- Redirecting logs for error returns is a good way to find the source of the problem.
-
Final point, using scripts to initiate the mounting of mapped drives has become, let's say, "OldSchool."
We now use GPP to mount network drives ('especially' with 2008R2 ...)
So we can have just one group policy, but with several GPPs inside, pointing to different sets of users and groups....
This way, we can mount mapped drives for different user groups (like 'Accounting' on one side and 'Management' on the other) within a single policy; that is, we filter group membership in the GPPs...
Do some tests with GPPs, it's relatively powerful; there are some pretty fun filtering options.
--
Luc L.
[Gentoo Is Good]
Can we use the environment variable %USERNAME% in a network path for mounting a network drive?
Yes.
The issue might lie elsewhere.
- The network hasn't fully "mounted," and the script is running. (You need to check a GPO setting: "wait for the network blablabla...."
- The login script should be run for users rather than machines (understanding "user context" and not "machine context": is the GPO linked to an OU containing users or machines?). This is a very good lead.
- Is the Y: drive available when the script executes? (i.e., the letter is not being used by another device. At worst, change the letter for testing...)
- Avoid short "netbios" names when pointing to a server, especially in scripts. Using the FQDN is recommended: in terms of resolution, it forces DNS in this case, not netbios (WINS/Broadcast/Hosts, etc.); in terms of future migration: if the server name changes, just keep this alias pointing to the new server... so no need to modify the script.
- Mapped drives should be disconnected at session logoff.
It's best to use
net use * /delete /yesat the beginning of the script.
Or also the
/persistent:nooption for each drive at mount.
- Redirecting logs for error returns is a good way to find the source of the problem.
-
Final point, using scripts to initiate the mounting of mapped drives has become, let's say, "OldSchool."
We now use GPP to mount network drives ('especially' with 2008R2 ...)
So we can have just one group policy, but with several GPPs inside, pointing to different sets of users and groups....
This way, we can mount mapped drives for different user groups (like 'Accounting' on one side and 'Management' on the other) within a single policy; that is, we filter group membership in the GPPs...
Do some tests with GPPs, it's relatively powerful; there are some pretty fun filtering options.
--
Luc L.
[Gentoo Is Good]