Errata

"To find links to the author's web site and email address, you can visit

http://www.daynotes.com"

There is no (longer) reference to Alistair G. Lowe-Norris on this site.

A FSMO role owner who has its roles seized cannot be brought back into the domain.
Replication will not will not equalize this issue, only downing the old role holder,
doing a metadata cleanup to remove the old role holder from AD and rebuilding the
machine from the ground up.

The first two sentences on the page are about group conversion and do not make sense to me given the information in Tables 2-4 through 2-7.

I believe the first sentence should read:

"A domain local group can be converted to a universal group provided
that the domain local group DOES NOT CONTAIN ANY OTHER DOMAIN LOCAL
GROUP."

And the second sentence should read:

"A domain global group can be converted to a universal group provided
that the domain global group IS NOT ALREADY A MEMBER OF ANOTHER DOMAIN
GLOBAL GROUP."

This paragraph makes the claim that "Microsoft quickly jumped onto this
bandwagon and adopted the standard with Windows 2000". This implies that
Microsoft has adopted the standards in IETF RFC 2136. This is not correct.

RFC 2136 is based on the standards for DNS in RFC 1035. The naming
conventions refer directly to RFC 1035, which states:

"The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less."

As one can clearly see from the example at the bottom of page 83, Windows
2000 uses the '_' (underscore) character, which is completely out of the
set of accepted characters. Not only that, it is used as the first
character in a DNS label.

The third paragraph on page 81 should read: 'Microsoft quickly jumped onto
this bandwagon and _ADAPTED_ the standards in with Windows 2000.' This is a
more accurate representation of the deviation from IETF standards.

I believe there should also be a discussion of this related to the fact
that only Microsoft 2000 will be able to utilize these DNS entries, as
other Operating Systems will not be able to form queries in a manner which
deviates so far from the standard.

This posting refers to the second main text paragraph and the subsequent second bullet point regarding ISM-SMTP. The paragraph states:

"However, DS-RPC is not the best replication mechanism for asynchronous links
like these, so instead PetroCorp creates digital certificates and rolls our a
certificate server to those sites to enable the replication mechanism to use
the underlying mail transport via an SMTP Connector for each link. That
changes the list to include the following site links:

? Create 86 high-cost DS-RPC site links for each of the stable 64KBps (60)
lihks.
? Create eight high-cost ISM-SMTP site links for each of the unstable
64KBps (75) links representing South America branches."

My understanding is that ISM-SMTP can only be used as a site link between
different domains. The Windows 2000 Server Resource Kit, amongst many others,
states:

"Replication between sites over SMTP is supported for only domain controllers
of different domains. Domain controllers of the same domain must replicate by
using the RPC over IP transport. Therefore, replication between sites over
SMTP is supported for only schema, configuration, and Global Catalog
replication, which means that domains can span sites only when point-to-point,
synchronous RPC is available between sites."

I think this is because the File Replication Service does not support
asynchronous links.

In fact, the author does point this out himself, in the tip on page 159:

"The SMTP Connector cannot be used for domain NC replication...This means
that multisite domains with slow links will be required to use DS-RPC for
domain replication."

Unfortunately for our organization and I daresay many others this means
wherever you have a very slow/unreliable link you may well have to create a
new domain in order to use the asynchronous SMTP replication.

Unfortunately for the author, this issue really needs to be addressed in his
domain design, in Chapter 6, p.138 onwards, before he can come up with a
sensible correction for p.173.

I suggest Chapter 6 would need some additions to point out that the a
consideration should be made for:

"? The links between eight South American branches and the hub are very
unreliable." (p.139)

i.e., It should be mentioned that the unreliability of the links may force you
to consider having one domain per South American branch! This would push up
"The right way" (p.140) solution from 9 domains to a potential 9 + 8 = 17
domains which obviously would have a real impact in terms of admin and
hardware and doesn't sound at all sexy. (We're being told the ideal AD goal
is one AD domain and now we find out we actually need one domain per poorly
linked office! i.e. the smaller and less well connected the office the more
likely it's going to require an entire domain of its own - not a very nice
thing for AD to admit to!) Please correct me if I'm wrong here - I really
hope I am.

This is a very interesting conundrum that I imagine quite a few companies are
up against so I hope this issue is discussed in future revisions of the book
rather than being omitted because there's no solution that looks very
appealing.

P.S. I have only read up to Chapter 8 so far so I don't know if this issue
will affect any of the later chapters.

In the section named "Standard GPO Inheritance Rules in OU's", in the seventh paragraph, sentences 2 and 3 state...

"The setting in the GPO child policy takes priority, although there is one
case in which this is not true. If the parent disables a setting and the
child makes a change to that setting, the child's change is ignored. In other
words, the disabling of a setting is always inherited down the hierarchy."

I have not found this to be true. The child organization's GPO policy still
takes priority and implements the change. I have tested this on my domain
several times and obtained Microsoft Consulting Services verification that
this is the expected behavior.

Tests
====================================================================
Note: There wern't any "No overrides", "Block Inheritance", nor
"Security Filters" applied. The tests were run on a domain
with a single DC (for speed) and four Windows 2000 Prof
Clients. Both the "SecEdit /refreshpolicy Machine_policy" as
well as the "SecEdit /refreshpolicy User_policy" commands were
run prior to each test and several seconds were allowed for
the local client's registry to be updated. Various settings
at each OU level were made and recorded.
====================================================================
1) In the Default Domain Policy, use the existing policy and set
the "Disable Registry Editing Tools" policy to "Disabled".
----------------------------------------
User Configuration
Administrative Templates
System
Disable registry editing tools --> "Disabled"
----------------------------------------

2) In a root Level OU, create a new group policy and set the
"Disable Registry Editing Tools" policy to "Disabled".
----------------------------------------
User Configuration
Administrative Templates
System
Disable registry editing tools --> "Disabled"
----------------------------------------

3) I a child OU of the OU noted above, create a new group policy
and set the "Disable Registry Editing Tools" policy to "Enabled".
----------------------------------------
User Configuration
Administrative Templates
System
Disable registry editing tools --> "Enabled"
----------------------------------------

Result: While the policy is one of the "Disable..." title policies,
the Registry Editing tools are "Disabled", meaning that the
policiy is trully "Enabled". According to the author, the
Child OUs should inherit the "Disable" setting from one
(or both) parents. In this situation, the registry tools
should remain usable, however, in practice they are not
usable. This indicates that the Child OU is NOT inheriting
the "Parents" explicit "Disable" setting.

This was verified independently with a 3rd party GPO
RSoP (Resultant Set of Policies) tool. [FAZAM 2000 from the
Full Armor company.]
====================================================================

I consider this in the category of a "serious technical mistake"
since it affects, in their entirety, the manner in which IT
professionals design and implement Group Policy Objects for an
organization.

The only GPO settings to which this does not apply are the DDP's (Default
Domain Policy) Account" policy settings (Password Policy, Account Lockout
Policy, and Kerberos Policy) as the author correctly Warns/Cautions on
page 188.

Please let me know if the author coroborates this information. If other
more specfic tests were performed by the author where the text is correct
as stated, please let me know that also.

The code sample on this page declares a variable adsMyObject (line 2), but later uses adsMyDomain (line 4), which is not declared, while never using
adsMyObject. If this is by design, could it be explained? The following text
refers to both variables.

The last line of the sample code does not work on my system. I tried using
the full name for the IADS::OpenDSObject method without success.

As written the code returns an "object required" error. Adding the
IADS:: prefix returns "cannot use parenthesis when calling a subroutine".

After fixing the trustee to be an NT style name, this example still gives an
"ActiveX component can't create object" error.

I have been unable to find a way around this yet.
This is yet another error that is not documented by Microsoft.

Several examples use the LDAP DN to set the ACE Trustee. This gives an error:
The security ID structure is invalid. It appears that only the Well Known
names, or NT style names, can be used.

In the code sample, the mustContain attribute is shown being set after the initial SetInfo call. This will ALWAYS fail, since Active Directory does
not allow the mustContain attribute of a class to be modified after its initial
creation.

This would also seem to contradict the discussion about the mustContain/
systemMustContain attributes earlier in the book. If the mustContain
attributes are all internally converted to systemMustContain attributes when
a class is initially created, and you cannot modify the mustContain attribute,
then the mustContain attribute must always be empty. Is it just me or does
this seem wrong?

Using the sample code, I am able to return an adoConnection.State = 1, even without
passing parameters to the adoConnection.Open method. How can this be so?

It makes it look like I'm authenticated, when clearly I cannot be.