Environment variables in GPOs?

[fpbear]

I think this should be possible but I cannot find documentation on this
searching Google. Can I use an environment variable such as %programpath%
in the File System section of the Administrative Templates where I define
NTFS permissions? Would I simply define this variable in the System
Environment variable on the client?

[Roger Abell [MVP]]

Post by fpbear
I think this should be possible but I cannot find documentation on this
searching Google. Can I use an environment variable such as %programpath%
in the File System section of the Administrative Templates where I define
NTFS permissions? Would I simply define this variable in the System
Environment variable on the client?

Alas, no. This is not available.

[fpbear]

I'm a bit confused because I came across a newsgroup post that says
something of the nature, "Don't let Add File fool you in the File System
section of the GPO. You can type any path, including the use of environment
variables to define your path for the NTFS permissions." Is that
information wrong? Where can I find the authoritative Microsoft
documentation on this? Thanks

Post by Roger Abell [MVP]

Post by fpbear
I think this should be possible but I cannot find documentation on this
searching Google. Can I use an environment variable such as %programpath%
in the File System section of the Administrative Templates where I define
NTFS permissions? Would I simply define this variable in the System
Environment variable on the client?

Alas, no. This is not available.

[fpbear]

I read that User environment variables are not available because these do
not exist until the user logon, but that System level variables exist at
start, and can be used throughout GPOs. It would be nice if there was some
Microsoft KB article to clarify this. I come across discussion forum posts
showing people sprinkling these environment variables all over .adm
settings.

[fpbear]

I found the post I was referring to, written by Marin Marinov. I would like
to see if anyone can confirm what he says here about using environment
variables:

Yes, you can do this with group policy. Check out:
Computer configuration\Windows Settings\Security settings\File system
Don't let the "Add file..." menu option fool you - you can type whatever
path you like, use environment variables, add entire directory and
propagate permissions down the hierarchy.

Feel free to post again if you have any other concerns about this.

HTH

[Roger Abell [MVP]]

Post by fpbear
I found the post I was referring to, written by Marin Marinov. I would
like to see if anyone can confirm what he says here about using environment
Computer configuration\Windows Settings\Security settings\File system
Don't let the "Add file..." menu option fool you - you can type whatever
path you like, use environment variables, add entire directory and
propagate permissions down the hierarchy.
Feel free to post again if you have any other concerns about this.

OK, I am with you now. But notice you indicated use of system env
vars that you defined, and you did not restrict how you use them.

If you notice, the newer version of the Templates snapin automatically
translates to env vars when one browse-selects paths that start with an
env var Ex. %systemdrive%, %programfiles%, %alluserprofile%, etc.
And, a template defined with these does apply as expected.
I had not noticed this behavior changed with the GPO editor (as it has on
the W2k3 where I checked) as I tend to not use the Filesystem section in
GPOs, only in templates that are applied on demand rather than via GPO.

Now, as for general use of custom defined system env vars, such as
%systemdrive%\%customvar%\this
(which you would need to type / paste in, i.e. only the %systemdrive%
part would be automatically translated upon browse-select)
with use of Templates and of Configuration and Analysis templates,
although I find such a path can be defined in the template, and the
Config and Analyze sees no syntax problems on import, use of analyze
does not see differences for the path and use of configure does not
alter the permissions in the filesystem. (In other words, the behavior
is as thought the line is not present in the .inf template file.)
So, you need to test further for your specifics, and use a two level test
where first is as outlined just above and then second is with trial GPO
targetting example of each OS version you have in use.

[fpbear]

Thanks Roger. So if I understand right, custom System Variables will
resolve ok when used as part of the path for the File System section? As
for the use of these custom variable in other parts of the GPO, it needs to
be tested on a case by case basis?

May I suggest to Microsoft to publish a knowledge base article showing where
environment variables can be used in GPOs and where they cannot be used. It
reduces the need for hard-coding so it can be quite useful in certain
scenarios.

[Roger Abell [MVP]]

Post by fpbear
Thanks Roger. So if I understand right, custom System Variables will
resolve ok when used as part of the path for the File System section? As
for the use of these custom variable in other parts of the GPO, it needs
to be tested on a case by case basis?
May I suggest to Microsoft to publish a knowledge base article showing
where environment variables can be used in GPOs and where they cannot be
used. It reduces the need for hard-coding so it can be quite useful in
certain scenarios.

Actually, what I was saying is that I have not used custom system
env vars successfully, and I supplied an example that I know does
not work. So, I suggested that you test.

[fpbear]

Thanks Roger for the clarification. I wonder if we are doing something
non-standard because I can't find this info in the Microsoft documents.

We put the file system NTFS permissions in the GPO to lock down the client
systems. However the client system application can be installed in any path
specified during the Installshield.

I wonder if we are we doing something against best practices this way? Is
there a more efficient way of managing the file permissions via some other
group policy mechanism that wouldn't even need to use environment variables
for the unique client install paths?

Or do most professional apps just forget about using GPOs for this and set
the permissions once during install time? We like the GPO approach as it
gives flexibility and visibility to centrally manage the DACLs without
having to tweak with the client machines.

[Roger Abell [MVP]]

Post by fpbear
Thanks Roger for the clarification. I wonder if we are doing something
non-standard because I can't find this info in the Microsoft documents.
We put the file system NTFS permissions in the GPO to lock down the client
systems. However the client system application can be installed in any
path specified during the Installshield.
I wonder if we are we doing something against best practices this way? Is
there a more efficient way of managing the file permissions via some other
group policy mechanism that wouldn't even need to use environment
variables for the unique client install paths?
Or do most professional apps just forget about using GPOs for this and set
the permissions once during install time? We like the GPO approach as it
gives flexibility and visibility to centrally manage the DACLs without
having to tweak with the client machines.

The docs are fairly dark on many aspects of GPO processing,
and what we have been speaking of has not always been as it
now is. Also, it is my belief that most admins do not do anything
with the filesystem section.

I think that most apps just accept defaults when they define new
directories during install, and if they do not then they do a one
time set of the DACL.

I also, as you, like to use the capability to manage NTFS permissions.

However, I do not do this via GPO but via templates and application
of these via either secedit or the Config and Analysis snapin. But
then I am dealing with servers mostly. My reasons for this are basically
two. Once set there is little reason to set again, but that is what GPO
based use would do, at least whenever that GPO is reapplied, plus the
on disk ACLing can be changed and stay that way for extended times as
the GP process does not monitor this and reapply on need. The template
allows me to analyze to see if anything is different from the expected, and
this is something probably more or at least as important to me as is having
the NTFS ACLing restored to the defined. I mean, I cannot count on the
GPO keeping the NTFS ACLs as defined anyway. Then there is also the
overhead if the ACLing is over a large store and the GPO carries a number
of other policy settings so that it becomes more likely that it is seen as
changed and reapplied. If I use this via GPO, which I agree with you does
have advantages such as central visibility and one-to-many management,
then I start with the template (so I can still analyze) and import this into
a GPO used for this purpose, perhaps carrying other policy settings, so
that I pretty much know it is not being reapplied (needlessly?) when the
GPO is seen as changed due to edits of other settings (I can always force
a reapplication by an innocent edit to bump the GPO version).

I have never seen discussion of usage of filesystem section in a best
practices type doc. I consider use of some form of this capability to
be a good practice for servers. It is certainly of high value on anything
where compliance and auditing is part of the picture. There may be
discussions on this out there somewhere, but I cannot refer you.

Roger

[Pete Long]

You can manage Power options with GPP's

http://www.petenetlive.com/KB/Article/0000389.htm


Pete
http://www.petenetlive.com

Post by fpbear
I think this should be possible but I cannot find documentation on this
searching Google. Can I use an environment variable such as %programpath%
in the File System section of the Administrative Templates where I define
NTFS permissions? Would I simply define this variable in the System
Environment variable on the client?

Post by Roger Abell [MVP]
Alas, no. This is not available.

Post by fpbear
I'm a bit confused because I came across a newsgroup post that says
something of the nature, "Don't let Add File fool you in the File System
section of the GPO. You can type any path, including the use of environment
variables to define your path for the NTFS permissions." Is that
information wrong? Where can I find the authoritative Microsoft
documentation on this? Thanks

Post by fpbear
I read that User environment variables are not available because these do
not exist until the user logon, but that System level variables exist at
start, and can be used throughout GPOs. It would be nice if there was some
Microsoft KB article to clarify this. I come across discussion forum posts
showing people sprinkling these environment variables all over .adm
settings.

Post by fpbear
I found the post I was referring to, written by Marin Marinov. I would like
to see if anyone can confirm what he says here about using environment
Computer configuration\Windows Settings\Security settings\File system
Don't let the "Add file..." menu option fool you - you can type whatever
path you like, use environment variables, add entire directory and
propagate permissions down the hierarchy.
Feel free to post again if you have any other concerns about this.
HTH
--
Cheers,
Marin Marinov
MCT, MCSE 2003/2000/NT4.0,
MCSE:Security 2003/2000, MCP+I

Post by Roger Abell [MVP]
OK, I am with you now. But notice you indicated use of system env
vars that you defined, and you did not restrict how you use them.
If you notice, the newer version of the Templates snapin automatically
translates to env vars when one browse-selects paths that start with an
env var Ex. %systemdrive%, %programfiles%, %alluserprofile%, etc.
And, a template defined with these does apply as expected.
I had not noticed this behavior changed with the GPO editor (as it has on
the W2k3 where I checked) as I tend to not use the Filesystem section in
GPOs, only in templates that are applied on demand rather than via GPO.
Now, as for general use of custom defined system env vars, such as
%systemdrive%\%customvar%\this
(which you would need to type / paste in, i.e. only the %systemdrive%
part would be automatically translated upon browse-select)
with use of Templates and of Configuration and Analysis templates,
although I find such a path can be defined in the template, and the
Config and Analyze sees no syntax problems on import, use of analyze
does not see differences for the path and use of configure does not
alter the permissions in the filesystem. (In other words, the behavior
is as thought the line is not present in the .inf template file.)
So, you need to test further for your specifics, and use a two level test
where first is as outlined just above and then second is with trial GPO
targetting example of each OS version you have in use.

Post by fpbear
Thanks Roger. So if I understand right, custom System Variables will
resolve ok when used as part of the path for the File System section? As
for the use of these custom variable in other parts of the GPO, it needs to
be tested on a case by case basis?
May I suggest to Microsoft to publish a knowledge base article showing where
environment variables can be used in GPOs and where they cannot be used. It
reduces the need for hard-coding so it can be quite useful in certain
scenarios.

Post by Roger Abell [MVP]
Actually, what I was saying is that I have not used custom system
env vars successfully, and I supplied an example that I know does
not work. So, I suggested that you test.

Post by fpbear
Thanks Roger for the clarification. I wonder if we are doing something
non-standard because I can't find this info in the Microsoft documents.
We put the file system NTFS permissions in the GPO to lock down the client
systems. However the client system application can be installed in any path
specified during the Installshield.
I wonder if we are we doing something against best practices this way? Is
there a more efficient way of managing the file permissions via some other
group policy mechanism that wouldn't even need to use environment variables
for the unique client install paths?
Or do most professional apps just forget about using GPOs for this and set
the permissions once during install time? We like the GPO approach as it
gives flexibility and visibility to centrally manage the DACLs without
having to tweak with the client machines.

Post by Roger Abell [MVP]
The docs are fairly dark on many aspects of GPO processing,
and what we have been speaking of has not always been as it
now is. Also, it is my belief that most admins do not do anything
with the filesystem section.
I think that most apps just accept defaults when they define new
directories during install, and if they do not then they do a one
time set of the DACL.
I also, as you, like to use the capability to manage NTFS permissions.
However, I do not do this via GPO but via templates and application
of these via either secedit or the Config and Analysis snapin. But
then I am dealing with servers mostly. My reasons for this are basically
two. Once set there is little reason to set again, but that is what GPO
based use would do, at least whenever that GPO is reapplied, plus the
on disk ACLing can be changed and stay that way for extended times as
the GP process does not monitor this and reapply on need. The template
allows me to analyze to see if anything is different from the expected, and
this is something probably more or at least as important to me as is having
the NTFS ACLing restored to the defined. I mean, I cannot count on the
GPO keeping the NTFS ACLs as defined anyway. Then there is also the
overhead if the ACLing is over a large store and the GPO carries a number
of other policy settings so that it becomes more likely that it is seen as
changed and reapplied. If I use this via GPO, which I agree with you does
have advantages such as central visibility and one-to-many management,
then I start with the template (so I can still analyze) and import this into
a GPO used for this purpose, perhaps carrying other policy settings, so
that I pretty much know it is not being reapplied (needlessly?) when the
GPO is seen as changed due to edits of other settings (I can always force
a reapplication by an innocent edit to bump the GPO version).
I have never seen discussion of usage of filesystem section in a best
practices type doc. I consider use of some form of this capability to
be a good practice for servers. It is certainly of high value on anything
where compliance and auditing is part of the picture. There may be
discussions on this out there somewhere, but I cannot refer you.
Roger
Submitted via EggHeadCafe
LINQ executed in Parallel (PLINQ)
http://www.eggheadcafe.com/tutorials/aspnet/042c0b06-95f2-4944-9b52-46be6eeb3e7d/linq-executed-in-parallel-plinq.aspx