This isnt quite scripting, but scripting people will get what i mean..

I am using the good old "for /f" along with xcacls.vbs to set home
drive and profile permisisons, but have always used it setting all the
way down the tree (ie /s /t) .... as you can imagine this takes a very
long time for large migrations, as it sets permissions on every file
instead of using inhertiance (which is obviously quicker and cleaner)

In the Windows Explorer GUI, i can simply set the permissions at the
top level, and inhertiance will take care of the rest of the tree.

However, if i set the permissions at just the top level using
xcacls.vbs, the permissions dont flow through to the rest of the
structure, even though inhertiance is enabled. (so using the
"inhertitance enabled" fature of xcacls is of no use, as its already
on!)

Im clearly missing something here, there must be a way to set it once
at the top with xcacls and have it flow through cvorrectly - can
anyone assist?

"verukins" <verukins@hotmail.com> wrote in message
news:1192016315.276768.242920@v3g2000hsg.googlegro ups.com...
> This isnt quite scripting, but scripting people will get what i mean..
>
> I am using the good old "for /f" along with xcacls.vbs to set home
> drive and profile permisisons, but have always used it setting all the
> way down the tree (ie /s /t) .... as you can imagine this takes a very
> long time for large migrations, as it sets permissions on every file
> instead of using inhertiance (which is obviously quicker and cleaner)
>
> In the Windows Explorer GUI, i can simply set the permissions at the
> top level, and inhertiance will take care of the rest of the tree.
>
> However, if i set the permissions at just the top level using
> xcacls.vbs, the permissions dont flow through to the rest of the
> structure, even though inhertiance is enabled. (so using the
> "inhertitance enabled" fature of xcacls is of no use, as its already
> on!)
>
> Im clearly missing something here, there must be a way to set it once
> at the top with xcacls and have it flow through cvorrectly - can
> anyone assist?

I cannot be sure, but I think I have done something similar with cacls.EXE
(the latest version as found in XP and 2k3). I think, however, that it may
depend on whether or not the folder structure already is setup with "dynamic
inheritence" of permissions.

Anyway, I'd suggest you try setting the permission on one folder using
cacls.exe, and see if the change is inherited.

If it isn't, try it on another folder after having used the GUI to replicate
permissions to see if that results in permission inheritance.

/Al

Hey Al,
nup, neither of them work, setting the perm using xacls
(or icacls for that matter) dont seem to inherit, even when
inheritance is turned on or you re-enable inheritance after setting
the top level.... hence the message to this group.

I'm not sure about icacls (.exe?) or xacls (.exe?), but I did mention
cacls.exe. Did you specifically try what I suggested, i.e.:

I cannot be sure, but I think I have done something similar with cacls.EXE
(the latest version as found in XP and 2k3). I think, however, that it may
depend on whether or not the folder structure already is setup with "dynamic
inheritence" of permissions.

Anyway, I'd suggest you try setting the permission on one folder using
cacls.exe, and see if the change is inherited.

If it isn't, try it on another folder after having used the GUI to replicate
permissions to see if that results in permission inheritance.

/Al

"verukins" <verukins@hotmail.com> wrote in message
news:1192342966.164054.237250@i38g2000prf.googlegr oups.com...
> Hey Al,
> nup, neither of them work, setting the perm using xacls
> (or icacls for that matter) dont seem to inherit, even when
> inheritance is turned on or you re-enable inheritance after setting
> the top level.... hence the message to this group.
>

ok so...

cacls.exe is the old school version (http://support.microsoft.com/kb/
834721)

xcacls.exe was the next iteration

xcacls.vbs was the updated version that popped up a few years ago and
addressed many of the issues by the previous iterations (http://
support.microsoft.com/kb/825751)

icacls is the version included in vista.... (http://
technet2.microsoft.com/windowsserver2008/en/library/403edfcc-328a-479d-
b641-80c290ccf73e1033.mspx?mfr=true)

i do thank you for your suggestions al, but going back to an outdated,
buggy version of a tool that has been updated a number of times, IMO,
is not the way to go.

The change is not inherited when setting with any of the above command
line tools, without switching /t, which causes the long delays and
processing of every file anyway.

Im sure it's just a trial and error thing, so i'll put in the required
time - i was just hoping that people that have run into this before
(there will be plenty of them) may have commented on this.

"verukins" <verukins@hotmail.com> wrote in message
news:1192452041.423719.321680@e34g2000pro.googlegr oups.com...
> ok so...
>
> cacls.exe is the old school version (http://support.microsoft.com/kb/
> 834721)
>
> xcacls.exe was the next iteration
>
> xcacls.vbs was the updated version that popped up a few years ago and
> addressed many of the issues by the previous iterations (http://
> support.microsoft.com/kb/825751)
>
> icacls is the version included in vista.... (http://
> technet2.microsoft.com/windowsserver2008/en/library/403edfcc-328a-479d-
> b641-80c290ccf73e1033.mspx?mfr=true)

I was not aware of the version in vista being called icacls, but...

> i do thank you for your suggestions al, but going back to an outdated,
> buggy version of a tool that has been updated a number of times, IMO,
> is not the way to go.


cacls.exe was indeed the name of the original version. xcacls.exe was NOT
the next iteration, or, at least, was not the next iteration outside of a
quasi-official resource kit package. cacls.exe is, however, the name of the
delivered-in-the-windows-box version on xp and 2k3, and it has been my
understanding that they should logically supercede xcacls.exe from any
earlier o/s or resource kit that predates the version of NTFS in xp and 2k3.

That said, and buggy or not, if it had resolved your issue, then it might
have been worth considering. Since it doesn't (as I can only assume that you
tried that particular version on my suggestion), then all is moot.

> The change is not inherited when setting with any of the above command
> line tools, without switching /t, which causes the long delays and
> processing of every file anyway.
>
> Im sure it's just a trial and error thing, so i'll put in the required
> time - i was just hoping that people that have run into this before
> (there will be plenty of them) may have commented on this.

I have always looked for ways of avoiding the problem, including permitting
folders only one - when they are created. I know when we moved to 2k3 we
were advised that, once we had used that O/S to set permissions through the
gui interface, we should studiously avoid doing so with w2k. from my reading
of the subject there seems a lot going on under the hood to hide the fact
that NTFS itself has changed, now including dynamic inheritance - even
though, as you have found out, it doesn't always work out like you'd expect.

/Al