We help IT Professionals succeed at work.

Mapping Network Drives In Vista With UAC Turned On

Medium Priority
1,512 Views
Last Modified: 2012-05-06
I am trying to get a script to map network drives in Windows Vista with UAC turned on.  The domain is a 2003 domain, but the group policies exist for Vista.  I have tried the launchapp.wsf script from Microsoft, and it doesn't map the network drives for local admin accounts on the WIndows Vista machines.  UAC is a requirement for our security policy, and is enforced at the Group Policy Domain level.  Any help is greatly appreciated.  Thanks
Comment
Watch Question

Hypercat (Deb)President
CERTIFIED EXPERT

Commented:
I've run across the same problem, also tried the .wsf script with no luck.  It's sort of a cop-out/workaround, but what I've done for users who have to have local admin rights - i.e., only myself and other network admin accounts - is to put a copy of the login script in the Startup folder in their user profile. I absolutely do NOT allow regular users to have local admin rights.  This makes it a little harder to work with some 3rd party apps, but I use the Microsoft Application Compatibility program to fix most of those problems. If that doesn't work, I give the user a separate account with local admin rights so that they can log on as themselves but use their local admin login only when they get a message from the UAC that they need admin rights to run one of their programs.
Hypercat (Deb)President
CERTIFIED EXPERT

Commented:
Just a clarification - the account with local admin rights that the user has is a workstation local-only account, not a domain account.

Author

Commented:
It's a domain user account, with local admin priviledges.,
Hypercat (Deb)President
CERTIFIED EXPERT

Commented:
That wasn't a question. I was merely adding a clarification to my comment about the workaround. The admin account we create for the user to have for running apps with admin privileges is a local account only, not a domain account. This is to ensure that they don't get any privileges on the domain that they shouldn't have.  All they need is local admin privileges to run the programs, so that's why we give them a local account.

Author

Commented:
The problem is that the scripts run at the elevated level when logging in so the maps appear invisible to admin users (domain or local) when they view explorer with the standard user elevation.  UAC is an evil invention.  I have it turned off right now, but that prevents run as administrator from prompting standard users for credentials when they need to elevate something, so I need to log someone off, and log myself in in order to do something.  The override breaks when UAC is off, and the maps break when it is on.
Hypercat (Deb)President
CERTIFIED EXPERT

Commented:
I'm have a bit of a problem understanding exactly what you are getting at.  Please clarify which description fits your situation:
1.  Users log on with local admin rights, so the domain login script doesn't run properly. You need users to log on with local admin rights for some reason, so you don't want to change this, but you need to have the mapped drives work for these users.
2.  Users log on with local user rights and get their mapped drives.  However, when they get an elevation prompt and use a local admin login, the mapped drives do not appear for that login.

Author

Commented:
When a user logins in in Vista/7 if they have admin irghts of any kind they are given standard user rights until admin rights are needed.  That's when the UAC prompt appears.  However login scripts are run at the admin level so any network maps run at login are not visible to the user because they are running at a higher security level.  The solution to this issue is to turn UAC off, but then when a standard user needs to perform an admin task, instead of being prompted for an admin to enter his password, they just get an access denied message.
President
CERTIFIED EXPERT
Commented:
OK - I think I understand now.  Below is an explanation of how we get around this issue.  There are still problems, but it works better as far as I am concerned.
I have two basic classes of users - regular users and admin users.  
1. I have set group policies for the ADMIN users so that they always have elevated privileges, without having to respond to prompts from the UAC.  This is done only for users that have a high level of access to everything and are completely trustworthy both in their handling of admin rights and privileges and in their knowledge of truthworthy computing behavior. IOW, they are trusted not to inadvertently download bad stuff from the Internet as well as trusted to know what they are doing with their elevated permissions.  The way to do this is to set the policies for the UAC under the Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options as follows:
User Account Control: Behavior of the elevation prompt for administrators.....etc. - set to Elevate without prompting
User Account Control: Run all administrators in Admin Approval Mode - set to Enabled
The problem with this is that the domain login script will not run for these admin users for some reason - I think it's a "feature" not a "bug."  IOW, it works that way on purpose. This is what I tried to fix with the launchapp.wsf script, but it didn't work and maybe I misunderstood what it was supposed to do. Anyway, to get around this, I put a login script in the Startup folder of the users' profiles to map drives, etc.
2. All other users have only local User level rights to their workstations.  If a user has an application that needs to be run with administrative-level access, we create a local account on their workstation with local admin rights.  When they run that program, they will get a UAC prompt and then they use that admin account to give them elevated privileges to run that particular program. If we just need to have occasional elevated privileges when doing something on the user's workstation (i.e., installing a program for them), we respond to the elevation prompt with a domain-level administrative login.
 

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts

Author

Commented:
Ah, so those are the two GPO items that need to be configured.  I'll have to test that.  I'll let you know the results when the GPO is updated.
Top Expert 2007

Commented:
I know this solution is closed, but I ran into the same problem with Vista and here's a wonderful solution that works great:

http://support.microsoft.com/kb/937624
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.