RDOC should be RODC
On pages 164 and 165 there are multiple references to RDOC which should be RODC.
Change:
"RDOC, however, solves this dilemma by providing a secure way to have a domain controller at your branch office. The only requirement for using RDOC is that the domain controller that holds the PDC Emulator FSMO role on your network has to be running Windows Server 2008. Once this is the case and you’ve deployed an RDOC at your branch office, changes made to the directory on your normal (writable) domain controllers replicate to the RDOC, but nothing replicates in the opposite direction. That’s because the directory database of a RDOC is read-only, so you can’t write anything to it locally—it has to receive all changes to its database via replication from another (writable) domain controller. (RDOCs can’t replicate with each other either, so there’s no point having more than one
RDOC at a given site—plus it could cause inconsistent logon experiences for users if you did do this.) So RDOC replication is completely unidirectional—and this applies to DFS replication traffic as well.
RDOCs also advertise themselves as the Key Distribution Center (KDC) for the branch office where they reside, so they handle all requests for Kerberos tickets from user and computer accounts at the remote site. RDOCs don’t store user or computer credentials in their directory database, however; so when a user at the branch office tries to log on, the RDOC contacts a writable DC at the hub site to request a copy of the user’s credentials. How the hub DC responds to the RDOC’s request depends on how the Password Replication Policy is configured for that RDOC. If the policy says that the user’s credentials can be replicated to the RDOC, the writable DC does this, and the RDOC caches the credentials for future use (until the user’s credentials change). The result of all this is that RDOCs generally have few credentials stored on them. So if an RDOC somehow gets stolen (remember the DC cleaning guy), only those credentials are compromised and replacing them is much less work than rebuilding your entire directory from scratch.
Another feature of RDOCs is that a domain administrator can delegate the local administrator role for an RDOC to an ordinary domain user. This can be very useful for smaller branch offices that have no full-time expert IT person on site. So if you need to load a new driver into your DC at a remote site, you can just give instructions to your “admin” by phone on how to do this. The admin is simply an ordinary user who can follow instructions, and delegating RDOC admin rights to him doesn’t enable him to perform any domain-wide administrative tasks or log on to a writable DC at headquarters—the damage he can do is limited to wrecking only the RDOC."
To:
"RODC, however, solves this dilemma by providing a secure way to have a domain controller at your branch office. The only requirement for using RODC is that the domain controller that holds the PDC Emulator FSMO role on your network has to be running Windows Server 2008. Once this is the case and you’ve deployed an RODC at your branch office, changes made to the directory on your normal (writable) domain controllers replicate to the RODC, but nothing replicates in the opposite direction. That’s because the directory database of a RODC is read-only, so you can’t write anything to it locally—it has to receive all changes to its database via replication from another (writable) domain controller. (RODCs can’t replicate with each other either, so there’s no point having more than one
RODC at a given site—plus it could cause inconsistent logon experiences for users if you did do this.) So RODC replication is completely unidirectional—and this applies to DFS replication traffic as well.
RODCs also advertise themselves as the Key Distribution Center (KDC) for the branch office where they reside, so they handle all requests for Kerberos tickets from user and computer accounts at the remote site. RODCs don’t store user or computer credentials in their directory database, however; so when a user at the branch office tries to log on, the RODC contacts a writable DC at the hub site to request a copy of the user’s credentials. How the hub DC responds to the RODC’s request depends on how the Password Replication Policy is configured for that RODC. If the policy says that the user’s credentials can be replicated to the RODC, the writable DC does this, and the RODC caches the credentials for future use (until the user’s credentials change). The result of all this is that RODCs generally have few credentials stored on them. So if an RODC somehow gets stolen (remember the DC cleaning guy), only those credentials are compromised and replacing them is much less work than rebuilding your entire directory from scratch.
Another feature of RODCs is that a domain administrator can delegate the local administrator role for an RODC to an ordinary domain user. This can be very useful for smaller branch offices that have no full-time expert IT person on site. So if you need to load a new driver into your DC at a remote site, you can just give instructions to your “admin” by phone on how to do this. The admin is simply an ordinary user who can follow instructions, and delegating RODC admin rights to him doesn’t enable him to perform any domain-wide administrative tasks or log on to a writable DC at headquarters—the damage he can do is limited to wrecking only the RODC."