Cool – Darren is blogging. And already in OPML-o-Matter: http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/12/30/80015.aspx Gruesse - Sincerely, Ulf B. Simon-Weidner MVP-Book
"Windows XP - Die Expertentipps": http://tinyurl.com/44zcz From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe Darren and I have had offline chats about this before so I know we
are quite in sync on our thoughts. That is one of the reasons I am brave enough
to spout them, if Darren isn't beating me up on my GPO thoughts they can't be too
far off base. He is the GPOGUY after all. :o) BTW, I didn't see Darren say it, but I just found today that he has
started blogging... http://blogs.dirteam.com/blogs/gpoguy/.
But back to this stuff... I agree that the common interface is
nice, but don't fully believe the info needs to be written to a policy file in
sysvol since you have the DCs right there to write the info into AD. But alas,
as you mention, we are talking decent reworking of how things work and
that includes parts of AD to do really do it cool especially in terms of
restricted AD groups. I do believe that for some of the stuff, code is now in
there to force the change to only occur on the PDC. I am not sure when the
change occurred but I am guessing K3 but I was trying to chase some code a
month or two back in the Windows source tree and it appeared there was some
code in the GPO processing that was looking for a PDC in order to make changes.
I ran out of time and never went back to it though. RE the API for settings. It is kind of sad how that
wasn't/hasn't/maynotbe implemented. It seems like it would have been easiest
way for MS to have done things for themselves as well. I do agree that it is
possible to reverse it out and figure out how to do it. Of course we aren't
supposed to but that doesn't stop progress in the MS world.
Eventually someone at MS will see what someone else is doing with their
tech and say hey that is pretty cool, lets do that now. From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Random input below 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 –
Enterprise logon scripts 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern 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... |
- RE: Re: [ActiveDir] icmp's Ulf B. Simon-Weidner
- RE: Re: [ActiveDir] icmp's Rick Kingslan