Vista - Vista/7 permissions for script?

I have almost no experience with Vista but
recently started testing my software and
scripts on Win7 RC. I'm confused by the
permissions issues and wanted to ask how other
people are handling them. Examples of problems
even when running as an admin:

* I can write a set of "Open With X" Registry
keys under HKCR\* in Regedit, but can't do it
programmatically from software that admin is
running.

* I wrote an HTA for managing services via WMI
but access is denied when using the HTA to
change services. Admin can change settings
directly through the services applet, but not through
the HTA. And there's no "Run as Admin." on the
HTA context menu.

* I've found that there are even some values in
the Registry that Admin. seems to be completely
denied access to.

I was thinking that it might be worthwhile to write
an ActiveX DLL for file operations and Registry edits
that conveniently incorporates the ability to set
permissions in order to allow a given operation -- in
other words, render permissions altogether "transparent".
That could be convenient for scripting, but if the DLL
does not have permission to do its work when run from
a script then it's not of much value. Is there any way
around this mess without needing to resort to command
line or specifically selecting to run a given process as
admin.? (I didn't think to check whether VBS files have
a "Run as Admin." context menu, but even if they do that's
not an adequate solution.) Is script in Vista/7 doomed to
be limited to what admin. can do without getting a UAC
prompt?

This is not even getting into how to manage if I
were to run as a normal "user". I'm just trying to
figure out how to have full permission to use a
Vista/7 when I'm admin.!

A similar problem has been designed into some
Linux systems, whereby root is not really root and
needs to give itself "superuser" rights. But once one
is SU there are no limitations. On Vista/7 I was under
the impression that running this command line was
equivalent:

Net user administrator activate:yes

But as far as I can see, that still doesn't give me
the full control that I have naturally on Win9x or
as admin on WinXP.

This code works in Windows 7

This code goes in the beginning of your script.

If WScript.Arguments.Count = 0 Then
Set Objshell = CreateObject("Shell.Application")
Objshell.ShellExecute "wscript.exe", """" & _
WScript.ScriptFullName & """" &_
" RunAsAdministrator", , "runas", 1
Else

--
Windows XP and Vista Tweaks
------------------------------------------------------------
www.paulsxp.com
------------------------------------------------------------
Windows XP and Vista Help Forum
------------------------------------------------------------
www.paulsxp.com/forum
------------------------------------------------------------
Live Computer Help and Chat
------------------------------------------------------------
www.paulsxp.com/livesupport.html
------------------------------------------------------------


"mayayana" <mayaXXyana@xxxxxx> wrote in message
news:ukgwq8x1JHA.6056@xxxxxx

Thanks. So all scripts have to be run by a starter
script? If you're putting that into the running script,
how do you deal with multiple instances? Is some
part of the wscript.exe command string ending up
as part of the script's own command string.... and
that's how you recognize a recursive call?

So, if I understand this right, to accomodate all
systems one would need to first check for Windows
6+. (ShellExecute is not available on Win9x and I
don't know what effect " RunAsAdministrator" would
have.) Then, in order to accept arguments, the script
would need to somehow build a new command? I'm
thinking that, say, a file dropped onto a script would
result in a wscript.argument and therefore block the
script from running.

I'm wondering if it might make sense to actually write
a small EXE that takes charge of the .vbs extension
and then handles the operation of running a given script
as admin. with any command line kept intact. That's
not a very attractive option, but it appears that otherwise
a fairly large prepend has to be added to all scripts.

Can you give me an example of one of your script so I can test it.
That's not a starter script I put that code in all my Vista scripts.
--
Windows XP and Vista Tweaks
------------------------------------------------------------
www.paulsxp.com
------------------------------------------------------------
Windows XP and Vista Help Forum
------------------------------------------------------------
www.paulsxp.com/forum
------------------------------------------------------------
Live Computer Help and Chat
------------------------------------------------------------
www.paulsxp.com/livesupport.html
------------------------------------------------------------


"mayayana" <mayaXXyana@xxxxxx> wrote in message
news:eo#5wsz1JHA.4756@xxxxxx

Is there documentation for this? This is the first time I've seen this. I
cannot find documentation for the "runas" verb. I assume it is only
supported on Vista, Windows Server 2008, and Win 7. Also, is the parameter
"RunAsAdministrator", "RunAsAdmin" (as you posted earlier), or "uac" as in
this link:

http://support.microsoft.com/kb/958149/EN-US

Finally, I assume you could use cscript in place of wscript, but I see no
way to do this from the command line.

I run all scripts from a command prompt and when I need elevated privileges
I launch cmd.exe from a shortcut on my desktop by right clicking the
shortcut and selecting "Run as administrator".

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--
"PaulM" <NONO@xxxxxx> wrote in message
news:%23LPfrJz1JHA.1900@xxxxxx

You can use, "uac", "RunAsAdmin" or "RunAsAdministrator"

I have never tried it with cscript, by I will give it a test.

--
Windows XP and Vista Tweaks
------------------------------------------------------------
www.paulsxp.com
------------------------------------------------------------
Windows XP and Vista Help Forum
------------------------------------------------------------
www.paulsxp.com/forum
------------------------------------------------------------
Live Computer Help and Chat
------------------------------------------------------------
www.paulsxp.com/livesupport.html
------------------------------------------------------------


"Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
message news:eCZfqf01JHA.1096@xxxxxx

I understood that. I was just thinking that it
might be worthwhile to have a starter script,
or starter EXE, because it seems that a full
version of your code would really need to test
for OS version and find a way to send on
any command string parameters.

I'm not sure what you mean by a sample
of one of my scripts. You mean in regard to
the arguments issue? I use a lot of scripts
that are drag-drop. I actually leave quite a few
on my Desktop. I guess an example of a good
test script would be one that tests two things
at once -- an argument getting through and a write
to HKLM. Here's a simple script that, when a file
is dropped onto it, should write the file's path to
a new value called TestArgument. The file path
does not have to be arguments(0). It could be,
say, arguments(2). But somehow that would need
to be knowable beforehand.

Dim SH, Arg, sVal
If WScript.Arguments.Count = 0 Then WScript.Quit

sVal = WScript.Arguments(0)
Set SH = CreateObject("WScript.Shell")
SH.RegWrite "HKLM\Software\Microsoft\Windows\CurrentVersion\TestArgument",
sVal, "REG_SZ"
Set SH = Nothing

>privilegesYou never use drag-drop scripts or HTAs?
Or do you start an HTA from command line
in cmd.exe?

Is it really true that Vista/7 simply will not allow
anyone, under any conditions, total control over
the system? That implies quite a radical transition
in the Windows product, whereby the PC owner
is really only a guest who happens to own the
hardware, with Microsoft themselves maintaining
the software -- and the job of admin being simply
to oversee employee restrictions.
I've noticed that a lot of network
admin types like to operate DOS-style/mouse-
free, but a big part of VBS is the ability to use
it in Explorer, with mouse and GUI options. If Vista/7
is as restrictive as it seems then I wonder about
the usability of the WSH at all, at least for the
sorts of things that I use it for.

This is C++ .NET code, but it shows the underlying mechanics:
http://blogs.msdn.com/vistacompatteam/default.aspx?p=3

There's a runas entry underneath HKCR\exefile\shell on Win7 (and I presume
Vista). This works fine from a commandline as well as from a GUI, and I've
successfully used the same tool to run an executable from PowerShell using
the System.Diagnostics.Process class. A couple of caveats:

+ as-is, this only works against executables - and only because there is a
runas explicitly defined.

+ This makes it a bit difficult to pass arguments if trying something from
WSH/HTA, since Shell.Application doesn't expose a way to add arguments such
as a script name or options. It's not possible to use
System.Diagnostics.Process without some wrapup, since you need to invoke a
static method.

+ A process started programmatically has the same behavior as you get with
anything run using DDE-style invocation (e.g., getting launch information
from using registry associations). In other words, you don't have a
connected pipeline, you get a new window even for console executables, and
you don't have drag-and-drop from the non-elevated desktop.

"Richard Mueller [MVP]" <rlmueller-nospam@xxxxxx> wrote in
message news:eCZfqf01JHA.1096@xxxxxx

This is what I was thinking would be useful; basically a Windows admin
"exec" script. It would correctly replicated all arguments, quoting as
necessary. Then you could simply use something like this in a shortcut's
command:

adminexec.vbs <targetscriptpath>

and adminexec would invoke targetscriptpath with the appropriate elevation
request, correct application explicitly set to launch it, and arguments
appended.

"mayayana" <mayaXXyana@xxxxxx> wrote in message
news:#ZmkYl21JHA.4632@xxxxxx