Environment variables in GPOs?
fpbear
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]
"fpbear" <dontse...@nospam.com> wrote in message
news:%23t2bT9r...@TK2MSFTNGP05.phx.gbl...
fpbear
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
"Roger Abell [MVP]" <mvpN...@asu.edu> wrote in message
news:%23J0WiEv...@TK2MSFTNGP04.phx.gbl...
fpbear
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
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
--
Cheers,
Marin Marinov
MCT, MCSE 2003/2000/NT4.0,
MCSE:Security 2003/2000, MCP+I
Roger Abell [MVP]
>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.
>
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
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]
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
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]
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
http://www.petenetlive.com/KB/Article/0000389.htm
Pete
http://www.petenetlive.com
>> On Tuesday, March 20, 2007 8:10 AM Roger Abell [MVP] wrote:
>> Alas, no. This is not available.
>>> On Tuesday, March 20, 2007 12:22 PM fpbear wrote:
>>> 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
>>>
>>>
>>> "Roger Abell [MVP]" <mvpN...@asu.edu> wrote in message
>>> news:%23J0WiEv...@TK2MSFTNGP04.phx.gbl...
>>>>> On Tuesday, March 20, 2007 3:10 PM fpbear wrote:
>>>>> 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
>>>>> --
>>>>> Cheers,
>>>>> Marin Marinov
>>>>> MCT, MCSE 2003/2000/NT4.0,
>>>>> MCSE:Security 2003/2000, MCP+I
>>>>>> On Tuesday, March 20, 2007 10:36 PM Roger Abell [MVP] wrote:
>>>>>> "fpbear" <dontse...@nospam.com> wrote in message
>>>>>> news:Okqgwuya...@TK2MSFTNGP05.phx.gbl...
>>>>>>
>>>>>> 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.
>>>>>>> On Tuesday, March 20, 2007 11:09 PM fpbear wrote:
>>>>>>> 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.
>>>>>>>> On Wednesday, March 21, 2007 12:58 AM Roger Abell [MVP] wrote:
>>>>>>>> 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.
>>>>>>>>> On Wednesday, March 21, 2007 1:20 AM fpbear wrote:
>>>>>>>>> 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.
>>>>>>>>>> On Wednesday, March 21, 2007 8:50 AM Roger Abell [MVP] wrote:
>>>>>>>>>> "fpbear" <dontse...@nospam.com> wrote in message
>>>>>>>>>> news:uOPhmD4a...@TK2MSFTNGP06.phx.gbl...
>>>>>>>>>>
>>>>>>>>>> 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