RE: [ActiveDir] Updating ADM files - best practices

[Ruston, Neil]

Title: Message

FWIW:   I have decided to adopt the following approach:   Receive new ADM template (e.g. system.adm) Test this new template in a lab environment Sign the new template off as approved for production use Open the GP object which requires the newer ADM template using GPedit Remove the superseded template and import the new template file Ensure the new file is propagated to all DCs Implement new GPO settings and close GPedit Ensure new GPO settings are propagated This is almost identical to the process I designed for in-house ADM file updates.   The issues I mentioned are related to the fact that in the past I have used GP settings which have subsequently 'disappeared' from the UI, which meant I was no longer able to control those settings via GPO.   Maybe we have somewhat differing definitions of '... isn't really that dangerous' :)   You say the ADM should be tested before release, but how would you ensure this is done? The rollout of a SP could be performed by a group outside of the realms of AD itself. Who's to say the AD guys will be consulted about a client SP rollout, if the ramifications are not even understood? :) I'd rather be proactive and block auto updates, than react to ADM issues. After all, that's why MS exposed this setting :))   neil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 20 February 2005 05:55 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Updating ADM files - best practices Hi Neil,   I understand your concern that unexpectedly updating the Production ADM files "sounds like a bad idea", but it really isn't that dangerous. The ADM template doesn't change the policy at all. It only changes what you see in Active Directory Users & Computers. So even if Microsoft does stuff up the new template and make it "non backward compatible" the worst is that it will display wrong in ADUC. Of course you have to be careful when you change policies that you understand what the ADM template is now doing.... but you would always test it comprehensively before releasing it anyway.....   You mention that you were bitten before. I suspect that this was the XP update that caused an error message when you viewed the policy in ADUC under Windows 2K. As I say, microsoft stuffed up, but it didn't hurt your users, just the users of ADUC.   Alan C   Policy Management Software:- http://www.sysprosoft.com/index.php?ref=activedir&f=pol_summary.shtml ADM Template Editor:- http://www.sysprosoft.com/index.php?ref=activedir&f=adm_summary.shtml Policy Log Reporter(Free) http://www.sysprosoft.com/index.php?ref=activedir&f=policyreporter.shtml   ----- Original Message ----- From: Ruston, Neil To: 'ActiveDir@mail.activedir.org' Sent: Saturday, February 19, 2005 2:12 AM Subject: RE: [ActiveDir] Updating ADM files - best practices That made me chuckle - you advise that I give up the one setting which was the sole reason for posing the question :)   I am not prepared to allow ADMs to be auto updated - this is too risky in a large, global environment. XP SP2 has just been released with its own new ADM files. I don't want the first admin who uses SP2 to inadvertently update the ADMs - that update needs to be done in a controlled manner, IMHO.   I've been bitten by this issue before and want to protect myself from it occurring again.   I'll test the 'copy files to SYSVOL and allow to replicate' route.   thanks, neil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 18 February 2005 04:35 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Updating ADM files - best practices Neil,   Not sure if it is best practice, but what I do is:-   1. Leave on the Auto upgrade of ADM files. We assume that Microsoft always adds to ADM files, never changes existing keys.   2. Always use a different ADM file for your modifications. Never change the microsoft ones.   3. Leave the Domain GPO alone for security settings and  password policy etc. Create another GPO for the "non standard" stuff.  (Note there was a long discussion on this very point 6 months ago and I think the general conclusion was that there wasn't a lot of technical reasons for doing so, just easier to understand what was going on)   4. I also create a GPO applied to a Test OU and then link it across when it is fully tested. I feel this is just as safe (or maybe safer) than doing it in a different domain then importing it. Admittedly, if you are testing complex changes were multiple policies interact, a separate domain is good since the policies will apply in exactly the same order as your final implementation.   Alan C   Policy Management Software:- http://www.sysprosoft.com/index.php?ref=activedir&f=pol_summary.shtml ADM Template Editor:- http://www.sysprosoft.com/index.php?ref=activedir&f=adm_summary.shtml Policy Log Reporter(Free) http://www.sysprosoft.com/index.php?ref=activedir&f=policyreporter.shtml   ----- Original Message ----- From: Ruston, Neil To: 'ActiveDir@mail.activedir.org' Sent: Thursday, February 17, 2005 10:24 PM Subject: [ActiveDir] Updating ADM files - best practices Scenario: W2k DCs and multiple w2k domains I plan to implement and enable the GPO setting 'turn off automatic update of ADMs' in the default domain GPO as part of the upgrade from w2k DCs and domains to w2k3 DCs and domains. [For obvious reasons, I hope] Issue: This new setting requires an updated system.adm. Naturally I could place this one setting in a new GPO (in a test env) and after testing, transport the whole GPO (incl ADMs) using GPMCs backup/restore feature. However, I would rather simply update the ADM file(s) and then make the change to the def domain GPO. Question: What is the preferred method for updating ADM files? I don't see any reason why I can't just copy a new system.adm into SYSVOL, wait for replication to finish and then change the def domain GPO. Is this logic flawed in any way? Thanks in advance, neil ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ==============================================================================