3

Here is a quickie that has had me scratching my head. Not a showstopper, so an answer isn’t urgent, but still.

I am trying to modify the logon scripts directory to include a login script. I have gone with Remote Desktop into my Domain Controller, and I am using a specially-created administrative account (something that wasn’t there when the domain was crafted) that is a part of the following groups:

  • Administrators (builtin)
  • Enterprise Admins
  • Domain Admins
  • Domain Users
  • Group Policy Creator Owners
  • Scan Operators
  • Schema Admins

Unfortunately, I cannot create any files within the following folder:

\\domain\SYSVOL\domain\{policy}\Machine\Scripts\Startup

And yet, if I log on using the original Administrator account which was used to set up the domain in the first place, I can! In fact, the original Admin account can do a lot that the (apparently) identical special-purpose superadmin account can’t. I mean, WTF?? Both accounts are absolutely identical in terms of the groups they belong to, as well as the organizational unit they are a part of, so I am unsure as to what the frakking difference is.

In fact, the only way to actually place a script there is to go through the drive itself:

C:\Windows\SYSVOL\sysvol\domain\Policies\{policy}\Machine\Scripts\Startup

1
  • Does the related GPO have any Security Filtering on it?
    – jscott
    Dec 10, 2013 at 19:34

8 Answers 8

4

Take ownership, preferably in gpmc.

4

It seems to work if you take the long way around... Browse to SYSVOL locally rather than using the "Show Files" shortcut, which is actually showing the UNC path (\SERVER...)

Go to: C:\Windows\SYSVOL\sysvol{yourdomain}\Policies{yourpolicy}\USER\Scripts\Logon

You can then drag and drop your login bat script into this folder, which will prompt you to perform the action as admin. Now when you click on the "Show Files" button in GPO you'll see your login script in the appropriate folder.

1
  • Works just fine this way. This is the correct answer, and it's the way I've always added scripts to the SYSVOL share. The rights are set the way they are by default for a reason, and it's to reduce the chances of you accidentally deleting or drag-moving something important while browsing your SYSVOL share. Nov 10, 2016 at 21:04
3

Just look at the default security settings for SYSVOL folder - for Domain Administrators there is no Modify rights:

enter image description here

And this is just a precaution from accidental deletion of important thing placed in this folder. As a Domain Administrator you will be able to add objects here but not delete them by default or even rename. But Domain Administrator has ownership for this folder as well as rights to manage permissions so nothing prevents you from just granting modify rights and rename/delete things. Below you can see default Advanced Permissions for Domain Administrators on SYSVOL folder:

enter image description here

I strongly recommend you to leave default permissions intact granting Modify right to your account only if you really need to modify something and then revoke this right again just to be on a safe side in the future.

1

NTFS File permissions and "Share" Permissions are two different things. When you go to the actual folder (c:\windows..Startup) you are using NTFS permissions, which you clearly have rights to.

When you, however, are trying to edit \domain\Sysvol..., you are going to one of the DCs which probably does grant access to the the account you are using.

In short, I would look at share permissions for the issue you are describing. Here is a KB article explaining the diff: http://technet.microsoft.com/en-us/library/cc754178.aspx

0

I've run into something similar a few times before.

The logon scripts directory may be inheriting some permissions that are preventing you from having full control. Take ownership of the directory with your Domain Admin account, set the permissions the way you like, and you should be able to add your scripts.

2
  • Grogan Jr - Both Enterprise Admins and Domain Admins have full control over the directories. Ownership, however, is set to Administrators (DOMAIN\Administrators); but this doesn’t explain why going through the file system works while going through the UNC path does not. Dec 8, 2013 at 19:08
  • Just also confirmed - taking ownership (to Domain Admins) does NOT work! FS file add still works, UNC file add is still prevented (“You need permission to perform this action” - no additional information given). Dec 8, 2013 at 19:12
0

Right-click Notepad and choose run as Administrator. Click File>Open and browse to the file you are trying to edit. It should now let you edit and save the file.

0

Just in case anyone else sees this, I found a workaround using plain old Administrator Command Prompt. No modifying permissions needed.

Copy the files you need to the local server, open CMD as Administrator, then copy the files using the copy \path\to\src \\domain\to\dest.

-6

Disable UAC on the host machine.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .