Radius118

No worries, I'm still pretty new myself.

Based on what I understand you are trying to do, that DFS really is your answer. You can go through and set up security groups for uses, and go through all your shares and set it up but it's going to be time consuming and cumbersome. Michael

Wow! No offense, but that seems like a mess. You should really start using DFS. The beauty of DFS is that you create a namespace such as .local\home. Then you can assign all of your shares to this namespace by making DFS folders. In our organization, we have shares across 12 servers with about 35 folders. All of them are available from one location. The real location of the share becomes transparent to the users and you only have to map one location. Assign your permissions when you create the DFS folders and you're done. If you have permissions to view the folder, it's there. If not, then it's not visible. Not only that, but it adds incredible flexibility to your network. So when our users logon, it maps Y: to \\.local\home and we're done. We make sure that all users have access to that share, then restrict access to the individual folders inside that share. So now the whole company refers to the "Y" drive. It really works well. For example, we have a lot of custom scripts that run to process EDI data coming in from our customers. Instead of having each script run in a specific share, we specify a folder from our root DFS. So instead of specifying something like: \\server\folder1\folder2 We do this instead: \\.local\home\folder What's great about this is that if for some reason you decide to move that share, all you have to do is copy it and update the DFS share. You don't have to run around modifying scripts, etc, in order to avoid breaking something. Another example of the flexibility of DFS. I needed more hard drive space for our server nightly backups. So I created a new namespace Archive. So the path is \\.local\Archive. I added 3 different shares to this namespace. All 3 shares are on different machines. So now when I do network backups, my path is \\.local\Archive\Backup or Backup2 or Backup3. Then I set Windows backup to backup to these shares. If I decide to move one of these shares, it's easy. Simply copy the data where I want it to go, delete the original share, make a new share at the new location, and update DFS. Done. I don't have to log on to 6 different servers and reconfigure the nightly backup. Make sense? I think I got a little verbose there. As for your current issue, you definitely have some type of permissions issue going on there. Why do you want to remove Domain User permissions from these shares? Michael

Here are a few links, although some of them are a little old: Assign computer startup scripts: Group Policy Overview of Logon, Logoff, Startup, and Shutdown Scripts in Windows 2000 Windows 2000 Script Policies And here is some information on Group Policy Preferences: Group Policy FAQ #1: What are the Group Policy Preferences Prerequisites?

By default, Startup scripts run as Local System, and they have the full rights that are associated with being able to run as Local System. Logon script scripts run on the User account and not on the Administrator account. So, if these are logon scripts, and the user account they are running under are members of the Domain Users group, and you remove that group from permissions for the shared resource, then the logon script will no longer have permissions to run. If these are not your scripts, I would start with checking to see if the script is running under group policy in Group Policy Management. If they aren't, then I would consider reconfiguring things so they can run under Group Policy. I have a few links for you, but I can't post them because my post count is too low. I will be able to on the next post though. So I will try. Michael

Why not define security groups in AD, then define access to network shares using those groups? Then use a simple logon script to automatically map the shares. To answer your question, you might want to look at the permissions the script runs under. If it runs in the Domain Users group - although with enhanced permissions - then removing the Domain Users permissions from the share will result in the script not having necessary permissions. At least that's my guess anyway. Michael