20150415

Wed Apr 15 10:27:51 EDT 2015 Slept fairly well. Although I went to bed slightly hungry last night, I wasn't excessively hungry when I woke up. Goals: Work: - Plan backups for new vm's Because of AD database consistency concerns between DC's, we should NOT do live snapshots.* *Although there is an initial patch to support VM Generation-ID in the development branch of qemu, which should make it save to snapshot Server 2012+ DC's. I don't believe this feature is present yet in the production qemu release. Since we plan to virtualize two domain controllers, for each one, we may want to: - Shut down the vm - Back up the disk image of the shut down machine - Turn the vm back on *** If a DC dies, we must not spin up a backup image! Instead, we must spin up a new server, and promote it to DC. *** - Do some refresher reading of AD/DC roles The Global Catalog Server has a read-only copy of every object in the Forest. In a single-Domain environment (like ours) this isn't of great import. In a single-Domain forest, it's reasonable to configure each DC as a global catalog server (though this would be a bad idea in a multi-domain forest because of performance issues and incompatible FSMO roles). We should have at least one global catalog server in each domain that contains an Exchange mailbox server. AD is heavily entangled with DNS. Both DC's should be DNS servers. Flexible Single Master Operations http://en.wikipedia.org/wiki/Flexible_single_master_operation "FSMO is a specialized domain controller (DC) set of tasks, used where standard data transfer and update methods are inadequate. AD normally relies on multiple peer DCs, each with a copy of the AD database, being synchronized by multi-master replication. The tasks which are not suited to multi-master replication, and are viable only with a single-master database, are the FSMOs." The first domain controller brought online gets the FSMO roles. In an small domain like ours, there's no reason to split FSMO roles between DC's. PDC Emulator role (one per domain): - source for time synchronization for all other domain controllers - all password changes occur on the PDC Emulator, and get priority replication RID Master role (one per domain): - allocates security RIDs to DCs to assign to new AD security principals (users, groups, etc.) (RID is a variable length number assigned to objects at creation, which becomes part of the object's Security Identifier (SID) that uniquely identifies an it in a domain.) Infrastructure Master role (one per domain): - handles cross-domain object reference - does nothing in a single-domain environment Schema Master role (one per forest): - replicate schema changes to all other domain controllers in the forest - the schema rarely changes, so the Schema Master rarely does much Domain Naming Master (one per forest): - processes all changes to the namespace, like adding child domains "When a FSMO role is transferred to a different DC, the original FSMO holder and the new FSMO holder communicate to ensure no data is lost during the transfer. If the original FSMO holder experienced an unrecoverable failure, you can force another DC to seize the lost roles; however, there is a risk of data loss because of the lack of communications. If you seize a FSMO role instead of transferring the role, that domain controller can never be allowed to host that FSMO role again, except for the PDC emulator Master operation and the Infrastructure Master Operation. Corruption can occur within Active Directory. FSMO roles can be easily moved between DCs using the AD snap-ins to the MMC or using ntdsutil which is a command line based tool." - Update rents for a few properties I finished three. Question (which I may not have time to answer today): - In what manner is AD entangled with DNS?

< ^ txt