Vista - UAC problem with login scripts

It looks like I am not alone on this one, however none of the solutions
suggested have worked. As an administrator drives are not mapped properly
when logging on, the official explanation for which is here, under the
heading 'Group Policy Scripts can fail due to User Account Control':

http://technet2.microsoft.com/Window....mspx?mfr=true

Disabling User Account Control has been suggested but this is not really an
acceptable solution, nor is disabling 'Run all administrators in Admin
Approval Mode' under Local Security Policy as it somewhat defeats the point
of UAC.

We have attempted the solution described in the article with no luck. I read
somewhere else (I forget where exactly) that the guide at the above URL is in
fact inaccurate and that the field where you specify 'logon.bat' has to be
the fully qualified path, for example \\SYSVOL\etc.\logon.bat but firstly, I
don't know how to obtain that specific address and secondly, we do not use a
'logon.bat', although perhaps the second point answers the first. On the
Profile tab in all our users' Properties the 'Logon script' field is left
blank as the scripts that run at logon are determined by Group Policy. Does
this mean that the given solution will not work for us?

There are three sets of scripts that run if you are an administrator: one
set that is run for all users, one set that is run for staff, then one set
that is run for administrators. The script that runs for all users renames
the user's home drive to something more friendly than the default of the
absolute path, and this fails with an error. Then there is a drive mapping
script at the staff level which does not work but gives no error. Finally,
the script at administrator level should map further drives, but this fails
and gives the same error as the drive renaming script.

It's all very confusing. Cheers in advance to anyone that can help

Not sure if it will work, but worth a try...set the following.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1

Josh
http://windowsconnected.com


"Ben" <Ben@discussions.microsoft.com> wrote in message
news:52E93864-BEEA-49C8-9CB5-45A0AE360380@microsoft.com...
> It looks like I am not alone on this one, however none of the solutions
> suggested have worked. As an administrator drives are not mapped properly
> when logging on, the official explanation for which is here, under the
> heading 'Group Policy Scripts can fail due to User Account Control':
>
> http://technet2.microsoft.com/Window....mspx?mfr=true
>
> Disabling User Account Control has been suggested but this is not really
> an
> acceptable solution, nor is disabling 'Run all administrators in Admin
> Approval Mode' under Local Security Policy as it somewhat defeats the
> point
> of UAC.
>
> We have attempted the solution described in the article with no luck. I
> read
> somewhere else (I forget where exactly) that the guide at the above URL is
> in
> fact inaccurate and that the field where you specify 'logon.bat' has to be
> the fully qualified path, for example \\SYSVOL\etc.\logon.bat but firstly,
> I
> don't know how to obtain that specific address and secondly, we do not use
> a
> 'logon.bat', although perhaps the second point answers the first. On the
> Profile tab in all our users' Properties the 'Logon script' field is left
> blank as the scripts that run at logon are determined by Group Policy.
> Does
> this mean that the given solution will not work for us?
>
> There are three sets of scripts that run if you are an administrator: one
> set that is run for all users, one set that is run for staff, then one set
> that is run for administrators. The script that runs for all users renames
> the user's home drive to something more friendly than the default of the
> absolute path, and this fails with an error. Then there is a drive mapping
> script at the staff level which does not work but gives no error. Finally,
> the script at administrator level should map further drives, but this
> fails
> and gives the same error as the drive renaming script.
>
> It's all very confusing. Cheers in advance to anyone that can help

Result! Cheers for that.

This has fixed the problem, a couple of questions though, if you have time
to answer them...

1. What exactly does this do?
2. How come I've not seen this suggested anywhere else and would it not work
for others who may have instead gone through the more laborious steps
described on the page I linked to?
3. Are there any drawbacks to setting this registry key?

Thanks again

Ben

"Josh Phillips" wrote:

>
> Not sure if it will work, but worth a try...set the following.
>
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
> EnableLinkedConnections =(dword)1
>
> Josh
> http://windowsconnected.com
>
>
> "Ben" <Ben@discussions.microsoft.com> wrote in message
> news:52E93864-BEEA-49C8-9CB5-45A0AE360380@microsoft.com...
> > It looks like I am not alone on this one, however none of the solutions
> > suggested have worked. As an administrator drives are not mapped properly
> > when logging on, the official explanation for which is here, under the
> > heading 'Group Policy Scripts can fail due to User Account Control':
> >
> > http://technet2.microsoft.com/Window....mspx?mfr=true
> >
> > Disabling User Account Control has been suggested but this is not really
> > an
> > acceptable solution, nor is disabling 'Run all administrators in Admin
> > Approval Mode' under Local Security Policy as it somewhat defeats the
> > point
> > of UAC.
> >
> > We have attempted the solution described in the article with no luck. I
> > read
> > somewhere else (I forget where exactly) that the guide at the above URL is
> > in
> > fact inaccurate and that the field where you specify 'logon.bat' has to be
> > the fully qualified path, for example \\SYSVOL\etc.\logon.bat but firstly,
> > I
> > don't know how to obtain that specific address and secondly, we do not use
> > a
> > 'logon.bat', although perhaps the second point answers the first. On the
> > Profile tab in all our users' Properties the 'Logon script' field is left
> > blank as the scripts that run at logon are determined by Group Policy.
> > Does
> > this mean that the given solution will not work for us?
> >
> > There are three sets of scripts that run if you are an administrator: one
> > set that is run for all users, one set that is run for staff, then one set
> > that is run for administrators. The script that runs for all users renames
> > the user's home drive to something more friendly than the default of the
> > absolute path, and this fails with an error. Then there is a drive mapping
> > script at the staff level which does not work but gives no error. Finally,
> > the script at administrator level should map further drives, but this
> > fails
> > and gives the same error as the drive renaming script.
> >
> > It's all very confusing. Cheers in advance to anyone that can help
>
>

Glad that worked for you Ben,

Not sure why others haven't tried this,but probably because it isn't well
known. We orginally had a problem where drives weren't available when we
would elevate UAC prompts and this key was the result of a DCR we
filed....hence how I know about it.

I think I will make a blog post about this to heighten awareness....thanks
for the reminder.


josh
http://windowsconnected.com



"Ben" <Ben@discussions.microsoft.com> wrote in message
news:277D60E8-C60C-4C00-A3EF-30C9E472DC7F@microsoft.com...
> Result! Cheers for that.
>
> This has fixed the problem, a couple of questions though, if you have time
> to answer them...
>
> 1. What exactly does this do?
> 2. How come I've not seen this suggested anywhere else and would it not
> work
> for others who may have instead gone through the more laborious steps
> described on the page I linked to?
> 3. Are there any drawbacks to setting this registry key?
>
> Thanks again
>
> Ben
>
> "Josh Phillips" wrote:
>
>>
>> Not sure if it will work, but worth a try...set the following.
>>
>> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
>> EnableLinkedConnections =(dword)1
>>
>> Josh
>> http://windowsconnected.com
>>
>>
>> "Ben" <Ben@discussions.microsoft.com> wrote in message
>> news:52E93864-BEEA-49C8-9CB5-45A0AE360380@microsoft.com...
>> > It looks like I am not alone on this one, however none of the solutions
>> > suggested have worked. As an administrator drives are not mapped
>> > properly
>> > when logging on, the official explanation for which is here, under the
>> > heading 'Group Policy Scripts can fail due to User Account Control':
>> >
>> > http://technet2.microsoft.com/Window....mspx?mfr=true
>> >
>> > Disabling User Account Control has been suggested but this is not
>> > really
>> > an
>> > acceptable solution, nor is disabling 'Run all administrators in Admin
>> > Approval Mode' under Local Security Policy as it somewhat defeats the
>> > point
>> > of UAC.
>> >
>> > We have attempted the solution described in the article with no luck. I
>> > read
>> > somewhere else (I forget where exactly) that the guide at the above URL
>> > is
>> > in
>> > fact inaccurate and that the field where you specify 'logon.bat' has to
>> > be
>> > the fully qualified path, for example \\SYSVOL\etc.\logon.bat but
>> > firstly,
>> > I
>> > don't know how to obtain that specific address and secondly, we do not
>> > use
>> > a
>> > 'logon.bat', although perhaps the second point answers the first. On
>> > the
>> > Profile tab in all our users' Properties the 'Logon script' field is
>> > left
>> > blank as the scripts that run at logon are determined by Group Policy.
>> > Does
>> > this mean that the given solution will not work for us?
>> >
>> > There are three sets of scripts that run if you are an administrator:
>> > one
>> > set that is run for all users, one set that is run for staff, then one
>> > set
>> > that is run for administrators. The script that runs for all users
>> > renames
>> > the user's home drive to something more friendly than the default of
>> > the
>> > absolute path, and this fails with an error. Then there is a drive
>> > mapping
>> > script at the staff level which does not work but gives no error.
>> > Finally,
>> > the script at administrator level should map further drives, but this
>> > fails
>> > and gives the same error as the drive renaming script.
>> >
>> > It's all very confusing. Cheers in advance to anyone that can help
>>
>>