Captured Image not Joining Domain RRS feed

  • Question

  • Hello Sir,

    My Captured Image not joining domain automatically, Although When I deploy Fresh Image through MDT it joined domain automatically. When I start the Image capturing the computer is not on the domain, as advised in the available threads, Image Captured went successfully, but when I try to deploy the Captured Image through MDT, the target computer not join the domain automatically, we have to do the domain Join manually. Please advise what went wrong.

    regards / Abhishek

    Friday, August 9, 2013 7:59 AM

All replies

  • Do you have the domain join information in the customsettings.ini file, a task sequence, or in the MDT database? If you use cs.ini can you post it so we can take a look at it. You can also take a look at the log found in %SystemRoot%\Debug\NetSetup.log for domain joining issues.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Friday, August 9, 2013 12:03 PM
  • this is a códice:


    TimeZoneName=Central Standard Time

    aquí el código Bootstrap.ini




    Wednesday, October 23, 2013 9:45 PM
  • I am experiencing same issue too. My custom image does not join to the domain in MDT. All the settings are out-of-box from MDT2013. I input username with permission to join computer to the domain. Below is extract of NeTsetup.log and these lines are repeated 3 times as I guess MDT tries to join the computer to the domain 3 times before giving up. Text between <> below is generalized after removing actual data BTW.

    In addition manually joining computer to the domain works fine. I have a custom script for domain joining which also worked fine. 

    10/24/2013 16:28:00:009 NetpDoDomainJoin
    10/24/2013 16:28:00:009 NetpDoDomainJoin: using new computer names
    10/24/2013 16:28:00:009 NetpDoDomainJoin: NetpGetNewMachineName returned 0x0
    10/24/2013 16:28:00:009 NetpDoDomainJoin: NetpGetNewHostName returned 0x0
    10/24/2013 16:28:00:009 NetpMachineValidToJoin: '<Computer Name>'
    10/24/2013 16:28:00:009 OS Version: 6.3
    10/24/2013 16:28:00:009 Build number: 9600 (9600.winblue_gdr.130913-2141)
    10/24/2013 16:28:00:009 SKU: Windows 8.1 Pro
    10/24/2013 16:28:00:009 Architecture: 64-bit (AMD64)
    10/24/2013 16:28:00:009 NetpDomainJoinLicensingCheck: ulLicenseValue=1, Status: 0x0
    10/24/2013 16:28:00:009 NetpGetLsaPrimaryDomain: status: 0x0
    10/24/2013 16:28:00:009 NetpMachineValidToJoin: status: 0x0
    10/24/2013 16:28:00:009 NetpJoinDomain
    10/24/2013 16:28:00:009 HostName: <Computer Name>
    10/24/2013 16:28:00:009 NetbiosName: <Computer Name>
    10/24/2013 16:28:00:009 Domain: <FQDN>\<Domain Controller>.<FQDN>
    10/24/2013 16:28:00:009 MachineAccountOU: <OU>
    10/24/2013 16:28:00:009 Account: <UserName>
    10/24/2013 16:28:00:009 Options: 0x23
    10/24/2013 16:28:00:009 NetpLoadParameters: loading registry parameters...
    10/24/2013 16:28:00:009 NetpLoadParameters: DNSNameResolutionRequired not found, defaulting to '1' 0x2
    10/24/2013 16:28:00:009 NetpLoadParameters: DomainCompatibilityMode not found, defaulting to '0' 0x2
    10/24/2013 16:28:00:009 NetpLoadParameters: status: 0x2
    10/24/2013 16:28:00:009 NetpDisableIDNEncoding: no domain dns available - IDN encoding will NOT be disabled
    10/24/2013 16:28:00:009 NetpJoinDomainOnDs: NetpDisableIDNEncoding returned: 0x0
    10/24/2013 16:28:00:009 NetpJoinDomainOnDs: status of connecting to dc '\\<Domain Controller>.<FQDN>': 0x0
    10/24/2013 16:28:00:009 NetpJoinDomainOnDs: Passed DC '<Domain Controller>.<FQDN>' verified as DNS name '\\<Domain Controller>.<FQDN>'
    10/24/2013 16:28:00:009 NetpLoadParameters: loading registry parameters...
    10/24/2013 16:28:00:009 NetpLoadParameters: DNSNameResolutionRequired not found, defaulting to '1' 0x2
    10/24/2013 16:28:00:009 NetpLoadParameters: DomainCompatibilityMode not found, defaulting to '0' 0x2
    10/24/2013 16:28:00:009 NetpLoadParameters: status: 0x2
    10/24/2013 16:28:00:009 NetpDsGetDcName: status of verifying DNS A record name resolution for '<Domain Controller>.<FQDN>': 0x0
    10/24/2013 16:28:00:009 NetpGetDnsHostName: PrimaryDnsSuffix defaulted to DNS domain name: <FQDN>
    10/24/2013 16:28:00:009 NetpProvisionComputerAccount:
    10/24/2013 16:28:00:009 lpDomain: <FQDN>
    10/24/2013 16:28:00:009 lpHostName: <Computer Name>
    10/24/2013 16:28:00:009 lpMachineAccountOU: <OU>
    10/24/2013 16:28:00:009 lpDcName: <Domain Controller>.<FQDN>
    10/24/2013 16:28:00:009 lpMachinePassword: (null)
    10/24/2013 16:28:00:009 lpAccount: <UserName>
    10/24/2013 16:28:00:009 lpPassword: (non-null)
    10/24/2013 16:28:00:009 dwJoinOptions: 0x23
    10/24/2013 16:28:00:009 dwOptions: 0x40000003
    10/24/2013 16:28:00:024 NetpLdapBind: Verified minimum encryption strength on <Domain Controller>.<FQDN>: 0x0
    10/24/2013 16:28:00:024 NetpLdapGetLsaPrimaryDomain: reading domain data
    10/24/2013 16:28:00:024 NetpGetNCData: Reading NC data
    10/24/2013 16:28:00:024 NetpGetDomainData: Lookup domain data for: <Domain Name>
    10/24/2013 16:28:00:024 NetpGetDomainData: Lookup crossref data for: CN=Partitions,CN=Configuration,<Domain Name>
    10/24/2013 16:28:00:024 NetpLdapGetLsaPrimaryDomain: result of retrieving domain data: 0x0
    10/24/2013 16:28:00:024 NetpGetLocalDACDisabled: returning 0x0, *pfDACDisabled=TRUE
    10/24/2013 16:28:00:024 NetpCheckForDomainSIDCollision: returning 0x0(0).
    10/24/2013 16:28:00:024 NetpGetComputerObjectDn: Cracking DNS domain name <FQDN>/ into Netbios on \\<Domain Controller>.<FQDN>
    10/24/2013 16:28:00:024 NetpGetComputerObjectDn: Crack results: name = <Domain Alias>\
    10/24/2013 16:28:00:024 NetpGetComputerObjectDn: Cracking account name <Domain Alias>\<Computer Name>$ on \\<Domain Controller>.<FQDN>
    10/24/2013 16:28:00:024 NetpGetComputerObjectDn: Crack results: Account does not exist
    10/24/2013 16:28:00:024 NetpGetComputerObjectDn: ldap_compare_s failed: 0x20 0x2
    10/24/2013 16:28:00:024 NetpCreateComputerObjectInDs: NetpGetComputerObjectDn failed: 0x2
    10/24/2013 16:28:00:024 NetpProvisionComputerAccount: LDAP creation failed: 0x2
    10/24/2013 16:28:00:024 NetpProvisionComputerAccount: Cannot retry downlevel, specifying OU is not supported
    10/24/2013 16:28:00:024 ldap_unbind status: 0x0
    10/24/2013 16:28:00:024 NetpJoinCreatePackagePart: status:0x2.
    10/24/2013 16:28:00:024 NetpAddProvisioningPackagePart: status:0x2.
    10/24/2013 16:28:00:024 NetpJoinDomainOnDs: Function exits with status of: 0x2
    10/24/2013 16:28:00:024 NetpJoinDomainOnDs: status of disconnecting from '\\<Domain Controller>.<FQDN>': 0x0
    10/24/2013 16:28:00:024 NetpJoinDomainOnDs: NetpResetIDNEncoding on '(null)': 0x0
    10/24/2013 16:28:00:024 NetpDoDomainJoin: status: 0x2


    Friday, October 25, 2013 12:56 AM
  • I have a similar issue....

    The domain join executes, but it executes with the wrong name.  Instead of using the name I specify in the database it uses a generic WIN-XXXXXXXX* name. 

    The fields FullName and OSDComputerName are set in the database to the name I want.  The NetSetup.LOG file show the wrong name being used.

    It looks like the Recover from Domain task attempts to to the join with the correct name but it fails because the test shows the system is already joined to the domain.

    Is there an easy way to skip the first join?  What task/script does it run under?



    Friday, October 25, 2013 11:00 PM
  • Hello Friend,

    We are using WDS and MDT 2012 (we do not have SCCM and as a policy cannot install it also so SCCM is ruled out) to deploy a Windows 7 syspreped image on clients spread accross various buildings and trying to make the deployment as zero touch as possible - in our Domain, we have created task sequence in MDT for the machine to join the domain and  to push applications after image is deployed -  the task sequences are followed till the Post instrall step where the the OS is installed, machine joins the domain, reboots, runs the OOBE and then just comes to the CTLR + ALT + DEL screen. Now there are two problems

    1. The next task sequences of pushing apps do not execute the link with the MDT is broken.

    2. The machine is on the domain picking up an ip address from the DHCP (if you delete the ip from DHCP disconnect and reconnect the nic it picks the same ip again) and we can ping other machines on the network from it but the When we try to ping THIS NEW DEPLOYED MACHINE from any other computer, we get Request Time Out both by name and ip, we also get Network path not found if we try to connect or manage it, 

    The Strange thing is After restarting it manually, the client become active and responds to remote ping and can be managed. 

    As we have to run other tasks that need to be executed on the machine remotely (remember we are trying to make it as zero touch as possible) our concern is that is

    a. Determine the Cause of why it might be happening (MDT link being broken)

    b. why we are not able to connect to the machine remotely - any way through which we can remotely restart the computer after CTRL+ ALT + DEL Screen through some MDT Task Sequence or unattended.xml

    Pleas.................e advise me this on urgent basis.

    regards / Abhishek

    Saturday, October 26, 2013 6:06 AM
  • You go into detail in your first paragraph above about the task sequence created, however the MDT Default CLient.xml task sequence does everything you mention above.

    I don't understand what the problem is when you say: "1. The next task sequences of pushing apps do not execute the link with the MDT is broken." What Link are you referring to? Does the machine no autologon? Is the Litetouch.lnk shortcut missing in the startup group? What does the bdd.log say?

    I could be that you correctly modified the firewall settings via script, however you need to restart the firewall service to accept the changes. I would recommend forcing a reboot near the end of the Task Sequence just to be sure.

    Keith Garner -

    Monday, October 28, 2013 12:03 AM
  • I am having the same thing happen.  I have a sysprepped image  of Win 8.1 that I captured using MDT 2012. Then I upgraded to MDT 2013 (along with the Deployment Kit) but even though I enter the machine name during deployment - it does not pick up the new machine name (it keeps the original from the sysprepped image) and it does not join the domain.  Everything else works fine - time zone, activation, etc.  I have looked through the logs and my logs look pretty much like the ones posted above.  Is there something specific I shold be looking for in the logs - and what logs to look at.  I see the unattend file and it has all the right stuff in it.
    Thursday, October 31, 2013 1:56 PM
  • I've added some debug logging lines into ZTIDomainJoin.wsf to log the value of oComputer.Name and it reports the computer name as the one I assigned.

    One other odd thing is that the Windows 8.1 setup asks me for the system name instead of taking it from the unattend.xml file (where it is blank in the deploy task).  I will try adding the name to the unattend.xml file to see what happens.

    In looking at the NetSetup.log file I can see that the attempts by ZTIDomainJoin.wsf to join the domain fail because the system is already joined to the domain.  The AD OU taken from the database shows a computer account for a system named WIN-XXXX .

    My question is where does this domain join happen?  If we find that we can fix the problem.



    • Edited by BDS_Vince Thursday, October 31, 2013 3:59 PM
    Thursday, October 31, 2013 3:35 PM
  • Success!!!!

    I edited the unattend.xml file associated with my deploy task and added a placeholder name to the ComputerName field in the specialized section of the amd64_Microsoft-Windows-Shell-Setup_neutral section

    Here's a picture

    After making that change my system is named correctly (i.e. uses the name I assigned in the database entry) and joins the domain as expected.

    I hope this works for everyone else!

    Thursday, October 31, 2013 6:48 PM