Login script problems

[wingnut144]

We recently moved to a different domain, previous to that, OUR DC had our login script and all worked well.

The login script is defined in our GPO and works well for everyone else (running XP), I'm the only one on Win7 and its not running for me.

Its a simple .vbs script. The odd thing is, when I save the file to my desktop and run the .vbs locally, it runs fine, and maps the drives I need, etc., it just won't run when I log into the domain.

If I log into another machine running WinXP, the login script runs just fine.

Any ideas???

 

[JimKeating]

Logon Script Issue .vbs

I found that if you turn the "User Account Control" settings to the lowest level the GP Scripts will run. We run 2 Scripts. A batch file to copy icons to the desktop and a .vbs script to map the drives. The batch file had no problem running but it was a different story with the .vbs script.

There is probably an easier way to allow the .vbs script without dumbing down the "User Account Controls" Does anyone know how?

Thanks, JK

 

[mattlok]

Same problem as well but check this out

Hey guys,

i am having the same problems will my logon script for mapped drives through GPO.

although i am using a logonscript.cmd file instead with simple net use command.

but this link explained a bit better what is going on because it is related to the UAC and token for each user:

Logon script that map network drives failes to apply if UAC is on. - Vista Forums

I know from my end if i run the logonscript.cmd as the domain user (even though it belongs to the local admin group), the cmd windows shows as running as local administrator account even though i am logged in as domain user.

the funny thing is if i run the cmd prompt manually (from the run command or from accessories group) it will launch as domain user and i can manually type in the net use command to map the network drives:

echo off
Title Login in Process for %Username%... Please Wait.
net time \\ABC01 /set /yes
net use H: /d
net use K: /d
net use K: \\ABC01\CompanyData\Accounting /persistent:no >nul
net use M: /d
net use M: \\ABC01\CompanyData\Management /persistent:no >nul
net use P: /d
net use P: \\ABC01\CompanyData\Public /persistent:no >nul
net use X: /d
net use X: \\XYZVM\images /persistent:no >nul

RUNDLL32 PRINTUI.DLL,PrintUIEntry /in /n\\MARKLYN01\hp2200

-----------------------------------------------

There's no rocket sceince to the script. However based on everything i read so far it has to do with the UAC and the token per user it runs.

Other people said to use this regedit:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLinkedConnections"=dword:00000001

but it never worked for me at all for both vista and windows 7

also a technet post claims to use the launchscript.wsf - which the script is broken.

Even another user which is in the link above had made changes to the launchscript.wsf and made it work but had to add another script.

However as much as a success to that user, none of the solution works for me here in our environment.

Hopefully someone can ringout a universal solution that works for at least 75% of common network environments. (i know each environment is different be we all have common denominators in GPO)

Please help!!!

 

[Opportunitor]

Interesting topic.
Does anyone have found a solution yet?

 

[WindowsStar]

We found that .CMD scripts have a hard time running in a domain because of UAC. However .VBS seem to work fine, unless you are doing something that requires Admin Rights. All of our XP and 7 machines work fine with the .VBS logon scripts.

 

[Opportunitor]

@WindowsStar: Okay. thanks for reply
At this moment I'm busy to finetune some vbs- and kixtart scripts to improve the logon processes. Automated logonscripts are awesome! Maybe you want to post some examples of vbs-logonscripts that works well on your W7-systems?

Here's only a workgroup-based network, rather then a domain, consist of 1 W7-64 and 3 XP-SP3 workstations - where W7 also acts as server . Up to now their cooperation seems well because all workstations shares the same (local) groups, users, grouppolicy- and secpol settings.

Although I already consider a home-server for two years, W7 offers many administrative tools to discover yet. Now I try to manually set these stuff. Actually, I really would prefer a central AD with associated advantages like dsa.msc, gpmc.msc and access-based enumeration, without install a server version.

By the way- I just left the UAC alone for weeks ago. Too much hassle for me

 

[WindowsStar]

@WindowsStar: Okay. thanks for reply
At this moment I'm busy to finetune some vbs- and kixtart scripts to improve the logon processes. Automated logonscripts are awesome! Maybe you want to post some examples of vbs-logonscripts that works well on your W7-systems?

Here's only a workgroup-based network, rather then a domain, consist of 1 W7-64 and 3 XP-SP3 workstations - where W7 also acts as server . Up to now their cooperation seems well because all workstations shares the same (local) groups, users, grouppolicy- and secpol settings.

Although I already consider a home-server for two years, W7 offers many administrative tools to discover yet. Now I try to manually set these stuff. Actually, I really would prefer a central AD with associated advantages like dsa.msc, gpmc.msc and access-based enumeration, without install a server version.

By the way- I just left the UAC alone for weeks ago. Too much hassle for me

You may NOT want to use Kixtart due to the many issues you will run into with UAC. Plus you will have to pre-install it on every machine before you can use it. It is best to use pure Microsoft VBS for your scripts. You will have the least amount of trouble.

What type of scripting examples are you wanting???

 

[Opportunitor]

Hi there,

Well, your warnings about Kixtart will be appreciated. I remember how powerful they were, explained by a fellow IT-collegue at work years ago.
What I want to achieve is to assign a per-user .vbs or .bat loginscript, stored in a central folder and invoked every time the user logs on (set via lusrmgr.msc). This page (Windows Logon Scripts - VBScript examples to create printers, map network drives) already seems to be a good source to me.

The script must perform at least the following tasks (per-session):
-remove and/or rename existing local and network drives;
-map c.q. attach multiple network drives and connect to different networkprinters;
-set access-based enumeration c.q. hide and restrict unused drives;
-set userpolicies to restrict or personalize desktop, start menu, taskbar, regedit et cetera.

Also I want to set up a mandatory or roaming profile for some specific users (as Windows SteadyState provides).

Thanks in advance!

 

[WindowsStar]

I just want to clarify you want to do this without a domain? or you are considering setting up a domain?

 

[Opportunitor]

I just want to clarify you want to do this without a domain? or you are considering setting up a domain?

At this moment within a workgroup. AFAIN, setting up a domain is not possible in a W7 client without a Windows Server version. I just want to simulate the Server environment much as possible

 

[WindowsStar]

If you want to PM me with your current logon CMD script I can convert it to VBS.

 

[djkc909]

Solution

From Install Network printers without Local admin rights in windows 7


There are TWO "Point and Print Restrictions" settings

• Computer Configuration/Policies/Administrative Templates/Printers/Point and Print Restrictions
• User Configuration/Policies/Administrative Templates/Control Panel/Printers/Point and Print Restrictions

Of these two, the one under Computer Configuration seems to be the important one. But guess what? The original Server 2008 doesn't include this setting in the list -- you need Server 2008R2 for this setting to show up. If you download the administrative templates from Server 2008 R2, extract, and copy the PolicyDefinitions folder to C:\Windows\sysvol\domain\Policies\PolicyDefinitions, this missing policy will show up magically in Group Policy Management Editor. Of course, the ADMX files from Server 2008 R2 causes Group Policy Management Editor from Server 2008 tocomplain about parse errors, but it works just fine to click "OK".




Once you've installed the proper ADMX files, for this to work in Windows 7, configure bothof these "Point and Print Restrictions" settings to:

• Enabled
• Security Prompts, When Installing Drivers for a new connection = Do not show warning or elevation prompt
• Security Prompts, When Installing Drivers for a new connection = Do not show warning or elevation prompt

Also, don't forget to make sure the users have permission to install printer drivers, since you're not even going to try to use Admin privileges any more:

• Computer Configuration\Policies\Administrative Templates\System\Driver Installation
• The setting is called "Allow non-administrators to install drivers for these devices setup classes".
• You will need to add thedevice class GUID of printers: {4d36e979-e325-11ce-bfc1-08002be10318}

Don't forget to update the computer policy on the workstation by running "gpupdate /force". Then log on as a non-admin user, and test! It worked for me with an annoying Konica Minolta bizhub C550 fax driver that was prompting my Win7 non-admin users for privileges when the logon script tried to install the driver for them. YMMV.




Good luck!

 

[djkc909]

Solution concurrence

Login script won't map printers on Windows 7

Scroll all the way to bottom to see solution.. same domain policy mentioned.

I'm about to add the template to a 2003 domain and test printer logon scripts on a 7 machine.

Let'cha know soon!

 

[haxcid]

Login script won't map printers on Windows 7

Scroll all the way to bottom to see solution.. same domain policy mentioned.

I'm about to add the template to a 2003 domain and test printer logon scripts on a 7 machine.

Let'cha know soon!

Set up a print server and gpo them to the machines. Really very simple to setup and work (in a domain)

 

[djkc909]

Solution roadblock - Can't add ADMX templates into 2003 GPO

OK, so there is an issue adding Windows 7/Server 2008 templates (ADMX files) into a 2003 domain GP.

Here is another article with additional solutions:

Add admx policy's into windows server 2003

 

[djkc909]

Solution evidence - straight from the Horse's mouth itself

The golden KB article:

The Point and Print User configuration policy is ignored by Windows 7, Windows Server 2008 R2 and Service Pack 2 release of Windows Vista, Windows Server 2008.
​

EXCERPT:

NOTE: Alternatively you can disable the driver installation warning messages and elevation prompts on computers that are running Windows 7, Windows Server 2008 R2 and Service Pack 2 release of Windows Vista and Windows Server 2008 by completely disabling the Point and Print Restrictions Policy. This setting disables the enhanced printer driver installation security of Windows 7 and Windows Server 2008 R2:

Computer Configuration -> Policies -> Administrative Templates -> Printers : Point and Print Restrictions
Setting: Disable

 

[djkc909]

Success!

Windows 7 machines are now mapping printers (and transparently installing their drivers) via user logon scripts in a Server 2003/2000 only domain environment (no 2008) without prompting the user or ignoring the scripts!

So basically, the solution was to copy the PolicyDefinitions folder from a local Windows 7 machine to the SysVol on the domain. Then use RSAT from the Windows 7 machine to connect to and manage the domain's newly "genetically engineered" GP.

Now I just need to figure out how to add 64-bit printer drivers to print shares on 2000 servers. Har har. NOT! (The servers are actually being taken out back with a baseball bat (couldn't find a sledge hammer)).

Btw, nice try HaxciD. It's not as simple a solution as your fail post suggested. But thank you for playing!

 

[glks]

a little more detail

Hey there djkc909,
congrats on getting that sorted.
I've seen a number of different solutions to UAC-related issues using W7 in W2K3 domains; here is the technet link with an explanation of what happens with logon scripts as a result of the use of limited / elevated tokens - Deploying Group Policy Using Windows Vista

I've found several resolutions

i. use launchapp.wsf to postpone the execution of a logon script (see the link above) - some users have reported difficulties with this implementation
ii. registry hack - After you turn on User Account Control in Windows Vista, programs may be unable to access some network locations
iii. your solution - which I've seen mentioned elsewhere.

I'm new to RSAT, & although I have read your resolution, I don't have enough experience to 'fill in the gaps'...

If you have the time & inclination, I'd really appreciate a dig out here - what are the steps needed to implement this solution?

Thanks

GLKS

 

[blamar]

There is a conflict with Windows VISTA and later OS's for UAC. Basically, the OS gets confused as to what token to use, especially if a user has local administrative rights on the system.

Below is an example on how to force the User token to be used in mapping drives.

USE G: "\\server\path" $user $persistent

Note 1: I have only been able to utilize KiXtart 2010 to do this effectively.

Note 2: You must create or update this registry key as well.
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections (RegDWORD) 1

Hope this helps.

 

[WindowsStar]

## P E A S E - N O T E ##

Modifying the registry key:
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections

Will lower your security in Windows Vista/Windows 7/Windows 8/8.1.

Use extreme caution! -WS