RE: Re: [ActiveDir] icmp's
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 Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile:http://mvp.support.microsoft.com/profile=""> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, January 02, 2006 2:15 AM To: ActiveDir@mail.activedir.org Subject: RE: Re: [ActiveDir] icmp's 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) http://www.gpoguy.com/ 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 reworkingof 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. Eventuallysomeone at MS will see what someone else is doing with their tech and say hey that is pretty cool, lets dothat now. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Sunday, January 01, 2006 7:11 PM To: ActiveDir@mail.activedir.org Subject: RE: Re: [ActiveDir] icmp's Random input below From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, January 01, 2006 11:54 AM To: ActiveDir@mail.activedir.org Subject: RE: Re: [ActiveDir] icmp's 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. [Darren Mar-Elia]If you're referring to using stuff like Restricted Groups policy to control domain-based group membership, then I agree and in fact its definitely a bad idea. The thing I don't like is that there really isn't any decent way to remove that capability out of the box. I could see value in using GP to control certain AD config settings, just so that you could have a common interface for all Windows configuration settings, but GP processing should be smart enough to say, hey, I'll only apply these domain changes to the PDC emulator and let AD replicate them out, or something like that. 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 machinesis 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? [Darren Mar-Elia]Agreed that an API into policy settings would be great. I've only asked about 55 times and it still isn't on the horizon. Why? Mostly because there is no standard within GP around how settings are stored. Since separate product teams ori
RE: Re: [ActiveDir] icmp's
Cool. Now I understand the rationale for what you were getting at. Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, January 01, 2006 1:54 PM To: ActiveDir@mail.activedir.org Subject: RE: Re: [ActiveDir] icmp's 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 machinesis 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 Sent: Sunday, January 01, 2006 1:09 PM To: [EMAIL PROTECTED] Subject: RE: Re: [ActiveDir] icmp's 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 youre getting at. Help out an old haggard road warrior. ;o) Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, January 01, 2006 10:50 AM To: ActiveDir@mail.activedir.org Subject: RE: Re: [ActiveDir] icmp's 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 theold 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 sodidn't need the sorting capability of GPOs. Overall I am ok levelhappy 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 Sent: Sunday, January 01, 2006 9:58 AM To: ActiveDir@mail.activedir.org Subject: RE: Re: [ActiveDir] icmp's 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 Sent: 01 January 2006 14:18 To: ActiveDir@mail.activedir.org Subject: [Norton AntiSpam] Re: [ActiveDir] icmp's 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
RE: Re: [ActiveDir] icmp's
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 Sent: 01 January 2006 14:18 To: ActiveDir@mail.activedir.org Subject: [Norton AntiSpam] Re: [ActiveDir] icmp's 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 alot of networks out there are configured with ICMPdisabled 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... Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] on behalf of Al Mulnick Sent: Fri 12/30/2005 8:13 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] icmp's When you say legacy way, what does that mean exactly? On 12/30/05, Tom Kern [EMAIL PROTECTED] wrote: would this also affect clients from getting logon scripts? and when i say logon scripts, i mean the legacy way of distributing them, NOT thru GPO's. Thanks again On 12/30/05, Brian Desmond [EMAIL PROTECTED] wrote: You need to enable ICMP echo source clients dest dc's, and icmp echo-reply source dc's dest clients. The rules look something like this: access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers echo access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any echo-reply Have your network people considered rate-limiting ICMP packets rather than shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are necessary pieces of a network. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] on behalf of Tom Kern Sent: Fri 12/30/2005 9:25 AM To: activedirectory Subject: [ActiveDir] icmp's What affect would blocking icmp packets on all vlans have on win2k/xp client logons in a win2k forest? any? I know clients ping dc's to see which responds first and later ping dc's to determine round trip time for GPO processing, but would blocking icmp's have any adverse affects on clients? I only ask because my corp blocks icmp's on all our vlans and i get a lot of event id 1000 from Usernev with error code of 59 which when i looked up, refers to network connectivity issues. i think this event id is related to the fact we block icmp packets and i was wondering if thats something i should worry about in a win2k network. Thanks
RE: Re: [ActiveDir] icmp's
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 theold 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 sodidn't need the sorting capability of GPOs. Overall I am ok levelhappy 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 ParrisSent: Sunday, January 01, 2006 9:58 AMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] icmp's 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 KernSent: 01 January 2006 14:18To: ActiveDir@mail.activedir.orgSubject: [Norton AntiSpam] Re: [ActiveDir] icmp's 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 alot of networks out there are configured with ICMPdisabled 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...Thanks,Brian Desmond[EMAIL PROTECTED]c - 312.731.3132From: [EMAIL PROTECTED] on behalf of Al MulnickSent: Fri 12/30/2005 8:13 PMTo: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] icmp'sWhen you say legacy way, what does that mean exactly?On 12/30/05, Tom Kern [EMAIL PROTECTED] wrote: would this also affect clients from getting logon scripts? and when i say logon scripts, i mean the legacy way of distributing them, NOT thru GPO's. Thanks again On 12/30/05, Brian Desmond [EMAIL PROTECTED] wrote: You need to enable ICMP echo source clients dest dc's, and icmp echo-reply source dc's dest clients. The rules look something like this: access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers echo access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any echo-reply Have your network people considered rate-limiting ICMP packets rather than shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are necessary pieces of a network. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] on behalf of Tom Kern Sent: Fri 12/30/2005 9:25 AM To: activedirectory Subject: [ActiveDir] icmp's What affect would blocking icmp packets on all vlans have on win2k/xp client logons in a win2k forest? any? I know clients ping dc's to see which responds first and later ping dc's to determine round trip time for GPO processing, but would blocking icmp's have any adverse affects on clients? I only ask because my corp blocks icmp's on all our vlans and i get a lot of event id 1000 from Usernev with error code of 59 which when i looked up, refers to network connectivity issues. i think this event id is related to the fact we block icmp packets and i was
RE: Re: [ActiveDir] icmp's
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 youre getting at. Help out an old haggard road warrior. ;o) Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, January 01, 2006 10:50 AM To: ActiveDir@mail.activedir.org Subject: RE: Re: [ActiveDir] icmp's 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 theold 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 sodidn't need the sorting capability of GPOs. Overall I am ok levelhappy 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 Sent: Sunday, January 01, 2006 9:58 AM To: ActiveDir@mail.activedir.org Subject: RE: Re: [ActiveDir] icmp's 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 Sent: 01 January 2006 14:18 To: ActiveDir@mail.activedir.org Subject: [Norton AntiSpam] Re: [ActiveDir] icmp's 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 alot of networks out there are configured with ICMPdisabled 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... Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] on behalf of Al Mulnick Sent: Fri 12/30/2005 8:13 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] icmp's When you say legacy way, what does that mean exactly? On 12/30/05, Tom Kern [EMAIL PROTECTED] wrote: would this also affect clients from getting logon scripts? and when i say logon scripts, i mean the legacy way of distributing them, NOT thru GPO's. Thanks again On 12/30/05, Brian Desmond [EMAIL PROTECTED] wrote: You need to enable ICMP echo source clients dest dc's, and icmp echo-reply source dc's dest clients. The rules look something like this: access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers echo access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any echo-reply Have your network people considered rate-limiting ICMP packets rather than shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are necessary pieces of a network. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL
RE: Re: [ActiveDir] icmp's
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 machinesis 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 KingslanSent: Sunday, January 01, 2006 1:09 PMTo: [EMAIL PROTECTED]Subject: RE: Re: [ActiveDir] icmp's 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 youre getting at. Help out an old haggard road warrior. ;o) Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Sunday, January 01, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] icmp's 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 theold 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 sodidn't need the sorting capability of GPOs. Overall I am ok levelhappy 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 ParrisSent: Sunday, January 01, 2006 9:58 AMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] icmp's 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 KernSent: 01 January 2006 14:18To: ActiveDir@mail.activedir.orgSubject: [Norton AntiSpam] Re: [ActiveDir] icmp's 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 alot of networks
RE: Re: [ActiveDir] icmp's
Random input below From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Sunday, January 01, 2006 11:54 AMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] icmp's 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. [Darren Mar-Elia]If you're referring to using stuff like Restricted Groups policy to control domain-based group membership, then I agree and in fact its definitely a bad idea. The thing I don't like is that there really isn't any decent way to remove that capability out of the box. I could see value in using GP to control certain AD config settings, just so that you could have a common interface for all Windows configuration settings, but GP processing should be smart enough to say, hey, I'll only apply these domain changes to the PDC emulator and let AD replicate them out, or something like that. 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 machinesis 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?[Darren Mar-Elia]Agreed that an API into policy settings would be great. I've only asked about 55 times and it still isn't on the horizon. Why? Mostly because there is no standard within GP around how settings are stored. Since separate product teams originally wrote the various client side extensions, without any standard storage format, we are in the mess we have today and they'd basically have to re-write all of GP to make that happen, or build some interface that abstracts each of the various storage formats into a common API--in either case, not a small amount of work. That being said, it has not slowed down several ISVs from figuring out the storage formats and using it in their products to essentially give different interfaces into GP. It is do-able if you have a reasonable amount of programming experience. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick KingslanSent: Sunday, January 01, 2006 1:09 PMTo: [EMAIL PROTECTED]Subject: RE: Re: [ActiveDir] icmp's 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 youre getting at. Help out an old haggard road warrior. ;o) Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Sunday, January 01, 2006 10:50 AMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] icmp's 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 theold 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 sodidn't need the sorting capability of GPOs. Overall I am ok levelhappy 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 ParrisSent: Sunday, January 01, 2006 9:58 AMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] icmp's This is from the Microsoft article Enterprise logon scripts By default, logon scrip
RE: Re: [ActiveDir] icmp's
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) http://www.gpoguy.com/ 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 reworkingof 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. Eventuallysomeone at MS will see what someone else is doing with their tech and say hey that is pretty cool, lets dothat now. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-EliaSent: Sunday, January 01, 2006 7:11 PMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] icmp's Random input below From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Sunday, January 01, 2006 11:54 AMTo: ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] icmp's 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. [Darren Mar-Elia]If you're referring to using stuff like Restricted Groups policy to control domain-based group membership, then I agree and in fact its definitely a bad idea. The thing I don't like is that there really isn't any decent way to remove that capability out of the box. I could see value in using GP to control certain AD config settings, just so that you could have a common interface for all Windows configuration settings, but GP processing should be smart enough to say, hey, I'll only apply these domain changes to the PDC emulator and let AD replicate them out, or something like that. 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 machinesis 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?[Darren Mar-Elia]Agreed that an API into policy settings would be great. I've only asked about 55 times and it still isn't on the horizon. Why? Mostly because there is no standard within GP around how settings are stored. Since separate product teams originally wrote the various client side extensions, without any standard storage format, we are in the mess we have today and they'd basically have to re-write all of GP to make that happen, or build some interface that abstracts each of the various storage formats into a common API--in either case, not a small amount of work. That being said, it has not slowed down several ISVs from figuring out the storage formats and using it in their products to essentially give different interfaces into GP. It is do-able if you have a reasonable amount of programming
