No announcement yet.

adprep giving us issues

  • Filter
  • Time
  • Show
Clear All
new posts

  • adprep giving us issues

    Thanks in advance…..

    Frustration settling in as I attempt to run adprep to allow a 2003 DC on 2000 AD environment. Have attempted couple things and read several KB articles with no luck. The following is my story….

    Have 2000 AD environment with two DC both with SP4 installed. One DC holds all FSMO roles which I will call Server1. I’ll call our domain MYDOMAIN (mydomain.local).

    1. Ran dcdiag.

    Only issue is that Server1 is not advertising as a time server. Which is fine since I use other means for time.

    2. Ran netdiag

    Only thing that sticks out is a warning for DNS test in which “Cannot find a primary authoritative DNS server for the name Server1.mydomain”. Server1 is set up as a DNS server also.

    3. Backup machine.

    4. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\NTDS\Parameters

    Value Name: Schema Update Allowed
    Data Type: REG_DWORD
    Base: Binary
    Value Data: Type 1 to enable this feature, or 0 (zero) to disable it.

    5. Logged off and then on with account that is in the following groups:

    Domain Admins

    Domain Users

    Enterprise Admins

    Schema Admins (Set Primary Group)

    6. Disabled outbound replication on both DC.

    repadmin /options +DISABLE_OUTBOUND_REPL

    7. Threw in Windows 2003 Server CD and map to i386 dir within command prompt.

    8. Type adprep /forestprep

    9. Type C and then press ENTER to continue. Otherwise, type any other key and press ENTER to quit.

    That’s as far as I can get. The following is the ending for the ADPrep.log:

    Adprep was about to call the following LDAP API. ldap_search_s(). The base entry to start the search is CN=UID,CN=Schema,CN=Configuration,DC=mydomain,DC=l ocal.

    LDAP API ldap_search_s() finished, return code is 0x20

    Adprep successfully determined whether Microsoft Windows Services for UNIX (SFU) is installed or not. If adprep detected SFU, adprep also verified that Microsoft hotfix Q293783 for SFU has been applied.

    Adprep was unable to upgrade the schema on the schema master.


    The schema will not be restored to its original state.

    [User Action]

    Check the Ldif.err log file in the C:\WINNT\system32\debug\adprep\logs\20060907182017 directory for detailed information.

    Adprep set the value of registry key System\CurrentControlSet\Services\NTDS\Parameters\ Schema Update Allowed to 1

    Adprep was unable to update forest-wide information.


    Adprep requires access to existing forest-wide information from the schema master in order to complete this operation.

    [User Action]

    Check the log file, Adprep.log, in the C:\WINNT\system32\debug\adprep\logs\20060907182017 directory for more information.

    No *.err file created.


    Opened Connection to Server1

    SSPI Bind succeeded

    Found Naming Context DC=mydomain,DC=local

    Found Naming Context CN=Schema,CN=Configuration,DC=mydomain,DC=local

    Found Naming Context CN=Configuration,DC=mydomain,DC=local

    Current Schema Version is 13

    Upgrading schema to version 30

    ERROR: Failed to transfer the schema FSMO role: 52 (Unavailable).

    If the error code is "Insufficient Rights", make sure you are logged in as a member of the schema admin group.

    I am baffled now and any help is much appreciated.

  • #2
    Re: adprep giving us issues

    Hi Brian,

    I think it was actually Daniel that stumbled upon something simmilar. We both tried to debug the failing schema update, but was solved the issue was transferring the Schema master FSMO to another DC and running adprep /forestprep on it instead of the DC that refused to update the schema.
    You might want to give this a try.
    Guy Teverovsky
    "Smith & Wesson - the original point and click interface"


    • #3
      Re: adprep giving us issues

      thanks for the reply, that might be a little too risky for our line of work, but were trying a couple other things. on failure we got when running a dcdiag was no time server present, because we use our routers here for timing rather then the DC's. So we started the time service now and we'll see if that lets us do it. thanks for your help