The Time You’ve Been Waiting For
It’s time to join the machines to the domain. At this point, you’ve created a domain controller and partially configured a domain. I say “partially” in order to stress that I’m not covering every single aspect of configuring a domain. I’m only going over what is needed to get SharePoint 2016 running.
Joining Servers to the Domain
The screenshots shown in this exercise feature the SQL server, which you may or may not have already created. Hopefully, you’re waiting until Chapter 9 to create the SQL server; but no worries if you’ve already created the machine. Just, please keep in mind that every server will need to be joined to the domain using these procedures, with the exception of the first domain controller.
1. Open the Run bar, type sysdm.cpl, and click OK.
2. Click Change… button, shown in Figure 6-1.
Figure 6-1. Change name to whichever member server name you’re working on
3. Enter the NetBIOS computer name (e.g., SP2016APP) Do not enter the FQDN. You might have already done part of this in Chapter 3, which is fine, and means that you can leave the name alone if it’s already changed from the WIN-ISJNS1N2TTO.
4. Select the Domain radio button, shown in Figure 6-2. Type the domain name tailspintoys.com, click OK, and then click Apply.
Figure 6-2. tailspintoys.com had a record year in 2015
If you receive a message like the one shown in Figure 6-3, proceed to step 5; otherwise, proceed to step 9.
Figure 6-4. Check those DNS servers
5. Open a Run bar and type Control netconnections, as displayed in Figure 6-4.
Figure 6-3. Result of improper configuration
6. Look at the properties of the IPv4 network, select it, and click Properties, as shown in Figure 6-5.
Figure 6-5. Focus on IPv4 for your home lab
7. Make sure that the primary domain controller is set to your domain controller IP address and that the secondary domain controller is set to your default gateway IP address, as shown in Figure 6-6.
Figure 6-6. Make sure your DNS server entries are correct
8. If the domain controller IP addresses are correct and you still receive the message shown in Figure 6-3, go into the domain and double-check that the SRV record for the domain is created. Refer back to Chapter 3’s Verify DNS Install: Create SRV Record exercise. If you’re still getting the Figure 6-3 message, see step 12.
9. After you click OK and Apply, you should get prompted to enter the domain admin credentials. Enter the domain admin account (e.g., Zeus or Zues, depending on your spelling skills and on what you renamed your domain account to, assuming you renamed it and didn’t leave it as administrator). (See Figures 6-7 and 6-8.)
Figure 6-7. Enter your credentials
Figure 6-8. If you changed the admin account, enter Zeus; spell it correctly
If you didn’t change your domain administrator account, you’ll use administrator, as shown in Figure 6-8, rather than using zues. Figure 6-9 shows how I failed to change the domain administrator account, so I’m using administrator.
Figure 6-9. If you didn’t change the admin account, enter administrator
10. Once the join completes, you get an acknowledgement, as shown in Figure 6-10.
Figure 6-10. You need to see this for every server
11. Click OK to restart the server when you see the image shown in Figure 6-11.
Figure 6-11. Restart the machine to effectuate the join
12. If you’re still having trouble, double-check that your machine is discoverable on the network. Right-click the bottom left-hand corner network icon and click Open Network and Sharing Center, as shown in Figure 6-12.
Figure 6-12. Right-click the network icon
13. Click “Change advanced sharing settings”, shown in the left-hand menu in Figure 6-13.
Figure 6-13. Change advanced sharing settings, left-hand menu
14. Set network discovery to turn on network discovery and restart the computer. Try steps 1-4 again. If you still are having trouble, make sure that the firewall is not the issue. Type wf.msc in the Run bar and click OK. Make sure that the firewall is turned off. Try again. In a live-fire environment, your servers are behind hardware-based firewalls and more than likely will not run Windows Firewall, as shown in Figure 6-14.
Figure 6-14. Turn on network discovery
Repeat this for all of your member servers, with the exception of the SQL server.
Now that you’ve joined all the member servers to the domain, let’s perform a domain resolution exercise to understand how to verify IP resolution. After the resolution exercise, let’s look at using the Microsoft terminal services executable to log in to the servers.
The DNS namespace lookup tool lets you check records in DNS without opening DNS.
Nslookup: Internal and External
Internal
1. To perform a lookup from the domain controller, you could open dns and start driving around looking for the record, or you could use a command prompt.
2. Open a console window by opening the Run bar, typing cmd, and pressing Enter or clicking OK, as shown in Figure 6-15.
Figure 6-15. Open the command prompt
3. Type nslookup and press Enter, as shown in Figure 6-16.
Figure 6-16. Open the name space lookup tool
4. Type the name of the internal resource record that you’re after and press Enter. You should see that the server that replied is your local DNS server, DC1AD1 (if you didn’t use a different name). (This is also known as localhost since these screenshots were taken from the DC1AD1 machine. See Figure 6-17.)
Figure 6-17. Local machine name
5. Type the name of the external resource record that you’re after (e.g., bing.com) and press Enter (see Figure 6-18).
Figure 6-18. Enter the external resource record (e.g., bing.com) and hit Enter
Use External DNS
6. Type server 8.8.8.8 (make sure that “server” is lowercase) and press Enter, as shown in Figure 6-19.
Figure 6-19. Enter Google DNS server IP (8.8.8.8) and press Enter
7. Type www.bing.com and press Enter. Notice the different DNS server that replied: any.edge.bing.com (see Figure 6-20).
Figure 6-20. any.edge.bing.com server
The nslookup command returned a name for the server that gave the reply in Figure 6-20. In figure 6-19 this information about the server named any.edge.bing.com was unknown and not returned because the DNS server that returned the call in that figure was not the google DNS server. Then in Figure 6-20, you can see that the info was returned by the Google DNS server.
Now that you know how to look up records in DNS, we will try another way to log in to the member servers—directly from the host (from the laptop, PC, or server on which you installed Hyper-V). This is the method that you’d use in a live-fire situation, too. It also looks great in presentations. The Hyper-V Manager method of logging into the machines that we’ve been using up until this point is not as nice as using Microsoft Terminal Services connections (mstsc.exe).
In a home lab setting, the only prerequisites for mstsc.exe to work when entering the host names is a modified hosts file and remote access enabled on the VMs. In a domain-joined PC (not in a home lab setting), you could use mstsc with host names without modifying the hosts file on the local PC, as long as the server or machine is enabled for remote access.
In Chapter 1, you dorked (modified) the hosts file of your laptop, and in Chapter 3, you set remote access to Enabled. We’ll double-check this in following exercise.
Microsoft Terminal Services Connection (Mstsc.Exe)
1. Open a Run bar, type mstsc, and then click OK, as shown in Figure 6-21.
Figure 6-21. Microsoft terminal services connection
2. Type the name of one of your member servers (e.g., SP2016APP) in the Computer field and then click Connect, as shown in Figure 6-22.
Figure 6-22. Enter the correct name, click Connect
3. If everything is configured correctly, you’ll get prompted to log in. After the computer prompts you about the certificate, do not log in with the user account that you logged into your laptop with; instead, use the domainadministrator account for your domain, as shown in Figure 6-23.
Figure 6-23. Use another account
4. In this example, it appears that the svc_farm account is being used to log in. You can’t use the farm account to join a computer to the domain; you need a domain admin account or an account with the privilege to join member computers; but you can use any account that’s a member of either the local administrators group or the local remote desktop users group on the virtual machine, as shown in Figure 6-24.
Figure 6-24. After you get the farm completely set up, you can even use svc_farm
5. If the machine you’re trying to log in to is not powered on, is not in your hosts file, is not present in DNS, and/or is not enabled for remote access, you’ll receive an error similar to Figure 6-25.
Figure 6-25. Make sure the machine is turned on, etc.
6. Go through the steps that you performed when you were joining the machine to the domain. Add a step to make sure that there is a host (A) record in DNS, double-check the SRV record, check the machine’s DNS servers and so forth (see the first exercise in this chapter). All of these things were in previous exercises. See Chapter 13 for things to check, too.
7. If you can’t remember the steps to check remote access, here they are in a nutshell: Log in to the server using Hyper-V Manager. Once logged in, open a Run bar. Type sysdm.cpl. Click the Remote tab. Make sure that the remote desktop is enabled. Click Apply and then click OK.
8. To check the SRV record, if you are logged into the domain controller, open the forward lookup zone in DNS, drive into the _tcp node, and verify that you can see an _ldap SRV record.
9. To check the hosts file, on your host (laptop, PC, or server), open C:windowssystem32driversetchosts and make sure that there are entries there, as shown in Figure 6-26.
Figure 6-26. Shows the hosts file on a machine that sometimes logs into contoso too.
Make sure that the IP addresses in your host file are corresponding to what you’ve configured for your machines.
Do You Want to Know More?
Table 6-1 provides additional information.
Table 6-1. Not Required Reading, But Here If You Want To Dive Deeper
Topic | URL |
|---|---|
Nslookup | |
Troubleshooting Domain Join Error Messages | |
Join and Authentication Issues | |
Network Geeks by Brian E. Carpenter (Apress, 2013) |
Summary
This chapter covered joining SharePoint (and maybe SQL) servers to the domain. We used nslookup to check the domain name resolution. We made sure that the domain controller had that all-important service location record for the ldap service. We double-checked our machines for network discoverability and remote access settings. Then we checked out Microsoft Terminal Services connection.
In the next chapter, we’ll dive into group policy, learn about some of the default group policy objects (GPOs), check out the computer or server’s local security policy, and create a GPO that controls who is an administrator on our member servers. Then, after the GPOs are good to go, we will create a certificate authority and a wildcard certificate.