Event ID 534 After DCPROMO

  • Thread starter Thread starter Will
  • Start date Start date
W

Will

I have a tough one. We have a lab domain controller running Windows 2000
and we wanted to bring up a second lab domain controller on Windows 2003,
with the intent to transfer all roles to the Windows 2003 and eventually
discard the Windows 2000 domain controller. We upgraded the Windows 2000
forest and server schema with ADPREP. We performed the DCPROMO on Windows
2003, which seems to complete without error. However what is telling is
that after completing there is no DNS server and there is no fully populated
SYSVOL share (so replication failed). I added the DNS server manually and
that eventually is up and running, but replication never works.

On the original Windows 2000 domain controller, four times a minute there
are very generic event ID: 534 messages complaining about a user being
denied a required login type. I tried the following corrections:

1) I added Everyone to the "Access this computer from the network" user
right in Domain Controller Security policy group policy on both machines.

2) I modified the file ACLs on the SYSVOL volume to include both ENTERPRISE
DOMAIN CONTROLLERS and <domain>\Domain Controllers with Modify permissions
on both domain controllers.

3) I added Everyone to all three unique login types on the original domain
controller:

Login as service
Login as batch job
Login locally

The event ID continues unabated by any of these changes.

4) I set Auditing on the file system to show any kind of failure event, and
I turned on auditing object access failure in group policy. However no
specific file access message turns up. Probably this means the login fails
before any file access is attempted.

I brought up a sniffer and confirmed that the contacts are indeed coming
from the new Windows 2003 domain controller. The failure is on RPC. It
does one RPC and then follows up with a second one, and the second one is
failing.

I can post UUIDs for the RPCs and additional details from the sniffer trace
if requested, but I'm hopeful that the above might be enough to suggest some
other possible solutions to try first.
 
Will, Will, Will . . .
"a user" is not getting grant of a login right . . .
Do you suppose it might help us if we knew what "a user"
and which login right ?

I for one do not have in mind the text for 534 which may
or may not be as generic as you see it.

So, now the (apparently) you have them with a shared DNS
support is replication working ?

Did you verify health of your prior AD by running dcdiag and
netdiag on the W2k DC prior to the dcpromo attempt ?
What are they now saying when run on the old W2k DC?

DCpromo has a dependency on NetBT. You do have
a WINS if these are not on a single segment. You did
not cripple NetBT on either box did you?
 
Here is the exact text as it shows on the original domain controller:

Logon Failure:
Reason: The user has not been granted the requested
logon type at this machine
User Name:
Domain:
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name: -

I believe that since this is related to an attempted file replication from a
new domain controller, that you can probably assume that the "user" is
SYSTEM on the new domain controller.

As far as which login right, how exactly do I determine that? That's what
is so frustrating here. The Windows 2000 event viewer messages can at times
be nearly worthless. Had they taken the time to document which right is in
question, there is a good chance I could have solved it immediately.

The new domain controller has an Active Directory DNS up and running but I
don't believe Active Directory replication is working.

DCDIAG is showing failed replications events from the new domain controller
with the error "Access is Denied (5)" So that seems pretty consistent
with the logon failure messages.

Both domain controllers are on a single segment. No WINS is present.

Regarding the dependency, you are saying that DCPromo requires more than
just the NetBIOS TCP/IP Helper service, but actually requires NetBIOS to be
active? Just by coincidence, both machines do have NetBIOS over TCP
enabled.

--
Will


Roger Abell said:
Will, Will, Will . . .
"a user" is not getting grant of a login right . . .
Do you suppose it might help us if we knew what "a user"
and which login right ?

I for one do not have in mind the text for 534 which may
or may not be as generic as you see it.

So, now the (apparently) you have them with a shared DNS
support is replication working ?

Did you verify health of your prior AD by running dcdiag and
netdiag on the W2k DC prior to the dcpromo attempt ?
What are they now saying when run on the old W2k DC?

DCpromo has a dependency on NetBT. You do have
a WINS if these are not on a single segment. You did
not cripple NetBT on either box did you?
Click to expand...
 
Will said:
Here is the exact text as it shows on the original domain controller:

Logon Failure:
Reason: The user has not been granted the requested
logon type at this machine
User Name:
Domain:
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Workstation Name: -

I believe that since this is related to an attempted file replication from
a
new domain controller, that you can probably assume that the "user" is
SYSTEM on the new domain controller.

As far as which login right, how exactly do I determine that? That's
what
is so frustrating here. The Windows 2000 event viewer messages can at
times
be nearly worthless. Had they taken the time to document which right is
in
question, there is a good chance I could have solved it immediately.
Click to expand...

the message states
Logon Type: 3
Click to expand...
which means network login
The new domain controller has an Active Directory DNS up and running but I
don't believe Active Directory replication is working.

DCDIAG is showing failed replications events from the new domain
controller
with the error "Access is Denied (5)" So that seems pretty consistent
with the logon failure messages.
Click to expand...

I am thinking that the event message has no info about account
as it does not know how to understand the credentials being
presented. That in turn is likely due to failed replication of the
accounts along with the rest of the the AD partitions' content.
Both domain controllers are on a single segment. No WINS is present.
Click to expand...
so they should be able to locate each other with downlevel methods
Regarding the dependency, you are saying that DCPromo requires more than
just the NetBIOS TCP/IP Helper service, but actually requires NetBIOS to
be
active? Just by coincidence, both machines do have NetBIOS over TCP
enabled.
Click to expand...
Good the NetBT (NetBIOS over TCP) is enabled. The interface of
each machine also needs to have MS File and Print bound to it (that
is, it needs to show but does not need to be checked when looking
at protocols on the cards) and needs to have MS Networking
Client checked. The binding of the F&P is what actually triggers
install of RCP.

It seems like you may be toasted in an in-between limbo.
If you were to make sure that both servers have their needed
SRV records in the shared DNS, and then that the new and
old see replication links with each other, it may be worth a
try at forcing replication over the links.
 
Since this is a lab environment, maybe we should focus on trying to redo the
DCPROMO but make it work right initially?

What is strange to me is that before the DCPROMO I can login as domain
administrator on the member server and I can see the SYSVOL share and its
content. So if I am running the DCPROMO in the user context of the domain
administrator, and I can see these files manually, then why can't DCPROMO
running in the same user context do the initial setup of the new domain
controller's SYSVOL?

Something is failing during the DCPROMO and not being reported clearly. Is
there a logfile associated with DCPROMO, or some argument that will generate
additional debug information? I noticed there is an "Advanced" mode
argument /ADV; could that help? If I could see the step at which DCPROMO
is failing, and the specific resource it is trying to get at that moment, it
might give some clues.

Is there a checklist somewhere of settings and configurations for existing
domain controllers that must be in place before DCPROMO is run?

For now, to reset things back to their original state, I guess I will have
to do a DCPROMO /forceremoval on the new domain controller? On the
original domain controller, I would need to go delete the new domain
controller's DNS and AD objects with ADSI on the old domain controller?
 
Back
Top