Introducing Windows Server® 2008

Errata for Introducing Windows Server® 2008




The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted Date Corrected
Printed
Page 134

dcpromp should be dcpromo On page 134, the last sentence before the code sample references "dcpromp" instead of "dcpromo." Change: "The syntax for running dcpromo.exe in unattended mode is dcpromp /unattend:unattend.txt, and a sample unattend.txt file you could use (or further customize) for doing this is as follows:" To: "The syntax for running dcpromo.exe in unattended mode is dcpromo /unattend:unattend.txt, and a sample unattend.txt file you could use (or further customize) for doing this is as follows:"

Microsoft Press  May 06, 2010 
Printed
Page 164-165

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

Microsoft Press  Jul 13, 2010 
Printed
Page 229

Sentence is missing the word not On page 229, the sentence immediately after the image is missing the word not. Change: "Note the Configuration button that was displayed when we accessed this page as an ordinary user." To: "Note the Configuration button that was not displayed when we accessed this page as an ordinary user." Microsoft Press is committed to providing informative and accurate books. All comments and corrections listed above are ready for inclusion in future printings of this book. If you have a later printing of this book, it may already contain most or all of the above corrections.

Microsoft Press  May 06, 2010