I have Vista RC1 jopined to a domain. I can login with my domain id, but my
drive maps don't show up. The drives are mapped through a vbscript deployed
via gpo. I can see the scripts in my recent files, and can run them manually
with success. I have checked and/or disabled every security setting I can
think of but still can't get this to work at login.

Anybody else had this problem? Any thoughts on how to fix?

Thanks.

Sorry about the delay. Here's an explanation of what you are seeing and the
official recomendation.

Explanation for what you are seeing and workaround :

By default Group policy service executes scripts in an elevated mode. There
are some scripts like 'Map network drives' that would need to be run in UAP
mode. In order to launch such scripts in a UAP context from an elevated
process, you can leverage the Task scheduler API. Here is a sample script:
Launchapp.wsf

Usage: cscript launchapp.wsf AppPath


If the user wants to run a GP logon script Script-UAP.wsf and requires it
to run in UAP context because it is mapping drives for the user then, create
another script Launch-Script-UAP.wsf which will just use the sample script
above to launch Script-UAP.wsf in UAP mode. Deploy this script as GP logon
script.

I'm attaching the LaunchApp sample script too.

This change will also be communicated via KB, Vista GP document or
otherwise.

Let me know if you still have issues.

Thanks,
Prashanth
Vista Remote File Systems.

"john" wrote in message
...
I have Vista RC1 jopined to a domain. I can login with my domain id, but my
drive maps don't show up. The drives are mapped through a vbscript
deployed
via gpo. I can see the scripts in my recent files, and can run them
manually
with success. I have checked and/or disabled every security setting I can
think of but still can't get this to work at login.

Anybody else had this problem? Any thoughts on how to fix?

Thanks.

Thanks for the reply.

Just to make sure I understand, I will know need to write two scripts, and
run them through the scheduler in order to do what a single script ran from a
gpo is supposed to do. I also think this is the whole point of having an AD
Domain, centralized, and simplification of, management.

This sounds like a bad flaw, not to mention security vulnerability. If a
hacker can get a bad script ran through the scheduler, you are hosed.

There has to be a better way of getting a domain member to get mapped
drives. Not to mention, is Vista going to break all of my gpos? If so, MS
just gave open source a huge advantage.

All I want is my current gpos to run properly in Vista, not work around them.

Thanks for any help you can provide.


"Prashanth Prahalad [MSFT]" wrote:

Sorry about the delay. Here's an explanation of what you are seeing and the
official recomendation.

Explanation for what you are seeing and workaround :

By default Group policy service executes scripts in an elevated mode. There
are some scripts like 'Map network drives' that would need to be run in UAP
mode. In order to launch such scripts in a UAP context from an elevated
process, you can leverage the Task scheduler API. Here is a sample script:
Launchapp.wsf

Usage: cscript launchapp.wsf AppPath


If the user wants to run a GP logon script Script-UAP.wsf and requires it
to run in UAP context because it is mapping drives for the user then, create
another script Launch-Script-UAP.wsf which will just use the sample script
above to launch Script-UAP.wsf in UAP mode. Deploy this script as GP logon
script.

I'm attaching the LaunchApp sample script too.

This change will also be communicated via KB, Vista GP document or
otherwise.

Let me know if you still have issues.

Thanks,
Prashanth
Vista Remote File Systems.

"john" wrote in message
...
I have Vista RC1 jopined to a domain. I can login with my domain id, but my
drive maps don't show up. The drives are mapped through a vbscript
deployed
via gpo. I can see the scripts in my recent files, and can run them
manually
with success. I have checked and/or disabled every security setting I can
think of but still can't get this to work at login.

Anybody else had this problem? Any thoughts on how to fix?

Thanks.

I have to agree with John on this issue. I've spent a lot of time perfect
and managing my GPO's and associated scripts so that my users receive the
proper drive and printer mappings. I would expect any NEW Microsoft
operating system, such as Vista, to adhere to the conventions in use and
defined on a Microsoft network operating system.

To think that deploying Vista would require me to re-engineer and re-script
all my GPO's is frustrating and would certainly be a HUGE strike in my
adoption of the new OS. After all, it's not like we're trying to pair Vista
with a non-Microsoft product! Vista should be able to take advantage of the
GPO's and scripts just as transparently and painlessly as XP.

Just for clarification: I am running Vista SC1 on a network with several
Windows 2003 servers and roughly a dozen or so GPO's.

"john" wrote:

Thanks for the reply.

Just to make sure I understand, I will know need to write two scripts, and
run them through the scheduler in order to do what a single script ran from a
gpo is supposed to do. I also think this is the whole point of having an AD
Domain, centralized, and simplification of, management.

This sounds like a bad flaw, not to mention security vulnerability. If a
hacker can get a bad script ran through the scheduler, you are hosed.

There has to be a better way of getting a domain member to get mapped
drives. Not to mention, is Vista going to break all of my gpos? If so, MS
just gave open source a huge advantage.

All I want is my current gpos to run properly in Vista, not work around them.

Thanks for any help you can provide.


"Prashanth Prahalad [MSFT]" wrote:

Sorry about the delay. Here's an explanation of what you are seeing and the
official recomendation.

Explanation for what you are seeing and workaround :

By default Group policy service executes scripts in an elevated mode. There
are some scripts like 'Map network drives' that would need to be run in UAP
mode. In order to launch such scripts in a UAP context from an elevated
process, you can leverage the Task scheduler API. Here is a sample script:
Launchapp.wsf

Usage: cscript launchapp.wsf AppPath


If the user wants to run a GP logon script Script-UAP.wsf and requires it
to run in UAP context because it is mapping drives for the user then, create
another script Launch-Script-UAP.wsf which will just use the sample script
above to launch Script-UAP.wsf in UAP mode. Deploy this script as GP logon
script.

I'm attaching the LaunchApp sample script too.

This change will also be communicated via KB, Vista GP document or
otherwise.

Let me know if you still have issues.

Thanks,
Prashanth
Vista Remote File Systems.

"john" wrote in message
...
I have Vista RC1 jopined to a domain. I can login with my domain id, but my
drive maps don't show up. The drives are mapped through a vbscript
deployed
via gpo. I can see the scripts in my recent files, and can run them
manually
with success. I have checked and/or disabled every security setting I can
think of but still can't get this to work at login.

Anybody else had this problem? Any thoughts on how to fix?

Thanks.

I cannot believe this has happened. I understand the UAC benefits, but was no
thought given to admins who have many many GPOs that simply cannot be easily
changed like this.

How far away from a _proper_ resolution is this issue?

Shane

"Jamfo" wrote:

I have to agree with John on this issue. I've spent a lot of time perfect
and managing my GPO's and associated scripts so that my users receive the
proper drive and printer mappings. I would expect any NEW Microsoft
operating system, such as Vista, to adhere to the conventions in use and
defined on a Microsoft network operating system.

To think that deploying Vista would require me to re-engineer and re-script
all my GPO's is frustrating and would certainly be a HUGE strike in my
adoption of the new OS. After all, it's not like we're trying to pair Vista
with a non-Microsoft product! Vista should be able to take advantage of the
GPO's and scripts just as transparently and painlessly as XP.

Just for clarification: I am running Vista SC1 on a network with several
Windows 2003 servers and roughly a dozen or so GPO's.

"john" wrote:

Thanks for the reply.

Just to make sure I understand, I will know need to write two scripts, and
run them through the scheduler in order to do what a single script ran from a
gpo is supposed to do. I also think this is the whole point of having an AD
Domain, centralized, and simplification of, management.

This sounds like a bad flaw, not to mention security vulnerability. If a
hacker can get a bad script ran through the scheduler, you are hosed.

There has to be a better way of getting a domain member to get mapped
drives. Not to mention, is Vista going to break all of my gpos? If so, MS
just gave open source a huge advantage.

All I want is my current gpos to run properly in Vista, not work around them.

Thanks for any help you can provide.


"Prashanth Prahalad [MSFT]" wrote:

Sorry about the delay. Here's an explanation of what you are seeing and the
official recomendation.

Explanation for what you are seeing and workaround :

By default Group policy service executes scripts in an elevated mode. There
are some scripts like 'Map network drives' that would need to be run in UAP
mode. In order to launch such scripts in a UAP context from an elevated
process, you can leverage the Task scheduler API. Here is a sample script:
Launchapp.wsf

Usage: cscript launchapp.wsf AppPath


If the user wants to run a GP logon script Script-UAP.wsf and requires it
to run in UAP context because it is mapping drives for the user then, create
another script Launch-Script-UAP.wsf which will just use the sample script
above to launch Script-UAP.wsf in UAP mode. Deploy this script as GP logon
script.

I'm attaching the LaunchApp sample script too.

This change will also be communicated via KB, Vista GP document or
otherwise.

Let me know if you still have issues.

Thanks,
Prashanth
Vista Remote File Systems.

"john" wrote in message
...
I have Vista RC1 jopined to a domain. I can login with my domain id, but my
drive maps don't show up. The drives are mapped through a vbscript
deployed
via gpo. I can see the scripts in my recent files, and can run them
manually
with success. I have checked and/or disabled every security setting I can
think of but still can't get this to work at login.

Anybody else had this problem? Any thoughts on how to fix?

Thanks.

You can get round this by making sure the user you log on with is NOT in the
Administrators group of the local machine. If you go to perform an activity
that needs Administrative status it will ask you for a user name and password
of a user that is.

"Shane" wrote:

I cannot believe this has happened. I understand the UAC benefits, but was no
thought given to admins who have many many GPOs that simply cannot be easily
changed like this.

How far away from a _proper_ resolution is this issue?

Shane

"Jamfo" wrote:

I have to agree with John on this issue. I've spent a lot of time perfect
and managing my GPO's and associated scripts so that my users receive the
proper drive and printer mappings. I would expect any NEW Microsoft
operating system, such as Vista, to adhere to the conventions in use and
defined on a Microsoft network operating system.

To think that deploying Vista would require me to re-engineer and re-script
all my GPO's is frustrating and would certainly be a HUGE strike in my
adoption of the new OS. After all, it's not like we're trying to pair Vista
with a non-Microsoft product! Vista should be able to take advantage of the
GPO's and scripts just as transparently and painlessly as XP.

Just for clarification: I am running Vista SC1 on a network with several
Windows 2003 servers and roughly a dozen or so GPO's.

"john" wrote:

Thanks for the reply.

Just to make sure I understand, I will know need to write two scripts, and
run them through the scheduler in order to do what a single script ran from a
gpo is supposed to do. I also think this is the whole point of having an AD
Domain, centralized, and simplification of, management.

This sounds like a bad flaw, not to mention security vulnerability. If a
hacker can get a bad script ran through the scheduler, you are hosed.

There has to be a better way of getting a domain member to get mapped
drives. Not to mention, is Vista going to break all of my gpos? If so, MS
just gave open source a huge advantage.

All I want is my current gpos to run properly in Vista, not work around them.

Thanks for any help you can provide.


"Prashanth Prahalad [MSFT]" wrote:

Sorry about the delay. Here's an explanation of what you are seeing and the
official recomendation.

Explanation for what you are seeing and workaround :

By default Group policy service executes scripts in an elevated mode. There
are some scripts like 'Map network drives' that would need to be run in UAP
mode. In order to launch such scripts in a UAP context from an elevated
process, you can leverage the Task scheduler API. Here is a sample script:
Launchapp.wsf

Usage: cscript launchapp.wsf AppPath


If the user wants to run a GP logon script Script-UAP.wsf and requires it
to run in UAP context because it is mapping drives for the user then, create
another script Launch-Script-UAP.wsf which will just use the sample script
above to launch Script-UAP.wsf in UAP mode. Deploy this script as GP logon
script.

I'm attaching the LaunchApp sample script too.

This change will also be communicated via KB, Vista GP document or
otherwise.

Let me know if you still have issues.

Thanks,
Prashanth
Vista Remote File Systems.

"john" wrote in message
...
I have Vista RC1 jopined to a domain. I can login with my domain id, but my
drive maps don't show up. The drives are mapped through a vbscript
deployed
via gpo. I can see the scripts in my recent files, and can run them
manually
with success. I have checked and/or disabled every security setting I can
think of but still can't get this to work at login.

Anybody else had this problem? Any thoughts on how to fix?

Thanks.