Weirdness when disable EFS via Group Policy

[Chris Largent]

I have two domain controllers, A & B...

A = Windows 2000 Server; PDC; DNS ('secondary' designation; Active Directory
integrated mode)
B = Windows Server 2003; DNS ('primary' designation; AD integrated mode)
domain functional level = "Native 2000"

I wanted to disable EFS (Encrypting File System) across the entire domain.
Of course, none of the Microsoft knowledgebase articles EXPLICITLY discuss a
MIXED environment of '2000 Server' and 'Server 2003'...

I have never messed with Group Policy before, so only the domain's default
Group Policy Object (GPO) existed. On server 'A', I created a brand new
GPO, moved it up in priority (above the default GPO), and followed Microsoft
article 222022 (for 2000 Server.) I then let that new GPO replicate, and
subsequently followed Microsoft article 324897 (for Server 2003) on server
'B'. I made no other changes to the new GPO, so theoretically, all other
policies within this new GPO were "not defined", and thus should not have
overrided anything crazy in the default GPO (so I would think...)

After this, everything got squirrelly, and I traced it down to something
related to DNS. On server 'A', the following was logged in the Application
Event Log:

Source = Userenv
EventID = 1000
Description = Windows cannot obtain the domain controller name for your
computer network. Return value (2146).

After I disabled the new GPO, the domain cleared itself up. ...Now, when I
make the 'disable EFS' modifications DIRECTLY to the DEFAULT GPO, my domain
behaves properly, and EFS is truly disabled on a domain-wide basis.

Can any gurus out there shed light on why my seemingly simple,
higher-priority GPO failed and caused the AD-DNS to fizzle out?

 

[Steven L Umbach]

Your error points to possibly a dns misconfiguration which is the number one reason
for AD problems. When you configure AD the first domain controller in the domain must
point to itself as it's preferred dns server in tcp/ip properties and additional
domain controllers need to point to the first domain controller [first in the list]
and themselves as their preferred dns servers. Then domain computers must point ONLY
to a W2K domain controller with the AD dns zone for the domain [they all do by
default]. Never list an ISP dns server in the tcp/ip properties of any domain
computer. The support tools netdiag and dcdiag can be used to check for proper domain
configuration with dcdiag reserved for domain controllers. If you change dns config
on a domain controller run netdiag /fix and then restart netlogon service on it and
view Event Viewer for problems.

What may have happened is that there was a replication problem with the new policy
due to a dns lookup failure. You can also check on GPO replication using the gpotool
and the replmon resource kit tool. Gpotool is quick and easy and will report
mismatches in policy between active domain controllers. The links below may
help. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp

 

[Chris Largent]

Steve, I think you hit the nail on the head. I think you may be correct
that my "EFS/Group Policy" issue was just a symptom of the problem, and the
actual problem was my DNS infrastructure configuration.

In my case, both server A and server B pointed at themselves as the
"primary" DNS server. I also had the FSMO roles assigned to these two
domain controllers in a haphazard way (but I think the core problem was the
"primary" DNS misconfiguration.)

So based on your prompting, and based on a few Microsoft knowledgebase
articles, I performed the following reconfiguration:

0) I didn't have to do anything with respect to my ISP's DNS servers. They
were already configured as just "forwarders".

1) I reconfigured my FSMO role placement. (An insignificant step, but I
did it anyway.)

(see article 223346)
http://support.microsoft.com/default.aspx?scid=kb;en-us;223346&Product=win2000

2) I reconfigured my two domain controllers to point at only server A as
"primary". Furthermore, on server A, I removed server B as a secondary.
Restated, server A now has NO secondary DNS configured.

(see article 825036)
http://support.microsoft.com/default.aspx?scid=kb;en-us;825036&Product=win2000

3) On server B, I removed itself as secondary. Restated, server B now has
NO secondary DNS configured. I'm sure this is a debatable step, but not
being an expert, I'm following the Microsoft knowledgebase article. Anybody
feel free to chime in.

(see article 275278)
http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&Product=win2000

4) I updated my DHCP server configuration so that it hands out server A as
'primary' and server B as 'secondary'.

I won't have time to test this updated configuration with my "Disable EFS"
GPO for a few days, but I'll attempt and post the outcome!

Your error points to possibly a dns misconfiguration which is the number one reason
for AD problems. When you configure AD the first domain controller in the domain must
point to itself as it's preferred dns server in tcp/ip properties and additional
domain controllers need to point to the first domain controller [first in the list]
and themselves as their preferred dns servers. Then domain computers must point ONLY
to a W2K domain controller with the AD dns zone for the domain [they all do by
default]. Never list an ISP dns server in the tcp/ip properties of any domain
computer. The support tools netdiag and dcdiag can be used to check for proper domain
configuration with dcdiag reserved for domain controllers. If you change dns config
on a domain controller run netdiag /fix and then restart netlogon service on it and
view Event Viewer for problems.

What may have happened is that there was a replication problem with the new policy
due to a dns lookup failure. You can also check on GPO replication using the gpotool
and the replmon resource kit tool. Gpotool is quick and easy and will report
mismatches in policy between active domain controllers. The links below may
help. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp

I have two domain controllers, A & B...

A = Windows 2000 Server; PDC; DNS ('secondary' designation; Active Directory
integrated mode)
B = Windows Server 2003; DNS ('primary' designation; AD integrated mode)
domain functional level = "Native 2000"

I wanted to disable EFS (Encrypting File System) across the entire domain.
Of course, none of the Microsoft knowledgebase articles EXPLICITLY discuss a
MIXED environment of '2000 Server' and 'Server 2003'...

I have never messed with Group Policy before, so only the domain's default
Group Policy Object (GPO) existed. On server 'A', I created a brand new
GPO, moved it up in priority (above the default GPO), and followed Microsoft
article 222022 (for 2000 Server.) I then let that new GPO replicate, and
subsequently followed Microsoft article 324897 (for Server 2003) on server
'B'. I made no other changes to the new GPO, so theoretically, all other
policies within this new GPO were "not defined", and thus should not have
overrided anything crazy in the default GPO (so I would think...)

After this, everything got squirrelly, and I traced it down to something
related to DNS. On server 'A', the following was logged in the Application
Event Log:

Source = Userenv
EventID = 1000
Description = Windows cannot obtain the domain controller name for your
computer network. Return value (2146).

After I disabled the new GPO, the domain cleared itself up. ...Now, when I
make the 'disable EFS' modifications DIRECTLY to the DEFAULT GPO, my domain
behaves properly, and EFS is truly disabled on a domain-wide basis.

Can any gurus out there shed light on why my seemingly simple,
higher-priority GPO failed and caused the AD-DNS to fizzle out?

 

[Steven L Umbach]

There is more than one way to configure dns on domain controllers and the important
thing is that they point to only AD domain controllers running dns for the domain and
that they are registering correctly in dns. What you have done should work, just
remember that if you ever retire the "chief" domain controller you want the remaining
domain controllers to point to an existing/functioning dc. Netdiag and dcdiag are two
great tools in determining if your AD configuration is firing on all eight cylinders
or not. I assume you also have static IP address for the domain controllers. Good
luck. --- Steve

Steve, I think you hit the nail on the head. I think you may be correct
that my "EFS/Group Policy" issue was just a symptom of the problem, and the
actual problem was my DNS infrastructure configuration.

In my case, both server A and server B pointed at themselves as the
"primary" DNS server. I also had the FSMO roles assigned to these two
domain controllers in a haphazard way (but I think the core problem was the
"primary" DNS misconfiguration.)

So based on your prompting, and based on a few Microsoft knowledgebase
articles, I performed the following reconfiguration:

0) I didn't have to do anything with respect to my ISP's DNS servers. They
were already configured as just "forwarders".

1) I reconfigured my FSMO role placement. (An insignificant step, but I
did it anyway.)

(see article 223346)
http://support.microsoft.com/default.aspx?scid=kb;en-us;223346&Product=win2000

2) I reconfigured my two domain controllers to point at only server A as
"primary". Furthermore, on server A, I removed server B as a secondary.
Restated, server A now has NO secondary DNS configured.

(see article 825036)
http://support.microsoft.com/default.aspx?scid=kb;en-us;825036&Product=win2000

3) On server B, I removed itself as secondary. Restated, server B now has
NO secondary DNS configured. I'm sure this is a debatable step, but not
being an expert, I'm following the Microsoft knowledgebase article. Anybody
feel free to chime in.

(see article 275278)
http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&Product=win2000

4) I updated my DHCP server configuration so that it hands out server A as
'primary' and server B as 'secondary'.

I won't have time to test this updated configuration with my "Disable EFS"
GPO for a few days, but I'll attempt and post the outcome!

Your error points to possibly a dns misconfiguration which is the number one reason
for AD problems. When you configure AD the first domain controller in the domain must
point to itself as it's preferred dns server in tcp/ip properties and additional
domain controllers need to point to the first domain controller [first in the list]
and themselves as their preferred dns servers. Then domain computers must point ONLY
to a W2K domain controller with the AD dns zone for the domain [they all do by
default]. Never list an ISP dns server in the tcp/ip properties of any domain
computer. The support tools netdiag and dcdiag can be used to check for proper domain
configuration with dcdiag reserved for domain controllers. If you change dns config
on a domain controller run netdiag /fix and then restart netlogon service on it and
view Event Viewer for problems.

What may have happened is that there was a replication problem with the new policy
due to a dns lookup failure. You can also check on GPO replication using the gpotool
and the replmon resource kit tool. Gpotool is quick and easy and will report
mismatches in policy between active domain controllers. The links below may
help. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp

I have two domain controllers, A & B...

A = Windows 2000 Server; PDC; DNS ('secondary' designation; Active Directory
integrated mode)
B = Windows Server 2003; DNS ('primary' designation; AD integrated mode)
domain functional level = "Native 2000"

I wanted to disable EFS (Encrypting File System) across the entire domain.
Of course, none of the Microsoft knowledgebase articles EXPLICITLY discuss a
MIXED environment of '2000 Server' and 'Server 2003'...

I have never messed with Group Policy before, so only the domain's default
Group Policy Object (GPO) existed. On server 'A', I created a brand new
GPO, moved it up in priority (above the default GPO), and followed Microsoft
article 222022 (for 2000 Server.) I then let that new GPO replicate, and
subsequently followed Microsoft article 324897 (for Server 2003) on server
'B'. I made no other changes to the new GPO, so theoretically, all other
policies within this new GPO were "not defined", and thus should not have
overrided anything crazy in the default GPO (so I would think...)

After this, everything got squirrelly, and I traced it down to something
related to DNS. On server 'A', the following was logged in the Application
Event Log:

Source = Userenv
EventID = 1000
Description = Windows cannot obtain the domain controller name for your
computer network. Return value (2146).

After I disabled the new GPO, the domain cleared itself up. ...Now, when I
make the 'disable EFS' modifications DIRECTLY to the DEFAULT GPO, my domain
behaves properly, and EFS is truly disabled on a domain-wide basis.

Can any gurus out there shed light on why my seemingly simple,
higher-priority GPO failed and caused the AD-DNS to fizzle out?

 

[Chris Largent]

Yes, definitely static IPs on both domain controllers (and even on a few of
our member servers.)

There is more than one way to configure dns on domain controllers and the important
thing is that they point to only AD domain controllers running dns for the domain and
that they are registering correctly in dns. What you have done should work, just
remember that if you ever retire the "chief" domain controller you want the remaining
domain controllers to point to an existing/functioning dc. Netdiag and dcdiag are two
great tools in determining if your AD configuration is firing on all eight cylinders
or not. I assume you also have static IP address for the domain controllers. Good
luck. --- Steve

Steve, I think you hit the nail on the head. I think you may be correct
that my "EFS/Group Policy" issue was just a symptom of the problem, and the
actual problem was my DNS infrastructure configuration.

In my case, both server A and server B pointed at themselves as the
"primary" DNS server. I also had the FSMO roles assigned to these two
domain controllers in a haphazard way (but I think the core problem was the
"primary" DNS misconfiguration.)

So based on your prompting, and based on a few Microsoft knowledgebase
articles, I performed the following reconfiguration:

0) I didn't have to do anything with respect to my ISP's DNS servers. They
were already configured as just "forwarders".

1) I reconfigured my FSMO role placement. (An insignificant step, but I
did it anyway.)

(see article 223346)
http://support.microsoft.com/default.aspx?scid=kb;en-us;223346&Product=win2000

2) I reconfigured my two domain controllers to point at only server A as
"primary". Furthermore, on server A, I removed server B as a secondary.
Restated, server A now has NO secondary DNS configured.

(see article 825036)
http://support.microsoft.com/default.aspx?scid=kb;en-us;825036&Product=win2000

3) On server B, I removed itself as secondary. Restated, server B now has
NO secondary DNS configured. I'm sure this is a debatable step, but not
being an expert, I'm following the Microsoft knowledgebase article. Anybody
feel free to chime in.

(see article 275278)
http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&Product=win2000

4) I updated my DHCP server configuration so that it hands out server A as
'primary' and server B as 'secondary'.

I won't have time to test this updated configuration with my "Disable EFS"
GPO for a few days, but I'll attempt and post the outcome!

Your error points to possibly a dns misconfiguration which is the

number
one reason

for AD problems. When you configure AD the first domain controller in

the
domain must

point to itself as it's preferred dns server in tcp/ip properties and additional
domain controllers need to point to the first domain controller [first

in
the list]

and themselves as their preferred dns servers. Then domain computers

must
point ONLY

to a W2K domain controller with the AD dns zone for the domain [they

all
do by

default]. Never list an ISP dns server in the tcp/ip properties of any domain
computer. The support tools netdiag and dcdiag can be used to check

for
proper domain

configuration with dcdiag reserved for domain controllers. If you

change
dns config

on a domain controller run netdiag /fix and then restart netlogon

service
on it and

view Event Viewer for problems.

What may have happened is that there was a replication problem with

the
new policy

due to a dns lookup failure. You can also check on GPO replication

using
the gpotool

and the replmon resource kit tool. Gpotool is quick and easy and will report
mismatches in policy between active domain controllers. The links

below
may

help. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp

"Chris Largent" <[email protected]>

wrote
in message

I have two domain controllers, A & B...

A = Windows 2000 Server; PDC; DNS ('secondary' designation; Active Directory
integrated mode)
B = Windows Server 2003; DNS ('primary' designation; AD integrated mode)
domain functional level = "Native 2000"

I wanted to disable EFS (Encrypting File System) across the entire domain.
Of course, none of the Microsoft knowledgebase articles EXPLICITLY discuss a
MIXED environment of '2000 Server' and 'Server 2003'...

I have never messed with Group Policy before, so only the domain's default
Group Policy Object (GPO) existed. On server 'A', I created a brand new
GPO, moved it up in priority (above the default GPO), and followed Microsoft
article 222022 (for 2000 Server.) I then let that new GPO

replicate,
and

subsequently followed Microsoft article 324897 (for Server 2003) on server
'B'. I made no other changes to the new GPO, so theoretically, all other
policies within this new GPO were "not defined", and thus should not have
overrided anything crazy in the default GPO (so I would think...)

After this, everything got squirrelly, and I traced it down to something
related to DNS. On server 'A', the following was logged in the Application
Event Log:

Source = Userenv
EventID = 1000
Description = Windows cannot obtain the domain controller name for your
computer network. Return value (2146).

After I disabled the new GPO, the domain cleared itself up. ...Now, when I
make the 'disable EFS' modifications DIRECTLY to the DEFAULT GPO, my domain
behaves properly, and EFS is truly disabled on a domain-wide basis.

Can any gurus out there shed light on why my seemingly simple,
higher-priority GPO failed and caused the AD-DNS to fizzle out?

 

[Chris Largent]

Yep, this was the fundamental problem (i.e, incorrect Domain Controller DNS
configuration.) Subsequent to my posted corrections, my "Disable EFS"
custom GPO is now working perfectly.

Thanks again Steve!

Steve, I think you hit the nail on the head. I think you may be correct
that my "EFS/Group Policy" issue was just a symptom of the problem, and the
actual problem was my DNS infrastructure configuration.

In my case, both server A and server B pointed at themselves as the
"primary" DNS server. I also had the FSMO roles assigned to these two
domain controllers in a haphazard way (but I think the core problem was the
"primary" DNS misconfiguration.)

So based on your prompting, and based on a few Microsoft knowledgebase
articles, I performed the following reconfiguration:

0) I didn't have to do anything with respect to my ISP's DNS servers. They
were already configured as just "forwarders".

1) I reconfigured my FSMO role placement. (An insignificant step, but I
did it anyway.)

(see article 223346)
http://support.microsoft.com/default.aspx?scid=kb;en-us;223346&Product=win2000

2) I reconfigured my two domain controllers to point at only server A as
"primary". Furthermore, on server A, I removed server B as a secondary.
Restated, server A now has NO secondary DNS configured.

(see article 825036)
http://support.microsoft.com/default.aspx?scid=kb;en-us;825036&Product=win2000

3) On server B, I removed itself as secondary. Restated, server B now has
NO secondary DNS configured. I'm sure this is a debatable step, but not
being an expert, I'm following the Microsoft knowledgebase article. Anybody
feel free to chime in.

(see article 275278)
http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&Product=win2000

4) I updated my DHCP server configuration so that it hands out server A as
'primary' and server B as 'secondary'.

I won't have time to test this updated configuration with my "Disable EFS"
GPO for a few days, but I'll attempt and post the outcome!

Your error points to possibly a dns misconfiguration which is the number one reason
for AD problems. When you configure AD the first domain controller in

the
domain must

point to itself as it's preferred dns server in tcp/ip properties and additional
domain controllers need to point to the first domain controller [first

in
the list]

and themselves as their preferred dns servers. Then domain computers

must
point ONLY

to a W2K domain controller with the AD dns zone for the domain [they all do by
default]. Never list an ISP dns server in the tcp/ip properties of any domain
computer. The support tools netdiag and dcdiag can be used to check for proper domain
configuration with dcdiag reserved for domain controllers. If you change dns config
on a domain controller run netdiag /fix and then restart netlogon

service
on it and

view Event Viewer for problems.

What may have happened is that there was a replication problem with the new policy
due to a dns lookup failure. You can also check on GPO replication using the gpotool
and the replmon resource kit tool. Gpotool is quick and easy and will report
mismatches in policy between active domain controllers. The links below may
help. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp

 

[Steven Umbach]

Great Chris. Thanks for posting back your results. --- Steve

Yep, this was the fundamental problem (i.e, incorrect Domain Controller DNS
configuration.) Subsequent to my posted corrections, my "Disable EFS"
custom GPO is now working perfectly.

Thanks again Steve!

Steve, I think you hit the nail on the head. I think you may be correct
that my "EFS/Group Policy" issue was just a symptom of the problem, and the
actual problem was my DNS infrastructure configuration.

In my case, both server A and server B pointed at themselves as the
"primary" DNS server. I also had the FSMO roles assigned to these two
domain controllers in a haphazard way (but I think the core problem was the
"primary" DNS misconfiguration.)

So based on your prompting, and based on a few Microsoft knowledgebase
articles, I performed the following reconfiguration:

0) I didn't have to do anything with respect to my ISP's DNS servers. They
were already configured as just "forwarders".

1) I reconfigured my FSMO role placement. (An insignificant step, but I
did it anyway.)

(see article 223346)
http://support.microsoft.com/default.aspx?scid=kb;en-us;223346&Product=win2000

2) I reconfigured my two domain controllers to point at only server A as
"primary". Furthermore, on server A, I removed server B as a secondary.
Restated, server A now has NO secondary DNS configured.

(see article 825036)
http://support.microsoft.com/default.aspx?scid=kb;en-us;825036&Product=win2000

3) On server B, I removed itself as secondary. Restated, server B now has
NO secondary DNS configured. I'm sure this is a debatable step, but not
being an expert, I'm following the Microsoft knowledgebase article. Anybody
feel free to chime in.

(see article 275278)
http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&Product=win2000

4) I updated my DHCP server configuration so that it hands out server A as
'primary' and server B as 'secondary'.

I won't have time to test this updated configuration with my "Disable EFS"
GPO for a few days, but I'll attempt and post the outcome!

Your error points to possibly a dns misconfiguration which is the number one reason
for AD problems. When you configure AD the first domain controller in

the
domain must

point to itself as it's preferred dns server in tcp/ip properties and additional
domain controllers need to point to the first domain controller [first

in
the list]

and themselves as their preferred dns servers. Then domain computers

must
point ONLY

to a W2K domain controller with the AD dns zone for the domain [they all do by
default]. Never list an ISP dns server in the tcp/ip properties of any domain
computer. The support tools netdiag and dcdiag can be used to check for proper domain
configuration with dcdiag reserved for domain controllers. If you change dns config
on a domain controller run netdiag /fix and then restart netlogon

service
on it and

view Event Viewer for problems.

What may have happened is that there was a replication problem with the new policy
due to a dns lookup failure. You can also check on GPO replication using the gpotool
and the replmon resource kit tool. Gpotool is quick and easy and will report
mismatches in policy between active domain controllers. The links below may
help. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp

 

[Chris Largent]

Ummm...errr...uh oh... I posted my results too soon. :-(

So to be clear for any future readers of this thread, my DNS configuration
wasn't actually the problem after all. Nevertheless, I'm still happy with
my new "clean" DNS infrastructure!

It turns out that my particular GPO/EFS-related problem doesn't appear until
a domain user actually ATTEMPTS to encrypt a file on one of my Windows 2000
Server shares. (Note that I wrote 2000 Server...not to be confused with
Server 2003.)

When a Windows XP user attempts to use EFS on their local workstation,
everything works fine, and Windows XP properly honors the Windows Server
2003 setting and disallows the user from encrypting local files. (Note that
this time I wrote Server 2003.) However, when the same user attempts to
utilize EFS on one of our Windows 2000 Server shares, the user's XP Explorer
session locks up, and the Windows 2000 Server practically grinds to a halt.
When I subsequently try to log into the 2000 Server, it takes several
minutes before the login dialog is presented, and the server no longer
thinks that it belongs to a domain. Even when the login dialog is finally
displayed, I can't log into the server because the server doesn't have a
Local Administrator account (remember that it's a domain controller.)

To get out of this predicament, I had to delete my higher-priority "Disable
EFS" GPO on the domain controller that I could still access (Windows Server
2003), and then remotely reboot the Windows 2000 Server by using Computer
Management on the Server 2003 server. Once rebooted--and with the 'Disable
EFS' GPO gone--the 2000 Server is stable again. Yes, the same DNS-related
error is seen in the log (i.e., it was logged once the server went haywire
after the encryption attempt.)

So I've gone back to disabling EFS via the "Default Domain Policy" GPO.
This works and I'm not going to worry about it anymore. My gut tells me
that this is a mixed 2000-2003 domain controller issue, SPECIFICALLY related
to EFS.

Points to remember:
- Infrastructure works 100% until a user actually attempts to encrypt a file
(only on the Windows 2000 Server.)
- The problem only occurs when using a higher-priority GPO to disable EFS.
Using the default domain GPO to accomplish this end causes no problems
whatsoever.

Yep, this was the fundamental problem (i.e, incorrect Domain Controller DNS
configuration.) Subsequent to my posted corrections, my "Disable EFS"
custom GPO is now working perfectly.

Thanks again Steve!

message news:[email protected]...

Steve, I think you hit the nail on the head. I think you may be correct
that my "EFS/Group Policy" issue was just a symptom of the problem, and the
actual problem was my DNS infrastructure configuration.

In my case, both server A and server B pointed at themselves as the
"primary" DNS server. I also had the FSMO roles assigned to these two
domain controllers in a haphazard way (but I think the core problem was the
"primary" DNS misconfiguration.)

So based on your prompting, and based on a few Microsoft knowledgebase
articles, I performed the following reconfiguration:

0) I didn't have to do anything with respect to my ISP's DNS servers. They
were already configured as just "forwarders".

1) I reconfigured my FSMO role placement. (An insignificant step, but I
did it anyway.)

(see article 223346)

http://support.microsoft.com/default.aspx?scid=kb;en-us;223346&Product=win2000

2) I reconfigured my two domain controllers to point at only server A as
"primary". Furthermore, on server A, I removed server B as a secondary.
Restated, server A now has NO secondary DNS configured.

(see article 825036)

http://support.microsoft.com/default.aspx?scid=kb;en-us;825036&Product=win2000

3) On server B, I removed itself as secondary. Restated, server B now has
NO secondary DNS configured. I'm sure this is a debatable step, but not
being an expert, I'm following the Microsoft knowledgebase article. Anybody
feel free to chime in.

(see article 275278)

http://support.microsoft.com/default.aspx?scid=kb;en-us;275278&Product=win2000

4) I updated my DHCP server configuration so that it hands out server A as
'primary' and server B as 'secondary'.

I won't have time to test this updated configuration with my "Disable EFS"
GPO for a few days, but I'll attempt and post the outcome!

Your error points to possibly a dns misconfiguration which is the

number
one reason

for AD problems. When you configure AD the first domain controller in

the
domain must

point to itself as it's preferred dns server in tcp/ip properties and additional
domain controllers need to point to the first domain controller [first

in
the list]

and themselves as their preferred dns servers. Then domain computers

must
point ONLY

to a W2K domain controller with the AD dns zone for the domain [they

all
do by

default]. Never list an ISP dns server in the tcp/ip properties of any domain
computer. The support tools netdiag and dcdiag can be used to check

for
proper domain

configuration with dcdiag reserved for domain controllers. If you

change
dns config

on a domain controller run netdiag /fix and then restart netlogon

service
on it and

view Event Viewer for problems.

What may have happened is that there was a replication problem with

the
new policy

due to a dns lookup failure. You can also check on GPO replication

using
the gpotool

and the replmon resource kit tool. Gpotool is quick and easy and will report
mismatches in policy between active domain controllers. The links

below
may

help. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;291382

http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/gpotool-o.asp

wrote
in message replicate,
and