RE: [ActiveDir] Updating ADM files - best practices

[Ruston, Neil]

Title: Message

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. ==============================================================================