Re: Login Script Problems

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" <john@discussions.microsoft.com> wrote in message
> > > news:C72E2C0F-900F-49AB-B145-D6E98B581B0F@microsoft.com...
> > > >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" <john@discussions.microsoft.com> wrote in message
> > > > news:C72E2C0F-900F-49AB-B145-D6E98B581B0F@microsoft.com...
> > > > >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.
> > > >
> > > >
> > > >