Just a clarification - the account with local admin rights that the user has is a workstation local-only account, not a domain account.
Main Topics
Browse All TopicsI 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
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
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.
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.
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.
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.
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/Win
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.
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.c
Business Accounts
Answer for Membership
by: hypercatPosted on 2009-02-12 at 10:10:26ID: 23624831
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.