Hi,
Yesterday we have had a crash server our principal hard disk was crashed and
we buy new and instlled again the Windows 2000 system. We have another
Domaincontroller and we could connect to that domain, make dcpromo and
everything was ok. But now we get every 5 minutes this error:
So, we didn't demote the server, beacuse was the hard disk was totally
damage. We simply put the new hard disk and install the server after that we
did dcpromo and we configurate the server like same old one, and now we have
this problem, the new one with the same like the old one and already
promoted to the same DC like the old one, doesn't work because the old one
is still in the database of the AD, but I don't have many expierence with
this AD and now I don't know what I should do with the new one. Why it is
possible to promoted with the same name and configuration like the old
server, but doesn't work really good. I don't have any idea to resolve that,
ok I would like to demote the older server in somehow and/or says to the new
one that, it is again Operation Master or something like that.
Event ID: 16650 Query: SAM
This is what we found on www.eventid.net:
Event ID: 16650
Source SAM
Type Error
Description The account-identifier allocator failed to initialize
properly. The record data contains the NT error code that caused the
failure. Windows 2000 may retry the initialization until it succeeds; until
that time, account creation will be denied on this Domain Controller. Please
look for other SAM event logs that may indicate the exact reason for the
failure.
From a newsgroup post: "I just had this situation last week and I got
out of it successfully. It sounds like you took the route I did when
retiring my old server. This is to say that you most likely never demoted
the old server gracefully and it still appears in you AD database. There is
no need to worry. If you are no longer planning to have the retired server
in your domain, transfer the FSMO roles to the new server and then use
ntdsutil.exe to cleanup the Metadata of the outgoing server. Read these
three articles closely: Q216498, Q223787 and Q298450.
If you did demote the old machine before reinstalling, run "netdom
query fsmo" from the command prompt to determine who owns the RID master
role. Netdom.exe is part of the support tools that comes with your server
media. Sometimes FSMO roles do not transfer gracefully to another replica
when you demote a DC that holds a role. In that, case you will need to seize
the role".
From a newsgroup post: "Check and make sure that the FSMO role RID
Master is available and operational in the domain. By default, this is
created on the first DC that was created in the domain. You can determine
who the RID Master is supposed to be by bringing up AD Users and Computers
and right clicking on the domain and selecting Operations Masters. The RID
role should be on a DC in your domain. If it is not, you may have removed
the DC that it was originally on, but did not transfer it before the
removal. In this case, you will have to use ntdsutil to seize the role to a
current operational DC
Adrian Grigorof
As per Microsoft: This behavior can occur because the RID Master FSMO
is unavailable or fails to replicate. The Domain Controller cannot obtain
and initialize the RID pool. This behavior can also occur when the User
Right "Access this computer from the network" has not been given to the
appropriate groups such as "Enterprise Domain Controllers" or "Authenticated
Users". See the link below for more details.
Nikolaus Porkert
See Q255504 for instructions on using NDSUTIL.
Our Approach This information is only available to subscribers. An
example of "approach" is available here.
Links Q216498 , Q223787 , Q248410 , Q255504 , Q285836 , Q298450
THANKS and I hope I will have some lucky with this!!!
Regards,
Luciano
