Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Script 1
- Thread starter liriom
- Start date
-
1
- #2
- Thread starter
- #3
- Thread starter
- #5
. Where will the script be located, the source for the copy operation? On a network share?
the logon script folder - C:\WINDOWS\SYSTEM32\GroupPolicy\User\Scripts\Logon
. Is this a Workgroup or Domain?
What does it matter? is a Domain
. Is this an occasional need, or do you intend to change the script frequently?
again, what does it matter? it might change or not.
the logon script folder - C:\WINDOWS\SYSTEM32\GroupPolicy\User\Scripts\Logon
. Is this a Workgroup or Domain?
What does it matter? is a Domain
. Is this an occasional need, or do you intend to change the script frequently?
again, what does it matter? it might change or not.
There are valid reasons for the question. For example, if you wanted your users logon script to always reflect any changes you made at a central file store on your Domain server, the logical place would be to precede the logon script with either an additional script in the Startup or perhaps the Shudown optional scripting locations.
Now my concern -- you do not have the security tokens during a Startup or Shutdown procedure to access your Domain server.
Second issue. If this is a Domain, enabling logon scripts is a Group Policy object that could easily be set for all users. If a Workgroup, the process is decidedly more complicated.
In general, the solution would be to have a generic logon scripting:
. layer one -- identical logon scripts, that essentially call:
. layer two -- a script to copy over the existing %userprofile% logon script; and then would call:
. layer three -- what will be the finally executed logon script. Because scripting wait states and recursion are a little tedious in WSH scripting, I would use .CMD files with the START /xxxx paramter settings to handle all three layers.
Now my concern -- you do not have the security tokens during a Startup or Shutdown procedure to access your Domain server.
Second issue. If this is a Domain, enabling logon scripts is a Group Policy object that could easily be set for all users. If a Workgroup, the process is decidedly more complicated.
In general, the solution would be to have a generic logon scripting:
. layer one -- identical logon scripts, that essentially call:
. layer two -- a script to copy over the existing %userprofile% logon script; and then would call:
. layer three -- what will be the finally executed logon script. Because scripting wait states and recursion are a little tedious in WSH scripting, I would use .CMD files with the START /xxxx paramter settings to handle all three layers.
- Thread starter
- #7
You are making this out to be more complicated than it is. I know what you are saying, basically, I'm just being lazy and don't want to install a particular script into a 100 computers, because of the level of permissions that we got set in the computers, it would take me a long time to do.
This particular script might change once a year, if that!
All I wanted was the code to write a script that would set a group policy, independent of the domain and server side scripts, that would copy a bat file into the specified folder for the pc to run the bat file every time an user logs into the machine.
This is a dead issue as I already did it the long way.
This particular script might change once a year, if that!
All I wanted was the code to write a script that would set a group policy, independent of the domain and server side scripts, that would copy a bat file into the specified folder for the pc to run the bat file every time an user logs into the machine.
This is a dead issue as I already did it the long way.
- Status
Similar threads
