none
Windows 7 joining a Windows NT Server

    Question

  • Hi All,

    Having real problems joining a windows 7 machine to an NT Server. Done all the usual things like setting the security (NTLM Only). Reset computer on the server etc but i all i get is this computer cannot be found.....

    I looked at the netseup.log and it shows that the DC can be found but cannot attach to it.

    Any ideas would be grateful

    TIM
    Thursday, March 26, 2009 8:48 AM

Answers

  • I can repro this easily now, so no worries on the time. After much gyration today, at this point it's looking pretty grim. Even if I can get it to join (and I think I can - we have some goo added in later builds that should do the trick, I just need to try again with that later build and about a dozen config changes plus a whole new one) I believe the secure channel will not maintain after joining, so the computer will disjoin later as well as have a bunch of other problems. Not to mention that in order to get this to work you will have to desecure the Win7 computer so much that it could be owned by a 12 year old.

    At this point, you should be planning for the eventual outcome that Win7 is not going to work in an NT4 server environment and that you should upgrade your servers or stick with XP/Vista for another 6-7 years. Just out of curiousity, why do you still have NT4? Some old software that just has to have it and no one wants to pay for the upgrade?
    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Thursday, April 02, 2009 2:33 AM

All replies

  • Please rename the netsetup.log, reproduce the issue, then post the contents of the new netsetup.log - but keep in mind, this is not supported so don't plan on deploying Win7 in an NT4 production environment when it releases.
    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    • Proposed as answer by Brian Borg Monday, March 30, 2009 3:15 AM
    Monday, March 30, 2009 2:30 AM
  • Thanks Ned,

    This is the .log you asked for;

    03/30/2009 13:08:18:014 -----------------------------------------------------------------
    03/30/2009 13:08:18:014 NetpValidateName: checking to see if 'ROCHNT4' is valid as type 3 name
    03/30/2009 13:08:18:124 NetpCheckDomainNameIsValid [ Exists ] for 'ROCHNT4' returned 0x0
    03/30/2009 13:08:18:124 NetpValidateName: name 'ROCHNT4' is valid for type 3
    03/30/2009 13:08:35:452 -----------------------------------------------------------------
    03/30/2009 13:08:35:452 NetpDoDomainJoin
    03/30/2009 13:08:35:452 NetpMachineValidToJoin: 'ROCHW7'
    03/30/2009 13:08:35:452  OS Version: 6.1
    03/30/2009 13:08:35:452  Build number: 7057 (7057.winmain.090305-2000)
    03/30/2009 13:08:35:452  SKU: Windows 7 Ultimate
    03/30/2009 13:08:35:452 NetpDomainJoinLicensingCheck: ulLicenseValue=1, Status: 0x0
    03/30/2009 13:08:35:452 NetpGetLsaPrimaryDomain: status: 0x0
    03/30/2009 13:08:35:452 NetpMachineValidToJoin: status: 0x0
    03/30/2009 13:08:35:452 NetpJoinDomain
    03/30/2009 13:08:35:452  Machine: ROCHW7
    03/30/2009 13:08:35:452  Domain: ROCHNT4
    03/30/2009 13:08:35:452  MachineAccountOU: (NULL)
    03/30/2009 13:08:35:452  Account: ROCHNT4\administrator
    03/30/2009 13:08:35:452  Options: 0x23
    03/30/2009 13:08:35:452 NetpLoadParameters: loading registry parameters...
    03/30/2009 13:08:35:452 NetpLoadParameters: DNSNameResolutionRequired not found, defaulting to '1' 0x2
    03/30/2009 13:08:35:452 NetpLoadParameters: DomainCompatibilityMode not found, defaulting to '0' 0x2
    03/30/2009 13:08:35:452 NetpLoadParameters: status: 0x2
    03/30/2009 13:08:35:452 NetpValidateName: checking to see if 'ROCHNT4' is valid as type 3 name
    03/30/2009 13:08:35:592 NetpCheckDomainNameIsValid [ Exists ] for 'ROCHNT4' returned 0x0
    03/30/2009 13:08:35:592 NetpValidateName: name 'ROCHNT4' is valid for type 3
    03/30/2009 13:08:35:592 NetpDsGetDcName: trying to find DC in domain 'ROCHNT4', flags: 0x40001010
    03/30/2009 13:08:36:358 NetpDsGetDcName: failed to find a DC in the specified domain: 0x54b, last error is 0x0
    03/30/2009 13:08:36:358 NetpJoinDomainOnDs: NetpDsGetDcName returned: 0x54b
    03/30/2009 13:08:36:358 NetpJoinDomainOnDs: Function exits with status of: 0x54b
    03/30/2009 13:08:36:358 NetpDoDomainJoin: status: 0x54b

    Where ROCHNT4 is my NT 4 Domain and ROCHW7 is the Windows 7 Workstation.

    ROCHNT4 has IP of 192.168.9.122
    ROCHW7 has IP of 192.168.9.123
    DNS 192.168.9.100 & 192.168.9.141
    WINS 192.168.9.100 & 192.168.9.141

    Firewall disabled on Win7

    Thanks for your help.
    TIM
    Monday, March 30, 2009 12:41 PM
  • So that error is:

    # for hex 0x54b / decimal 1355 :
      ERROR_NO_SUCH_DOMAIN                                          winerror.h
    # The specified domain either does not exist or could not be
    # contacted.
    # 1 matches found for "0x54b"

    Unfortunately, this can mean a ton of stuff is a possible culprit. Here are some things you can try, but unfortunately for this error, the only way we're really going to see what's up is with a network trace. You could install netmon 3.2 on the Win7 client, restart the client, then flush your name resolution caches with IPCONFIG /FLUSHDNS and NBTSTAT -R, then start the netmon capture and try to join again. Then you could share the network capture somewhere public (skydrive, whatever) and I can take a look.

    Anyway, some likely culprits:

    1. Date/time/year are very skewed (make sure they match - even NTLM cares about date, it's just not as sensitive as Kerberos).

    2. WINS/DNS client settings not configured on the Win7 client with the right info. Triple check this, historically this is the most likely cause.

    3. Besides LmCompatibility (which it sounds like you already checked) make sure SMB Signing and SMB Sealing are not required on the Win7 client. I can't recall for sure but I think the NT4 domain join uses a named pipe connection which is going to be SMB.

    4. Try setting following registry DWORD value on the Win7, rebooting, reattempting join:

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Netlogon\Parameters
    AllowNT4Crypto = 1

    Sorry I don't have anything more definitive, this is the 'dunno, it's broke' error of domain join.

    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Tuesday, March 31, 2009 2:35 AM
  • Hi Ned,

    OK, I have created a Network Monitor file and a NetSetup.log file at MS Skydrive (tim.pilcher@nexusalpha.com).
    I have done everthing you asked but still cannot attach to the domain server.

    Can you take a look and see what is happening.

    Thanks in advance.
    TIM
    Tuesday, March 31, 2009 2:31 PM
  • Since Windows 7 is expecting to see an Active Directory domain server, I don’t think it can be done.  I also tried to join a Windows 7, build 7000 client to a Windows NT 4.0 SP6a domain.  With DNS, WINS and everything else set, Windows 7 just would not join.  The error stating that it could not find the Active Directory Controller is what led me to believe this may be a moot effort.

     

    Looking at the log file, there were a couple of things that stood out that further substantiated that Windows 7 might not be able to join an older NT based domain model.

     


    03/30/2009 13:08:35:452  Build number: 7057 (7057.winmain.090305-2000)
    03/30/2009 13:08:35:452  SKU: Windows 7 Ultimate
    03/30/2009 13:08:35:452  MachineAccountOU: (NULL)
    03/30/2009 13:08:35:452 NetpLoadParameters: DomainCompatibilityMode not found, defaulting to '0' 0x2
    03/30/2009 13:08:36:358 NetpDsGetDcName: failed to find a DC in the specified domain: 0x54b, last error is 0x0

    Timbo,

     

    If you get it worked out, darn good on ya’. 

     

    Tuesday, March 31, 2009 8:34 PM
  • Is this all being done in a virtual machine (hyper-v, vmware workstation, etc)? The time offset data in your network trace is bizarrely trashed - wireshark says the time offset is negative ~3500 seconds (impossible) and netmon 3.3 says all the packets happened instantly (even more impossible). Like I was saying before, if time is all wacked out from a VM virtual CPU time synching problem (for example, something like this article KB938448), this could cause the issue where NTLM stops working. I don't see anything too terrible in the trace otherwise - WINS looks ok, netlogon PDC lookup is ok. There are some funky SAM logon requests I can't explain though. It's all very odd.

    I am going to take a look at this tomorrow morning when I get back in the office and run a Win7 domain join against an NT4 computer under a debugger. Not because this join is supported (it's not!) but because it's quite interesting and I'm curious to see what's happening.

    More news in a day or two,

    ps: Not supported!

    :)
    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Wednesday, April 01, 2009 4:14 AM
  • Hi Ned,

    Thanks for spending your time on this.
    Yes both the Windows 7 and NT box are virtual servers running on VMware. The server times were out by the UK hour change however they have now been set correctly.

    Thanks
    TIM
    Wednesday, April 01, 2009 8:24 AM
  • I can repro this easily now, so no worries on the time. After much gyration today, at this point it's looking pretty grim. Even if I can get it to join (and I think I can - we have some goo added in later builds that should do the trick, I just need to try again with that later build and about a dozen config changes plus a whole new one) I believe the secure channel will not maintain after joining, so the computer will disjoin later as well as have a bunch of other problems. Not to mention that in order to get this to work you will have to desecure the Win7 computer so much that it could be owned by a 12 year old.

    At this point, you should be planning for the eventual outcome that Win7 is not going to work in an NT4 server environment and that you should upgrade your servers or stick with XP/Vista for another 6-7 years. Just out of curiousity, why do you still have NT4? Some old software that just has to have it and no one wants to pay for the upgrade?
    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Thursday, April 02, 2009 2:33 AM
  • Thanks for the info.

    The main reason why I havent upgraded yet is simply the cost. But saying that i will be upgrading to 2008 in the summer. Is there any complications regarding Win7 and 2008?.

    Anyway thanks for spending your time on this question.

    TIM
    Thursday, April 02, 2009 9:10 AM
  • I, personally, can say from experience that Windows 7 will easily join a Server 2003 R2/2008 domain w/out any issues or weird workarounds.

    Thursday, April 02, 2009 7:14 PM
  • Dear Ned,

    The replies in this thread concern customers who are using Microsoft NT 4 Server for their domain control.  However, our organisation uses Samba 3 operating as a NT 4 style domain controller - we are affected in the same way.  We brought this issue to the attention of Microsoft on the 14th of January 2009 and we were assured on the 16th of February 2009 that the issue would be fixed.  The Microsoft Connect bug submission has ID 397104.  MSFT reply as follows:

    Subject: Windows 7 will not join a Samba 3 NT style domain
    Hello,

    This issue has been fixed in later internal builds. Please verify with the next available build release.

    Thank you for testing Microsoft Products,

    Bhupesh@MS [MSFT]
    Microsoft Windows Beta Team

    Note that Samba 3 is the current stable open-source implementation of Windows domain control.  In the interests of facilitating integration with open source products (http://port25.technet.com/) we would like to kindly request that this essential service please be integrated into Windows 7.

    Regards,

    Colin

    Sunday, May 10, 2009 11:30 PM
  • Can you join the Samba domain if you if you put the following two DWORD registry values in
    place on your Win7 client and reboot:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters

    DomainCompatibilityMode = 1
    DNSNameResolutionRequired = 0


    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Wednesday, May 13, 2009 3:50 AM
  • Joining the Samba (3.3.4) domain appears successful after adding these two registry values. There is an error message after the domain join "Changing the Primary Domain DNS name of this computer to "" failed." Which appears to be non critical.

    After a reboot it does appear joined, however attempting to log in with a domain account gives "The trust relationship between this workstation and the primary domain failed."

    Changing:

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters

    RequireStrongKey=0
    and
    RequireSignOrSeal = 0

    allows domain accounts to log in.


    • Edited by cplaw Friday, May 15, 2009 4:21 AM Additional info
    Thursday, May 14, 2009 12:04 AM
  • After adding these two Dwords I can get my windows 7 machine to join the NT domain but upon reboot and logging in as administrator or any user I always get "The trust relationship between this workstation and the primary domain failed". I have removed the computer from the domain and tried to rejoin. Same error. I have deleted the trust at the server and rejoined same error. .

    Any thoughts or is it all in vain?

    Thanks,


    Thursday, May 14, 2009 11:45 PM
  • I am having the same "Trust relationship" problem with my Windows 7 RC after joining our NT4 domain with the help of the two registry entries.

    Any suggestions?

    Thanks

    Friday, May 15, 2009 1:19 AM
  • Hi Ned, Moving back to my original question regarding the intergration of W7 into an NT Domain.

    The previous registry keys solved the problem of 'joining' the NT Domain but I have now another problem. The trust relationship has failed while logging in. The exact message is as follows;

    Error 20/05/2009 09:49:13 NETLOGON This computer could not authenticate with [DomainController], a Windows domain controller for domain [Domain], and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

    Now I have come across KB178640.....is this a possible fix.

    I dont want to try this hotfix if its not going to work and possibly affect the trusts on my current network.

    Any ideas anyone????????

    Thanks in advance TIM
    Wednesday, May 20, 2009 9:22 AM
  • Same problem over here, the registry keys works, but after adding to the domain the following error.

    Changing the Primary Domain DNS name of this computer to "" failed
    The name will remain "TESTDOMAIN".  The error was: 
     
    The specified domain either does not exist or could not be contacted"
    Wednesday, May 20, 2009 9:51 AM
  • To reiterate:

    You cannot join a Windows 7 or Windows Server 2008 R2 computer to a Windows NT4 domain. It is not possible, it is not supported. The oldest supported domain to join is Windows 2000 AD, only.
    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Friday, May 22, 2009 3:45 AM
  • You are quite correct, sir.  However, the original beta released earlier this year jumped right on our NT4 network with no trouble at all.  Even over a VPN from home.  I thought it was a fluke that my laptop (with build 7000) was able to do so, yet when I installed RC1 on my desktop machine at work, it absolutely would NOT hook up with our network servers.  I wiped the drive, installed the earlier build and it logged me right into our PDC, using my credentials from the desktop. 

    RC1 definitely SEES everything on the network, but will not get onto anything NT.  It accessed a couple shared folders on some XP machines no trouble. 

    Sadly, that makes Win 7 totally useless for us at work, though I'm quite pleased how it works otherwise.  The chances of us upgrading to a later server OS are between slim and none, as what we have works fine for our small business.  Prying money out of the purse is unlikely, especially to fix something that's not broken.

    Too bad build 7000 shuts off 1Aug.  We'll have to live with XP for a while longer.
    Friday, May 22, 2009 1:42 PM
  • I totally agree. RC1 had broken alot of things with working with older servers. We have a Win 2000 server here and can not add any printers from it in RC1, yet worked perfect in the 7000 build. I think a step backwards has been taken. I guess we will be stuck on XP for a long time as well.
    Friday, May 22, 2009 2:32 PM
  • I understand it is no longer supported, but I guess my question is why?

    Vista supported connecting to NT servers.
    NT is still the backbone of our field operations.
    We have 160 servers in the field and upgrading them to 2k3 or 2k8 is way to $$$. Especially since they are basically just file print servers.
    This is just one more reason for us not to move to 7. we didn't move to Vista because it just wasn't business friendly, now that Windows 7 is coming up. We were really excited, until this happened.

    If anyone can find a way to make it connect, that would be fantastic. I can't even login to my machine because I did the upgrade at home using cached credentials. Now I can't even login to the box now that I'm connected back to the network..

    I'm glad I made a full disk backup, because I'm going to have to blow the whole darn thing away now.
    Tuesday, August 25, 2009 4:04 PM
  • Vista is not supported either - it is supported to join NT 4.0-style domains, i.e. Samba. And that is  since we bend over backwards to assist with Samba compatibility as part of our agreements with them, Novell, and our mixed Windows-Linux customer base. Win7 can join Samba domains, but only with the latest versions of Samba - Samba had to be updated, and NT 4.0 will not be.

    There is no support for Windows NT 4.0 and hasn't been for years - any compatibility is purely coincidental. Your NT 4.0 servers are a time bomb from a security and hardware support perspective. If you continue to use an unsupported NT 4.0 environment, Win7 is not for you. There are no workarounds, it's not going to happen. And that's ok, Vista is supported for 10 years like all of our operating systems, so those can be used until 2017. It costs millions for us to test new releases against previous operating systems - going back to a 13 year old OS is too much to ask of us.

    I also hope there is nothing important on those NT4 file servers, as they are missing more than 3 years worth of security updates.

    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team
    Wednesday, August 26, 2009 4:17 AM
  • Hi

    I get this error when I join a Windows Server 2008 R2 server to our Windows Server 2003 domain. But if I say ok and reboot the server, it seems like everythink works as i should..

    Way do I get this error??

    /Mads

    Wednesday, September 02, 2009 5:16 PM
  • Maybe you have magic touch to solve this problem.

    Would you please try newly released  build 7600 for all of the people that have the same problem.

     

    http://technet.microsoft.com/en-us/evalcenter/cc442495.aspx



    I have tried. Failed, I don't have fluke, still work on it.
    Wednesday, September 09, 2009 12:30 PM
  • windows 7 can join nt domain

     

    I just done it  by editing registery values

     

    but after joining the domain

    when i try to login to the domain i recieve this error

    the trust relationship between this workstation and primary domain failed.

    any help please

     

    habib0008@gmail.com

    Wednesday, May 12, 2010 9:14 AM
  • Vista is not supported either - it is supported to join NT 4.0-style domains, i.e. Samba. And that is  since we bend over backwards to assist with Samba compatibility as part of our agreements with them, Novell, and our mixed Windows-Linux customer base. Win7 can join Samba domains, but only with the latest versions of Samba - Samba had to be updated, and NT 4.0 will not be.

    There is no support for Windows NT 4.0 and hasn't been for years - any compatibility is purely coincidental. Your NT 4.0 servers are a time bomb from a security and hardware support perspective. If you continue to use an unsupported NT 4.0 environment, Win7 is not for you. There are no workarounds, it's not going to happen. And that's ok, Vista is supported for 10 years like all of our operating systems, so those can be used until 2017. It costs millions for us to test new releases against previous operating systems - going back to a 13 year old OS is too much to ask of us.

    I also hope there is nothing important on those NT4 file servers, as they are missing more than 3 years worth of security updates.

    Ned Pyle [MSFT] - MS Enterprise Platforms Support - Beta Team


    Hi ~ 

    The above policy is fine and dandy but shortsighted.  I work for a large consulting firm and we are seeing a significant amount of small and large businesses who have deployed Win7 workstations as a workgroup that accesses shares on NT4 file systems where only the file, antivirus and print servers are the remaining domain members. Authentication is now being handled with some type of hack script that exports a credential manager file into each workstation. It appears to work OK and it gives Win7 an XP-like transparency and backwards compatibility but I am certain that Microsoft did not intend for their systems to work this way.

    The Libraries is another example of shortsightedness with its cobbled inability to simply add network drives. A significant amount of our clients have disabled the libraries with hacks and some only use the Favorites since it appears to be more functional - allowing drives from anywhere. Most enterprise users are not allowed to store files on the individual workstations. An option to turn off the Libraries and Favorites in Explorer as well as in Open/Save dialog boxes should have been included but this is another rant for another day.

    Friday, January 13, 2012 8:36 PM
  • Windows 7 – 8 and NT4

    The specified password is not correct

    Recently upgraded from vista to windows 8

    When I tried to connect to my nt4 shares  no …. No joy

    “The specified password is not correct”.

    After much searching and trying different options I discovered that the Windows security policy

     Start-Run secpol.msc is the tool you need to run to change it and this is what it looks like:

    Local policies

    Security options

    Network security: LAN Manager Authentication level

    Changing this from  to “Send LM & NTLM responses “

    TO

    “Send LM & NTLM - use NTLMv2 session security if negotiated”

    Fixed the problem for me

    • Proposed as answer by miltonl Wednesday, November 07, 2012 4:48 PM
    Wednesday, November 07, 2012 4:48 PM