DNS is Driving me Crazy!

[LoudCloudDragon]

DNS, DFS, Secure Channel, Can't connect Domain (DC1)

My setup

• MultiRole
  • DC1
  • S1
  • CLI1

Progress, status, current config At first I had no internet but I figured out I needed to get rid of 1 - 2 of my NetNat's so I wiped that out and afterwards I started getting different error messages and established internet connection so I am moving in the right direction. All systems, local, remote, virtual, meet or exceed the minimums.

There are two items I feel may be misconfigured during post install config; Root Hints, CA stuff, and service account choice for authentication.

Symptoms Error Codes will be below

• From CLI1 I can ping the DC1 and Google by IP and HostName CLI1's netadpater with changed from the AutoLab config to DHCP. I was having the issues before this change and it is probably a moot point
• From DC1 I can not ping CLI1 at all.
• From DC1 I can ping S1 by name and IP (this confused me).
• I can connect from CLI1 to DC1 with PSremoting (e..g Enter-psSession).

Things that I have tried not necessarily in order

1. Disabled IPv6 scope in DHCP and Root Hints _I still see a bunch of roots with IPv6 even after a reboot of DC1 so not sure what to do about that.
2. Flushing ipconfig stuff, reboots, etc.
3. Checked DNS config in the snap-in and things look ok, I guess, but I am not sure what is and is not right so...
4. After DC1 reboot:
   1. Restarted services; NETLOG ON, DFS (any service with that as part of the name)

Error Codes

• From CLI1 evevtvwr

  • 1054 The processing of Group Policy failed. Windows could not obtain the name of a domain controller. This could be caused by a name resolution failure. Verify your Domain Name System (DNS) is configured and working correctly.

  • 8033 The system failed to update and remove host (A or AAAA) resource records (RRs) for network adapter with settings:

    Adapter Name : {CFAC1B88-23D5-4B1F-96BD-A7B2368731BD} Host Name : Cli1 Primary Domain Suffix : Company.Pri DNS server list : 192.168.3.10 Sent update to server : <?> IP Address(es) : 192.168.3.200

  • 1014 DNS server failed to respond
  • Com, DCOM, Time Service errors
  • 5719 This computer was not able to set up a secure session with a domain controller in domain COMPANY due to the following: We can't sign you in with this credential because your domain isn't available. Make sure your device is connected to your organization's network and try again. If you previously signed in on this device with another credential, you can sign in with that credential. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

• From DC1

  • 12 Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the AD PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the AD PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient.
  • 1014 Name resolution for the name 168.192.in-addr.arpa timed out after none of the configured DNS servers responded.
  • 10154 The WinRM service failed to create the following SPNs: WSMAN/DC1.Company.Pri; WSMAN/DC1
  • 1014 DNS timeout
  • 5781 Dynamic registration or deletion of one or more DNS records associated with DNS domain 'ForestDnsZones.Company.Pri.' failed. These records are used by other computers to locate this server as a domain controller (if the specified domain is an Active Directory domain) or as an LDAP server (if the specified domain is an application partition)

• From S1

  • 1058 The processing of Group Policy failed. Windows attempted to read the file \Company.Pri\SysVol\Company.Pri\Policies{F4DD1E03-A436-488D-96F3-0D95D0B66C40}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following: a) Name Resolution/Network Connectivity to the current domain controller. b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller). c) The Distributed File System (DFS) client has been disabled.
  • 5719 This computer was not able to set up a secure session with a domain controller in domain COMPANY due to the following: We can't sign you in with this credential because your domain isn't available. Make sure your device is connected to your organization's network and try again. If you previously signed in on this device with another credential, you can sign in with that credential. This may lead to authentication problems. But I can still logon to S1 by HyperV mng > Command Prompt with Domain account so ... WHAT???

**I have not added S1 to DNS config. I have changed very little, if anything, in DNS config.

[jdhitsolutions]

The first thing to recognize is that these configurations are not standing up production-ready systems. They were designed to meet minimum requirements for a given Pluralsight training course. There are a number of settings and services that are admittedly incomplete. For example, the CA role is mostly setup but not completely.The fact that you are finding incomplete settings is to be expected, but the configurations were complete enough to meet their initial demands.

All of that said, you should still have some network connectivity between VMs and the host and VMs. Although the Windows Firewall in the VMs may not be configured for ICMP. When you ran the setup, did the Pester test complete successfully? If you are setting a configuration up for your own use, you very well may have to make changes, which you are welcome to.

[jdhitsolutions]

Change location to the MultiRole directory and run:

Invoke-Pester .\VMValidate.test.ps1

Does everything still pass? If any of the tests fail for a VM, restart the VM, wait 5 minutes and try the test again.

[LoudCloudDragon]

Executing all tests in '.\VMValidate.test.ps1'

Executing script .\VMValidate.test.ps1

Describing DC1 [-] [DC1] Should allow a PSSession but got error: The credential is invalid. 5 57ms Expected $true, but got $false. 85: $false | Should Be $True at , C:\Autolab\Configurations\MultiRole\VMValidate.test.ps1: l ine 85

Describing S1 [-] [S1] Should allow a PSSession but got error: The credential is invalid. 3m s Expected $true, but got $false. 112: $false | Should Be $True at , C:\Autolab\Configurations\MultiRole\VMValidate.test.ps1: l ine 112

Describing Cli1 [-] [CLI1] Should allow a PSSession but got error: The credential is invalid. 3ms Expected $true, but got $false. 193: $false | Should Be $True at , C:\Autolab\Configurations\MultiRole\VMValidate.test.ps1: l ine 193 Tests completed in 2.71s Tests Passed: 0, Failed: 3, Skipped: 0, Pending: 0, Inconclusive: 0

PS C:\Autolab\Configurations\MultiRole>

I understand that the lab is created in a way to facilitate the curriculum. I am a powershell student who is attempting to create a Small/Med business environment mockup lab (fully functional) for AD (my E3 Microsoft license provides the other env: for powershell). Hyper-V is local on my beefy laptop

[jdhitsolutions]

I'm assuming this test was 20-30 minutes after you started the setup process. For no reason that I can pinpoint, sometimes configurations don't finish. I would suggest using Hyper-V to shut down each VM and restart them. Change to the MultiRole directory and run Shutdown-Lab then Run-Lab. Wait 10 minutes then re-run Invoke-Pester.

The only thing that makes sense is that the AD configuration is failing to get applied. I'm assuming you didn't change any of the configuration files. If you still have issues, I'd suggest starting over. On occassion, I've found that something fails to run and the best course of action is to try again. Run Wipe-Lab. Then run Open-PSAutolabHelp and follow the instructions in the Detailed Setup Instructions to do a manual setup. If you get to this step, post a reply and also include the output of the Get-PSAutoLabSetting command.

[LoudCloudDragon]

PS C:\Autolab\Configurations\MultiRole> Invoke-Pester Pester v4.10.1 Executing all tests in '.' Tests completed in 0ms Tests Passed: 0, Failed: 0, Skipped: 0, Pending: 0, Inconclusive: 0

At this point I am going to wipe the lap and start over. Please feel free to close the issue or if you wish, await until I rebuild the Lah bore rah tory.

[LoudCloudDragon]

After Wiping and setting up manually; the lab seems better. I am still getting DNS related issues including DFS stuff BUT, for what I need (powershell targets), everything seems to be working. I am able to create PSSessions, invoke commands, and so on.

Here is the Pester from after the wipe and setup.

AutoLab : C:\Autolab PSVersion : 5.1.18362.1171 PSEdition : Desktop OS : Microsoft Windows 10 Enterprise FreeSpaceGB : 714.46 MemoryGB : 32 PctFreeMemory : 79.04 Processor : Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz IsElevated : True RemotingEnabled : True HyperV : 10.0.18362.1049 PSAutolab : {4.18.0, 4.17.0} Lability : 0.19.1 Pester : {4.10.1, 3.4.0} PowerShellGet : 1.0.0.1 PSDesiredStateConfiguration : 1.1

I think the issue is closed now. I will make Checkpoints and try to work out my errors another time. It is not essential right now and my test (MCSA) is fast approaching.

[jdhitsolutions]

As long as the Pester tests pass, that was our minimum bar of success. I know the configurations didn't do anything with DFS and setup a bare bones minimum AD/DNS.

[LoudCloudDragon]

Thank you for your guidance and expertise.