|
Cool. Now I understand the rationale
for what you were getting at. Rick From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Rick came out of the woodwork and rambled: "Huh? Can you explain both
statements, joe?" First statement being, I would rather not
set domain policies in GPOs... I am referring to actual domain policy, not a
policy applied to all machines in the domain. You know, the original meaning of
domain policy. Pushing any policy to domain controllers that has to do with
configuration of AD is assinine in my opinion, you already have a mechanism to
push those changes through the environment. You don't need to use another one.
Also it is a point of confusion for tons and tons of people. There should be a
clear divisor between true domain policy and a policy that gets applied to each
individual machine. Second statement being programmatically
handling settings in policies... You can't set GPO settings programmatically
unless you reverse the format of the policy information in sysvol. All you can
do is backup/restore/export/import/enable/disable. What if I want to take all
policies under the OU Buildings (which could be tens, hundreds, or thousands of
policy files) and set one setting, for the sake of argument say password policy
for local machines is equal to some set of values based on the specific OU
name that the policy is applied to (say it has finance in the name of the OU)
how will you do that programmatically without directly hacking the policy files
which last I heard wasn't supported? From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan joe stood up and attempted to smack Mark
Parris with a large trout, saying: “I would rather not set domain
policy with GPOs. While I am at it, I think we are far beyond the point that we
should have the ability to programmatically handle settings in policies.” Huh? Can you explain both
statements, joe? I understand the context of the first, but not
why. The second – I just am not sure what you’re getting
at. Help out an old haggard road warrior. ;o) Rick From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Come on, who ya going to believe?
Microsoft who has all sorts of typoes in the documentation (I just saw a
reference to objectcategory=user in an MS doc 2 days ago, I still have the
bruise on my forehead) or our trusted source... Al? :o) Personally I like the old style logon
scripts better than GPO logon scripts. Way too many things impact GPO
functions. I never found it difficult to write logon scripts designed to work
on specific users nor machines so didn't need the sorting capability of
GPOs. Overall I am ok level happy with having a default domain GPO and
default dc GPO as the only GPOs. I would rather not set domain policy with
GPOs. While I am at it, I think we are far beyond the point that we should have
the ability to programmatically handle settings in policies. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris This is from the Microsoft article – By default, logon
scripts written as either .bat or .cmd files (so-called "legacy"
logon scripts)
run in a visible command window; when executed, a command window open up on the
screen. To prevent a user from closing the command window (and thus terminating
the script), you can the Run legacy logon scripts
hidden enable policy. This ensures that all legacy logon scripts run
in a hidden window. Mark From: I thought i read somewhere in some MS doc it being refered to as
"legacy" since now you can put multiple logon scripts in GPO's and
that they recommend doing it that way. everytime a new OS or feature comes out, MS tends to refer to the
previous os/feature as legacy or down-level. maybe i just made a silly assumption that using a logon script as a
user attritbute( i guess somewhat simillar to the way NT did it) instead
of a GPO was "legacy". thanks
On 1/1/06, Al
Mulnick <[EMAIL PROTECTED]>
wrote: I personally haven't heard it referred to as "legacy".
I think that may be because it wasn't a legacy method when I last heard it ;) I haven't tested this, so your mileage may vary but: the
"legacy" method would have been created and designed for a time
before ICMP was the norm. As such, I wouldn't expect that to break if ICMP was
disabled. Several things will break, but I don't believe that's one of
them. Test it. You'll know for sure then right? Besides, I don't
imagine a lot of networks out there are configured with ICMP disabled
like that. Al On 12/31/05, Tom
Kern <[EMAIL PROTECTED]>
wrote: Thats it. Isn't that the way its refered to in MS-speak? I hope i didn't just make that up... On 12/30/05, Brian
Desmond <[EMAIL PROTECTED]
> wrote: presumably setting the
scriptPath attribute on accounts... |
