Title: 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 
----- Original Message -----
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.
==============================================================================

Reply via email to