none
why does one machine fail and the other not fail?

    Question

  • I had a W2K domain controller which I cloned using VMWare.  Not much has changed since the time of the clone except for some disabled usernames and changed passwords.  Two users happened to leave during that time and their accounts were disabled in Active Directory.  To keep current with that, I disabled their accounts in the W2K Clone as well. 

    I checked to see if the clone was still working the other day.  I pulled one of the workstations (from someone who's account was disabled) from the live domain and plugged it into a hub with the clone DC. 

    I expected it to work fine but it didn't.  I cannot log into the clone for some reason and it keeps telling me that the "trust relationship between this workstation and the primary domain failed".  Yet when I plug in a random laptop to the same hub I can log in easily.  In the event viewer of the cloned DC I see Netlogon errors with Event ID 5722 that say "The session setup  from the computer XYZ failed to authenticate.  The name of the account referenced in the security database is XYZ$.  The following error occurred.  Access is denied".

    Why am I able to log in at one machine but not the other??  Both PCs were on the domain at the time of the cloning process and both machines are indeed in Active Directory and DNS.  I did not add/remove either machine from the domain either.  The Active Directory in the live W2K DC and the cloned W2K DC should be similar. 

    Yet one workstation simply cannot authenticate while the other has no issues whatsoever.  Does it have anything to do with the fact that disabling/changing the password of a user account on that machine somehow caused its SID to change?? 


    • Edited by Banc0 Monday, April 09, 2012 9:32 PM
    Monday, April 09, 2012 9:29 PM

Answers

  • BartonUrp,

    I originally mentioned the machine account password was possibly to blame.

    ALso, please keep in mind, the client initiates the password, not the domain or any of the DCs.

    So if the client has a specific password, but the domain doesn't, then the channel will not get established, getting that familiar "...channel is broken..." or "trust is broken..." error messages.

    But there are other factors involved going on in the background, such as Kerberos' 5 minute time skew tolerance is a huge factor, not just a machine account password issue that may have been changed during the process.

    .

    That would explain why one machine works and the other does not.  Is there any way of getting that password information and importing it into the cloned DC?

    No, it can't be exported or imported. The password changes every 30 days, intitiated by the Netlogon service on the client, not the domain.

    .

    Another question is what if a user on the active domain goes away on vacation for 3 months let's say and comes back.  Is his laptop able to rejoin the domain or will the password already have expired?  What happens exactly?

    The following blogs will tell you exactly what happens with the machine account password.

    Machine Account Password Process, by DS Team - NedPyle [MSFT], Manish Singh [MSFT], 15 Feb 2009
    http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

    Windows machine account passwords and VM snapshots, By sudhakan [MSFT], 7 Jan 2010
    [Interesting set of tools to test and verify the machine account password]
    http://blogs.msdn.com/b/sudhakan/archive/2010/01/07/experimenting-with-windows-machine-account-passwords-and-vm-snapshots.aspx

    .

    .

    And as far as your previous post:

    Just to clarify:

    The clone runs INDEPENDENTLY of the actual production network, for obvious reasons.

    The intention is to clone the Win2K DC, work on the clone to make the necessary upgrade to Win2K3, then remove the Win2K DC and put the clone Win2K3 version of the DC into the production network.

    If I remove a machine off the production domain and join it to the cloned domain, then what is the point?  I'd have to do this for 100 other machines.  The objective is to swap the old DC for the new clone and have all other member servers and workstations work without a hitch.  They should act as if nothing has happened.

    The question now is why does one machine log onto the domain while the other has errors?  Both machines existed on the live domain at the time of the cloning process.

    Someone mentioned that the password for the computer account may have expired.  What would be the mechanism or time to live period for this computer account password?  Is there any way to reset this password or get them to match properly in AD?  Or is it better to just grab a brand new clone to keep things current?

    I'm kind of surprised that you are using this method for a DR or backup system. This just doesn't work, as Meinolf said, like it did with NT4 BDCs, where you could have done exactly this. There are too many variables, including Kerberos' time skew tolerance. The links I posted in this post above, explains this in more detail.

    .

    I agree with Meionolf that to just install an additional DC in a separate DR site, reduce replication schedule to that Site, don't make it a GC, reduce the weight and priority on it, etc. This way it keeps in sync with the rest of the domain, etc, and if you need to bring it back in prod, no problem.

    .

    And one more thing, cloning has never been supported. I'm somewhat surprised that PSS would provide a custom ntdsa.DLL to overcome this. Tweaked DLL and other methods are just not production friendly methods.

    I think it's just easier to setup a DC in a DR Site, and not worry about it, this way you know it works, and provides peace of mind.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    • Proposed as answer by Meinolf WeberMVP Tuesday, April 10, 2012 4:16 PM
    • Marked as answer by Banc0 Wednesday, April 11, 2012 7:33 PM
    Tuesday, April 10, 2012 3:29 PM

All replies

  • Hi,

    What I can tell you is that disabling user accounts has no bearing on the error you've described. This error only appears when the password for the client computer's logon account (yes, computers log on just the same as we do with our user accounts) has expired (or been reset, etc).

    What you're describing is expected behaviour if I'm making the correct assumption about your information above in that you've made a clone of the existing domain controller and are running it completely independantly of the original domain (which is the only responsible scenario I can think of).

    You're not going to be able to just flick machines in between the original and replica domains unless you address the password expiry configuration in both, and I'd strongly recommend that you do not do this as is reduces security for obvious reasons. Nevertheless, if you want to do this, you can do so through group policy with the following setting:

    Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options: Domain Member: Disable machine account password changes = Enabled

    You'd have to use this in conjunction with setting the computer account object to not expire. Just applying one change or the other won't help.

    To minimise the effect, you could create a new OU, only link the group policy object to that, and move just one or two computers into that OU, remembering to ensure the computer objects never expire. It may be wise to re-capture a new clone after you've made these changes though so they're also present (and the accounts have the same passwords again) on the duplicated environment.

    Cheers,
    Lain

    Monday, April 09, 2012 11:51 PM
  • Error ""trust relationship between this workstation and the primary domain failed" Occurs due to following reasons,.

    1. Single SID has been assigned to multiple computers.
    2. If the Secure Channel is Broken between Domain controller and workstations
    3. If there are no SPN or DNSHost Name mentioned in the computer account attributes
    4. Outdated NIC Drivers.

    Refer below link which explains how to troubleshoot this behaviour.

    http://social.technet.microsoft.com/wiki/contents/articles/9157.trust-relationshitp-between-workstation-and-primary-domain-failed-en-us.aspx

    I suspect this behaviour should be because of Secure Channel broken between workstation and the domain controller . probably you need to reset the computer account(Refer above link which explains how to reset computer account)

    Regards,

    _Prashant_


    MCSA|MCITP SA|Microsoft Exchange 2003 Blog - http://prashant1987.wordpress.com Disclaimer: This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Tuesday, April 10, 2012 2:55 AM
  • Hi,

    The error "The trust relationship between the workstation and the domain failed" normally occurs due to the broken secure channel between the DC and domain clients.

    You said, when I plug in a random laptop to the same hub I can log in easily.
    Problem with the particular workstation, to resolve this error, you can simply disjoin the problem machine from domain and join it back to domain.

    Also I would suggest to run dcdiag /q for any error.

    Broken secure channel reasons:
    SID conflict of the machine, SYSPREP is not performed on the machine which is prepared using clone/image/snapshot, hostname conflict, duplicate SPN, network connectivity or dns probelm.


    Best Regards,

    Abhijit Waikar.
    MCSA 2003 | MCSA:Messaging | MCTS | MCITP:Server Administrator | Microsoft Community Contributor | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Tuesday, April 10, 2012 4:08 AM
  • It might also pay to clarify whether you're running the cloned domain controller as a member of the production domain or whether you're running it in isolation, such as a pre-production or test environment.

    To me, it sounded like the former. Some of these suggestions only practically apply to the latter.

    I didn't bother saying this with my original response because I don't know if you have this option, but it would have made more sense to virtualise the cloned domain controller and simply build virtual clients as applicable. But since you're talking about separate physical switching, I'm guessing this isn't an option at this point in time.

    Cheers,
    Lain

    Tuesday, April 10, 2012 4:17 AM
  • I would agree with Lain. Before we decide what to do next, we would need to know whether you are running the cloned DC as a member of the same domain or running it as an isolated domain. If you are using it as a member domain controller in the existing domain you could try the solutions suggested by Abhijit or Prashant in the previous posts.

    Regards, Rahul A MCITP:MS SQL 2008 Dev, MCITP:EA, MCTS, MCSA, ITIL V3 My Blog: http://windowsdiary.wordpress.com/

    Tuesday, April 10, 2012 4:59 AM
  • Just to add, moving a member from the prod domain to a cloned domain, the cloned DC's machine secure channel password of what it believes the member should be, is not, since the member would have been synced up with its own home domain. If a restart occured on the client or DC, the secure channel password would also have changed, so even if the client was restarted once on the prod side, that would throw it off trying to log into the clone.

    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, April 10, 2012 5:01 AM
  • Hello,

    using a clone for LAB is a good idea. But NEVER connect the clone to the production network.

    Moving  machines between production and lab isn't either a good idea as exactly what you see can/will happen. If you like to move machines between the domains remove them from the domain and join it to the other one. But the RECOMMENDED way is to have one machine allways in the lab.

    In your case unjoin and rejoin the computer in the lab, make sure it use the correct DNS server on the NIC.


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Tuesday, April 10, 2012 6:38 AM
  • Just to clarify:

    The clone runs INDEPENDENTLY of the actual production network, for obvious reasons. 

    The intention is to clone the Win2K DC, work on the clone to make the necessary upgrade to Win2K3, then remove the Win2K DC and put the clone Win2K3 version of the DC into the production network. 

    If I remove a machine off the production domain and join it to the cloned domain, then what is the point?  I'd have to do this for 100 other machines.  The objective is to swap the old DC for the new clone and have all other member servers and workstations work without a hitch.  They should act as if nothing has happened.

    The question now is why does one machine log onto the domain while the other has errors?  Both machines existed on the live domain at the time of the cloning process. 

    Someone mentioned that the password for the computer account may have expired.  What would be the mechanism or time to live period for this computer account password?  Is there any way to reset this password or get them to match properly in AD?  Or is it better to just grab a brand new clone to keep things current?








    • Edited by Banc0 Tuesday, April 10, 2012 12:58 PM
    Tuesday, April 10, 2012 12:48 PM
  • Hello,

    there is no need for separation from the DC to update. This was old practice and recommended with NT4 in-place upgrades.

    For Windows AD the recommended options is to install a new OS DC/DNS/GC into the existing domain and transfer FSMO roles to the new OS DC. All details for upgrade to Windows server 2003 domains you'll find in http://msmvps.com/blogs/mweber/archive/2010/02/13/upgrading-an-active-directory-domain-from-windows-server-2000-to-windows-server-2003-or-windows-server-2003-r2.aspx

    And there is no problem following that way, this is the normal way of upgrading and swapping DCs that way, between lab and production for upgrade, will result in problems.

    Before you can install new OS DCs all DCs have the need for the schema upgrade that is the first step in a domain and all DCS should be up and running during the process so replication can occur.

    So please re-think your upgrade plan.


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Tuesday, April 10, 2012 12:56 PM
  • Meinolf:

    I understand that but I cannot promote the normal way.  There is a critical system AD object that is locked by SAM that cannot replicate during the upgrade.  The dcpromo process fails every single time.  I cannot bring a new DC into the domain normally.  I cannot even Install from Media, something that is only found in Windows 2003. 

    That is why it must be done this way.  This is the only way I can experiment and upgrade without putting the only DC left in the domain in jeopardy.  This is also the only way I can get Microsoft to support it. 

    I only have three options:

    1) conduct an in-place upgrade of the actual physical W2K DC and hope for the best

    2) create an entirely new domain, recreate every single object, container, etc then manually move every computer and server on the domain to it - a process which will take months or more

    3) clone the active DC, work on the clone, insert the clone into production, dcpromo other replicas and move all FSMO roles away from the clone to physical DCs

    4) Any other suggestions?






    • Edited by Banc0 Tuesday, April 10, 2012 1:43 PM
    Tuesday, April 10, 2012 1:07 PM
  • Domain member computers maintain secure channel with domain controllers, based on passwords which are changed by default in regular intervals. In the scenario above you are describing, the secure channel of client PC will get broken since the passwords maintained on production DCs is not synced with cloned DC in virtual environment.




    Best Regards,

    Sandesh Dubey.

    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Tuesday, April 10, 2012 1:20 PM
  • You mentioned that there is a critical system AD object that is locked by SAM that cannot replicate during the upgrade.What error message you get?

    Best Regards,

    Sandesh Dubey.

    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Tuesday, April 10, 2012 1:21 PM
  • Sandesh:

    That would explain why one machine works and the other does not.  Is there any way of getting that password information and importing it into the cloned DC? 

    Another question is what if a user on the active domain goes away on vacation for 3 months let's say and comes back.  Is his laptop able to rejoin the domain or will the password already have expired?  What happens exactly?

    ** DCPROMO fails with "Directory Object missing"

    The critical system object is the Built-In Administrator.  The attribute "isCriticalSystemObject" is set to FALSE.  If you try to change it to TRUE, it won't let you.  It says it is locked by SAM and you cannot change it.  During my work with the clone upgrade, MS was able to provide me with a tweaked version of ntdsa.dll and that allowed me to get into ADSIEDIT and change that attribute to TRUE.  The problem is the tweaked ntdsa.dll is unpredictable.  It may or may not work.

    • Edited by Banc0 Tuesday, April 10, 2012 1:30 PM
    Tuesday, April 10, 2012 1:22 PM
  • Hello,

    is that still the problem where you already have opened a call for?

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/98409b4e-6a83-4c81-8b40-fbef25f151f7/#f16bb03e-9588-4246-a252-3c7a8054ce70


    Best regards

    Meinolf Weber
    MVP, MCP, MCTS
    Microsoft MVP - Directory Services
    My Blog: http://msmvps.com/blogs/mweber/

    Disclaimer: This posting is provided AS IS with no warranties or guarantees and confers no rights.

    Tuesday, April 10, 2012 1:48 PM
  • Meinolf:

    Yes it's all related.  The issue now is with testing the clone.  But as somebody already pointed out, it's probably because one computer's domain password has changed.  That may explain why.

    Tuesday, April 10, 2012 1:50 PM
  • You can avoid this by disabling computer password changes, but you should be aware of potential security implications.

    More at http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

    I would not recommend to do the above.However as mentioned before you mentioned that there is a critical system AD object that is locked by SAM that cannot replicate during the upgrade.What error message you get?


    Best Regards,

    Sandesh Dubey.

    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator | My Blog

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.


    Tuesday, April 10, 2012 3:19 PM
  • BartonUrp,

    I originally mentioned the machine account password was possibly to blame.

    ALso, please keep in mind, the client initiates the password, not the domain or any of the DCs.

    So if the client has a specific password, but the domain doesn't, then the channel will not get established, getting that familiar "...channel is broken..." or "trust is broken..." error messages.

    But there are other factors involved going on in the background, such as Kerberos' 5 minute time skew tolerance is a huge factor, not just a machine account password issue that may have been changed during the process.

    .

    That would explain why one machine works and the other does not.  Is there any way of getting that password information and importing it into the cloned DC?

    No, it can't be exported or imported. The password changes every 30 days, intitiated by the Netlogon service on the client, not the domain.

    .

    Another question is what if a user on the active domain goes away on vacation for 3 months let's say and comes back.  Is his laptop able to rejoin the domain or will the password already have expired?  What happens exactly?

    The following blogs will tell you exactly what happens with the machine account password.

    Machine Account Password Process, by DS Team - NedPyle [MSFT], Manish Singh [MSFT], 15 Feb 2009
    http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

    Windows machine account passwords and VM snapshots, By sudhakan [MSFT], 7 Jan 2010
    [Interesting set of tools to test and verify the machine account password]
    http://blogs.msdn.com/b/sudhakan/archive/2010/01/07/experimenting-with-windows-machine-account-passwords-and-vm-snapshots.aspx

    .

    .

    And as far as your previous post:

    Just to clarify:

    The clone runs INDEPENDENTLY of the actual production network, for obvious reasons.

    The intention is to clone the Win2K DC, work on the clone to make the necessary upgrade to Win2K3, then remove the Win2K DC and put the clone Win2K3 version of the DC into the production network.

    If I remove a machine off the production domain and join it to the cloned domain, then what is the point?  I'd have to do this for 100 other machines.  The objective is to swap the old DC for the new clone and have all other member servers and workstations work without a hitch.  They should act as if nothing has happened.

    The question now is why does one machine log onto the domain while the other has errors?  Both machines existed on the live domain at the time of the cloning process.

    Someone mentioned that the password for the computer account may have expired.  What would be the mechanism or time to live period for this computer account password?  Is there any way to reset this password or get them to match properly in AD?  Or is it better to just grab a brand new clone to keep things current?

    I'm kind of surprised that you are using this method for a DR or backup system. This just doesn't work, as Meinolf said, like it did with NT4 BDCs, where you could have done exactly this. There are too many variables, including Kerberos' time skew tolerance. The links I posted in this post above, explains this in more detail.

    .

    I agree with Meionolf that to just install an additional DC in a separate DR site, reduce replication schedule to that Site, don't make it a GC, reduce the weight and priority on it, etc. This way it keeps in sync with the rest of the domain, etc, and if you need to bring it back in prod, no problem.

    .

    And one more thing, cloning has never been supported. I'm somewhat surprised that PSS would provide a custom ntdsa.DLL to overcome this. Tweaked DLL and other methods are just not production friendly methods.

    I think it's just easier to setup a DC in a DR Site, and not worry about it, this way you know it works, and provides peace of mind.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    • Proposed as answer by Meinolf WeberMVP Tuesday, April 10, 2012 4:16 PM
    • Marked as answer by Banc0 Wednesday, April 11, 2012 7:33 PM
    Tuesday, April 10, 2012 3:29 PM
  • I am not using it for DR or backup.  I am doing this to replace the current, possibly corrupt, domain controller in the hopes that I can move to a better supported level of OS and create additional AD replicas. 

    The tweaked dll is not for the cloning process, rather it is to unlock the SAM so that I can change the built-in Administrator's attribute.  After I change it, the original dll is restored.  That's how I was able to dcpromo.  Otherwise it would just fail again.  Even if there was no clone, the built-in Administrator attribute is still locked by SAM.  That defect was already there in the beginning.  Cloning the DC merely carries the same defect over.



    • Edited by Banc0 Wednesday, April 11, 2012 7:32 PM
    Wednesday, April 11, 2012 4:15 PM
  • I still feel that cloning a DC, if I understand you correctly, is not the best method to replace a DC. I'm not sure what occurred to have created a defective DLL installation, but that would be another topic to investigate and repair the underlying cause.

    At least we can use this as a good reason to not use cloning. The only time I've used cloning is for workstation deployment, or even base OS image deployment where I would Sysprep the "master" image, then shut it down. Then I would use that to copy/deploy it as a workstation. Upon first boot, it prompts for a computer name, etc, then goes through a mini-setup like when you first purchase a new machine from Dell, HP, etc. Same with the base server image.

    .

    Anyway, I hope our responses helped you out to understand the underlying workings and what to look for. If you want to try to investigate whatever caused the original ntdsa.DLL to go south, I would recommend to start a new thread on it, and provide some diagnostic data such as ipconfig /all from the DCs, dcdiag /v, repadmin results, and other data, etc. I can provide the list of switches and other data we'll need, if you like to pursue this further.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Wednesday, April 11, 2012 9:56 PM
  • It is the only DC.  There is no other.  MS has already checked dcdiag, etc.  Nothing to replicate so repadmin won't be much help. 

    The backup DC died a long time ago, simply crashed.  It was then that we discovered we could not dcpromo a new DC. 

    I don't know if it is the ntdsa.dll went south.  MS provided the tweak that allows me to bypass the SAM.  All I know is the built-in Admin object cannot replicate during dcpromo because its "isCriticalSystemObject" attribute is locked on FALSE. 

    If I shouldn't clone then what other options do I have of getting rid of W2K and moving up to Windows 2003?  Other than building a new domain from scratch?

    ** There is someone here who has actually cloned several DCs.  He referred me to an article:

    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006996



    • Edited by Banc0 Friday, April 13, 2012 9:35 PM
    Friday, April 13, 2012 8:54 PM
  • Thanks for the explanation. I think this would have been helpful early on in this thread.

    Curious, is this SBS (Small Business Server)?

    .

    So this occured before attempting to clone it. So even if you were to successfully clone it, and disjoin/rejoin the workstations, the clone would still have the problem. 

    .

    So what you're saying, even with the tweakable ntdsa.dll (I'm thinking it's the version from the debugging "symbols" Windows version) from Microsoft, you still can't promote an additional DC?

    .

    Also, do you remember the full error message for the "DCPROMO fails with "Directory Object missing" message? Did it look like the error screenshot in this link? Can you elaborate on it? Maybe re-run it and get a screenshot for us?
    http://social.technet.microsoft.com/Forums/en/winserverDS/thread/847644e7-aee5-4d20-8bf8-497c359268fc

    I'm thinking one of us can *possibly* (no promises) come up with a "non-supported" method to overcome it, but we'll need more specifics with the error message, associated event log errors, etc. :-)

    .

    Lastly, if not possible to overcome it, or you can't provide us the exact error message, and if you have a small number of users, it really may be better to simply create a new, fresh domain in a new forest, and recreate your users, disjoin from the old, and join to the new domain. Then you can use the free, downloadable Microsoft WET tool (Windows Easy Transfer) to migrate their profiles (including email, personal settings, pics, etc).

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Friday, April 13, 2012 9:46 PM
  • Ace,

    No this is Windows 2000 Server.  The problem occurs at this very stage, well before the clone.  Cloning and upgrading the clone only brings the same issue over. 

    The tweakable dll only works with Win2K3.  It's a 50/50 shot.  If it worked, you can change built-in Admin's attribute and dcpromo normally.  If it doesn't (and it did fail on me twice) then your entire OS is hosed with LSASS.EXE errors and you need to boot back into Directory Restore Mode, remove the tweak, restore the originall dll and go back to square one. 

    The failed message was simply the standard Directory Object Missing or Not found.  Nothing else really.  Your screen shot is not the same match. 

    Yes I know I can create a whole new domain.  Was really hoping I didn't have to.  WET sounds nice but for 100 people I don't know how easy of a feat that would be.  Plus I don't believe WET works on the same PC?  It looks like it was designed to migrate profiles from one box to another.  All profiles in this environment are more or less local.


    • Edited by Banc0 Tuesday, April 17, 2012 6:26 PM
    Tuesday, April 17, 2012 6:24 PM
  • With WET, you can dot it for each user to transfer private data after you disjoin and rejoin the machine. You can either store their data on a USB drive or on a server share.

    As for Windows 2000, first, I would forget the whole clone thing. Second, if you can install that tweak long enough to get a new DC promoted, then I would do that. If you can get the new DC promoted and all data replicated before the 2000 machine fails again on the tweaked DLL, then we can worry about DNS and everything else later and simply trash the old machine with a metadata cleanup,. and move forward with 2003.

    I assume that Exchange 2000 or nothing else, is not on the 2000 DC, otherwise I would assume you would've provided that info.

    I also assume you've ran an adprep on 2000 to prep it for a 2003 installation.

    So if the above is true, then go ahead and promote it.

    If it fails, you're back to square one and your only options would be to install a new domain (as noted earlier), or migrate your users and computers to 2003 using ADMT.

    My feeling is start fresh with 2008 R2, and make sure you install TWO DCs to insure at least you have an additional DC in the domain.

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, April 17, 2012 6:42 PM
  • Yes there's always been 2 DCs...it just happens that one died, we cannot promote a new one and we're stuck with this Windows 2000 box.

    Yes I had to run adprep domain and forestprep and Exchange 2003 runs on a separate box.

    The tweak dll didn't work when I tried to create a second clone.  So apparently it's a 50/50 chance.  Even the MS engineer couldn't get it to work after the 1st time. 

    I'll look into the WET option but again it's a manual task.

    Tuesday, April 17, 2012 8:28 PM
  • You can also use the USMT tool, which is more of an enterprise solution for large migrations. It will work fine for smaller migrations. Here are some links on the USMT, including more info and how-to for the WET tool.

    User State Migration Tool 3.0 - You can use Microsoft® Windows® User State Migration Tool (USMT) 3.0 to migrate user files and settings during large deployments of Microsoft Windows XP and ...
    technet.microsoft.com/en-us/library/cc722032(WS.10).aspx

    How Do I: User State Migration Tool?The User State Migration Tool (USMT) for Windows 7 is now part of the Windows Automated Installation Kit (AIK) and provides fast and flexible options to ...
    http://technet.microsoft.com/en-us/windows/dd572169.aspx

    User State Migration Tool - Video -  3 min 14 sec - Mar 17, 2009. The User State Migration Tool (USMT) for Windows 7 is now part of the Windows Automated Installation Kit (AIK) and provides fast and flexible options ...
    http://technet.microsoft.com/windows/dd572169.aspx 

    Windows 7 Walkthrough: User State Migration Tool - Video
    http://www.microsoft.com/downloads/details.aspx?familyid=E263796C-C7E4-44D6-96DD-32E821C88A25&displaylang=en

    Windows Easy Transfer for transferring from Windows XP (32 bit) to Windows 7
    http://www.microsoft.com/downloads/details.aspx?familyid=734917D8-0663-4C26-89D0-2D00B632EBDB&displaylang=en

    .


    Ace Fekay
    MVP, MCT, MCITP Enterprise Administrator, MCTS Windows 2008 & Exchange 2007 & Exchange 2010, Exchange 2010 Enterprise Administrator, MCSE & MCSA 2003/2000, MCSA Messaging 2003
    Microsoft Certified Trainer
    Microsoft MVP - Directory Services
    Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

    This posting is provided AS-IS with no warranties or guarantees and confers no rights.

    FaceBook Twitter LinkedIn

    Tuesday, April 17, 2012 10:05 PM