• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 338
  • Last Modified:

Cannot Join Domain


We have a 20 workstation network. All the workstations are WIN2K pro
computers and the server is a WIN 2K server with active directory/DHCP/DNS.  

Most of the computers login to the domain, 'xxx.net', but four of the workstations
access a workgroup.  The problem is that I cannot get these computers to
join the domain.  Whether I use control panel/system or netdom, the error
message I get is 'The specified domain either does not exist or it could not
be contacted.'

If I go up to a computer which can log into the domain and change it it to
workstation access, restart the computer and then try to change it back to a
domain, it cannot make the switch back.

We can use the internet, ping everything, map network drives, but not get workstations to join the domain.

Other details.

- Server has active directory runnning.
- DHCP / DNS is running on the server.
- There are no routers.
- All workstations are cabled into a switch.
- All computers already members of the domain work fine.

Any ideas will be appreciated.


Stephen Simpson
1 Solution
This is almost always DNS

Make sure that the workstations are pointing to the same INTERNAL DNS server as your AD Server
Use the DNS MMC Snapin to check that the _MSDCS entries are there for your domain in the forward lookup zones, if not run this at the command line of your DC and check the event logs after 15 minutes for errors:


Let me know how it goes


James HilloyaCommented:
I had this same problem rhis is what u need to do:

Lets say your domain name is abc.com
first make one of the trouble computers a member of the "workgroup" abc (make the worgroup name "abc"....)...then reboot
After that trouble computer is a member of the workgroup "abc" try to join the computer to the domain "abc" then it should work.

In other words make the workgroup name the same as the domain name then aftet the computer belongs to that workgroup join the computer to the domain.
do you use a host file for your workstations?
are the workstations getting ip from dhcp server?
if not is your ip address sceam correct?
coolmarine24 is right it should join the domain.
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.


>>first make one of the trouble computers a member of the "workgroup"

What exactly is this supposed to achieve, apart from creating spurious 20h, 1bh and 1ch entries in the NetBIOS namespace?

The error message "The specified domain either does not exist or it could not be contacted" is ALWAYS either DNS or network connectivity.
Simply joining a machine to a workgroup with the same name is not a technical solution - whether or not it might have worked once in the past.

We must address the fact that DNS is not working correctly if the domain cannot be addressed correctly from inside the LAN.

The DNS Server must allow the _MSDCS records to be created and the Domain Controller(s) and the clients must all point to the same DNS server, or one with a full copy the forward lookup zone for the AD domain.

Please try my original comment and let us know how you got on.


As the post above mentioned, make sure your DC is using itself as its primary DNS server.  All client machines should use yuor DC as their primary DNS server.  Make sure the clients don't have any hosts or lmhosts files in use.

Did you install a new DC and shut down the original one without running dcpromo?  If so, then your FSMO roles are out-of-whack.  See the following MS Knowledge Base Articles for more information:

Given the simplicity of your network, I would suggest changing to Active Directory Integrated Zones.
Go to DNS Admin | Select the Domain Controller | Forward Lookup Zones | Select your domain name | Right-Click and Choose Properties | Change Type to AD Integrated.  In this same area you can do some testing on the DNS server to see if it can resolve names properly.  Try them out and post the results.

You could also try creating new machine accounts in AD for your client machines.  You're just eliminating the possibility of a corrupt Machine Account in AD.  it might be part of the problem, but DNS is the probably culprit.

Part of me is thinking that this might be a SID problem, but hopefully the DNS changes will take care of it.  The SID could be the culprit if you installed a DC and gave it the same domain name as the original domain.

Are there any errors in the Event Viewer on the DC?

Two more things:
Make sure the proper IP address for the DNS server (i.e. the one on the DC) is specified in your DHCP options.

Also make sure that there are not any statically configured DNS servers on the clients.
StephenSimpsonxAuthor Commented:
Ok, we finally were able to make this problem go away.  

To review, the problem showed itself when you attempted to join the domain.  You got the message 'The specified domain either does not exist or it could not be contacted.'  Further, from time to time, a workstation which was a member of the domain would no longer be able to login.  An additional problem, which we later determned to be related was that the login and browsing process was very slow.

Now, any computer can join the domain and the login is lightning fast.

What did we do?

We accessed the dns server and noticed that there was no reverse lookup zone and the dns lookup zone for the domain was misconfigured.  There were certain 'subfolder' items that where missing and that dns zone was not being updated automatically as information was gathered and requested.  i.e., machine names were not added to the list.  We decided to delete the dns lookup record for the domain and add it again.  We set it to automatically update dns records when a request is made.  We also added a record for the server.  We also created a reverse lookup dns record and set up up to work.  Finally, we sorted the order of dns lookup addresses so it would use the internal dns before the external one (the internet)

(In short we deleted the dns configuration information and added it in again.)


You did not need a reverse lookup zone to make the AD work, although RLZ is best practice when configuring DNS and it does make troubleshooting easier using NSLOOKUP.

The _MSDCS entries would have been put back correctly into a zone that allows dynamic updates with the command IPCONFIG /REGISTERDNS on the DC. This command would also have put in the proper A and PTR records, but would not have fixed a missing SOA records, which it sound like you had as well.

It also sounds like the original zone wasn't allowing dynamic update, which it is now.

Given that you had more than one issue, a nuke it and start again approach was probably the best thing to do :)

Anyhow, glad you got it fixed, and thank you for the points


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now