| T O P I C R E V I E W |
| aval |
Posted - 07/30/2012 : 3:40:21 PM
When I want to assign a startup or logon script in Windows 2003, I create the script - startup.bat or logon.vbs - and then, inside the GPO, copy it, paste it into the location that appears when you click "Show Files" as illustrated here:
http://www.fr3d.org/dev/random/screenshots/clippings/lando/Group_Policy_Management_Editor_28792.png
I then click on the "Add" button, "Browse" and the script appears (without me needing to browse) and I add it.
On my Windows 2008 R2 SP1 domain controller, I notice:
1) I cannot paste it into the folder that appears when I click "Show Files"
2) If I paste into the corresponding location using Windows Explorer (and even after right-clicking on "Run As Administrator"), I can paste but when I add, the entire path is shown - instead of the name of the file only.
So it would be something like:
C:\Windows\Sysvol\Sysvol\mydomain.local\GUID\machine\scripts\startup
This is what I see in Windows 2003 (which is correct"):
http://www.petri.co.il/images/logon_script_gpo_14.gif
*
What's going on here? Works perfectly in W2K3, doesn't in W2K8.
Also, if I attach the script on the W2K3 domain controller, allow replication to take place, and then look at the GPO on the W2K8 machine, I just see the name of the script in the appropriate location.
If I attach the script on the W2K8 DC, on the W2K3 DC, I'll see the entire path as well.
Is this normal? |
| 6 L A T E S T R E P L I E S (Newest First) |
| Playwell |
Posted - 08/01/2012 : 02:05:57 AM
Am indeed glaring suspciously to UAC
You are right for permissions on 2003. |
| aval |
Posted - 07/31/2012 : 6:11:26 PM
But is the discrepancy between W2K3 and W2K8 normal?
I'm guessing it might have to do something with UAC.
Permissions would have to be OK for it to function correctly on W2K3?
Right? Or wrong? |
| sixdoubleo |
Posted - 07/31/2012 : 10:52:32 AM
quote:
Originally posted by Playwell
For the most part i agree with you Dave, but there is something to say to keep the scripts and the GPO together so you the only thing you'd have to manage is the GPO it self. On the technical side of your implementation, especially for laptops we have had issues in the past when they're offline or have a slow connection.
Logon time was 30 seconds longer with scripts stored in the netlogon share.
Is the reason for your logon delay in Netlogon vs stored with the GPO because when stored with the GPO, the laptop gets a cached copy of the script? In that case I could see a benefit.
The reason I personally don't like Microsoft's design is because it assumes that a script is unique to the GPO that invokes it. It makes the random GUID name of that GPO important and I feel it isn't It's a very simplistic assumption that doesn't take into account highly-managed script implementations in large environments.
For instance...say you have a master workstation management script called "WSMgmt.vbs". This script is invoked hourly via a scheduled task. When invoked in this behind-the-scenes mode it does some very lightweight checks. It might make sure the virus scanner service is running and current, that the company fonts are installed on the machine, collect installed software list, grab a list of running processes from the machine and store them somewhere, perform a CPUZ report and store it....whatever. But either way, it runs in a fairly stealth mode and it doesn't do anything that would disrupt the user.
But when run during startup, as a startup script, it might do all the above things plus perform more extensive operations such as installing updates to products like Java, Adobe Reader, upgrading .NET Framework on computers in a certain group, etc.
You might have multiple GPO's to invoke this script in different operation modes. A laptop mode, a local mode, a VPN mode, etc.
Microsoft's design would have you making multiple copies of this script and storing under the GUID for each GPO, creating a management nightmare for a script of this complexity. In the example above you'd break out of this model and store the scripts centrally..pointing the GPO's to them.
There needs to be a "Common" folder for scripts or other files that are shared between GPO's. Since that isn't there, Netlogon is the closest thing.
Rant Over ;)
|
| Playwell |
Posted - 07/31/2012 : 06:59:40 AM
For the most part i agree with you Dave, but there is something to say to keep the scripts and the GPO together so you the only thing you'd have to manage is the GPO it self. On the technical side of your implementation, especially for laptops we have had issues in the past when they're offline or have a slow connection.
Logon time was 30 seconds longer with scripts stored in the netlogon share. |
| sixdoubleo |
Posted - 07/31/2012 : 02:24:38 AM
I've never understood why Microsoft designed it this way. It's a DUMB design. You don't have to follow their crappy design.
I create all scripts myself and store them in \\MYDOMAIN\Netlogon.
Create GPO, Scripts, point to above....done. That whole "GUID" thing is silly for scripts, which, in my opinion, are a more permanent fixture.
(FWIW, I get why it's set up that way....just really goofy that the GUID of the GPO assigning the script determines the folder the script is stored in. In my opinion, all the scripts should go into a meaningful structure you create) |
| aval |
Posted - 07/30/2012 : 3:52:03 PM
I cannot delete the file either (in the "Show Files" location) even after opening the GPMC with the "Run as Admin" option.
Have to do this via Windows Explorer where I can confirm I want to delete and then delete successfully.
In GPMC, I get this message:
"You need permission to perform this action.
You require permission from Administrators to make changes to this file"
"Try Again" and "Cancel" are the only options. Clicking Try Again simply displays the same error message.
*
No, I am not using (nor do I normally use) the default domain admin account.
|
|
|
