Jump to content
|Topic||Stats||Last action by|
|Web design guidelines||
|Student to raise money for homeless man who offered her his last £3||
|South Dakota's 'Don't Jerk and Drive' Campaign Rubs People the Wrong Way||
|Texas City plumber's truck ends up in Syrian war||
|PS3 Media Server / Universal Media Server Guide||
Posted 15 July 2013 - 10:37
Posted 15 July 2013 - 11:59
You can map drives using Group Policy, simply configure it and apply it to the OU your users are in.
Or have a batch file to run every time a user logs in. An batch file would be:
net use z: \\nas\share1
Posted 15 July 2013 - 12:17
But it seems not to work.
Try this: Copy that script you wrote into the NETLOGON folder, and instead of "Browsing" for the file, type in "%logonserver%\netlogon\map.bat" without the quotes.
Posted 15 July 2013 - 13:52
It takes 2 reboots for a gpo to take place on windows xp machines. You can force the policy by using the following command:
you can check to see if your policy is being applied by using the following command
you can graphically see what policies are being applied by using this at a run prompt
If you do not see your policy being applied, you will never be able to map drives using the method laid out.
Posted 15 July 2013 - 15:54
Posted 15 July 2013 - 15:59
Yes which is why I would recommend a iscsi NAS. It can be linux based, it just needs to support the iscsi protocol. If it is enabled, then windows can see the share as a local drive to the server and apply permissions and shares accordingly.
Posted 15 July 2013 - 16:10
On topic: A Linux based NAS with a Windows domain and its permissions is a hellhole...
If your NAS runs Linux it almost certainly uses SAMBA, which supports Windows domains very well. If you are referring to problems you are having setting up user accounts or syncing permissions for AD, I recommend that you join the NAS to your domain. At my workplace we have a Windows domain with almost exclusively Windows 7 clients, but all of our network storage servers are either RHEL-based or Debian-based. We have them all joined to the domain and configured to allow login from users in specific AD groups. The key is keeping those servers in a separate OU so the GP for clients doesn't apply to them. For more detailed information read the Domain Membership chapter of the SAMBA Manual.