Quote:

Quote:

The best method is not to use RUNAS at all in the first place as it is insecure. See the FAQ Forum for ways to run scripts under admin privilegss in a secure way. Also, login tasks and admin tasks should be kept separated.



Well, then how would one suggest that I modify a Microsoft Office setting during login? I need to check and possibly modify the shared templates location and I am currently doing that during logon. To do that, I need to write a value to the User portion of the registry.

It's kind of a matter of style and that's something that's hard to search for.



Rule of thumb about this is....

Since all logon scripts run under what ever security rights that a user has.... putting admin level username/passwords in a logonscript is a bad thing to do, since everyone and their brother can read the logon script to see what the admin/password is. (this makes for bad security mojo!)

there are a few options avaliable...

1. the admin script
you run a script from a computer that has rights to make changes on remote computers... this script touches all computers on the network and makes the changes.
Pro: secure, using built in windows security, and some what easy to code.

Cons: will not make changes to computers that are not ON when the admin script goes to touch them.

2. client/server request/push approach..
the client (logonscript) requests a push from a server (admin script) to make changes on the local workstation.

Pros: still good security, and if left running long enough will reach 100% coverage of client pc's

Cons: can be difficult to code, more complex. Admin script will need to be left running for a period of time to assure 100% coverage.

3. runas from logon script...

Pros: fast and easy to code...
Cons: you compromise the username/password that you use for this task. There are ways to obscure the username/password in the logon script. Search for Kixcrypt.

Bryce