It could happen. I saw this issue couple of times, not only on domain controllers, but also on other domain joined computers.
The cause of this problem is the Network Location Awareness service. We know, that this service is recognising network location based on gateway and is trying to locate AD server thru port 389. Well, when gateway is changed or no server connection true port 389 is available, we have a new network location – by default it is Public.
Anyway, it can happened that NLA service starts before the AD services are started (or before DC is reachable on a non DC server). In this case, we will have public network profile on DC or domain joined computers. If firewall is enabled, most of network services will not run as the firewall for the Public profile is almost closed.
We have few possibilities to solve this situation. Maybe the most simple way is to restart the server, but I don’t know if I can restart the server at this moment and what was the original cause of the problem – maybe it will reappear. The second option is to disable / reenable the NIC adapter and in most cases, it will solve the issue. We will get the same result if we just restart the NLA service – this is a better way.
In some cases, you cannot connect to the computer for some reason. In this case, I use PowerShell remote session to solve the problem.
Here are the steps:
Enter-PSSession ComputerName (establish connection to computer with the problem)
Get-NetConnectionProfile (this will show you your current location profile – if this is the source of the problem, the location will not be Domain)
Restart-Service nlasvc (this cmdlet will restart NLA service; after this step you should see Domain network profile)
Get-NetConnectionProfile (just to check if the solution works)
Exit-PSSession (disconnect form the remote computer)
Based on my experience, this solution works always. Some administrators also suggest to change start option for NLA service to Automatic (Delayed Start). I am not sure if this is a good solution; be careful with it. Maybe you can do it in cases where this error is frequent (better: search for the original cause and solve the problem)
Many times (or almost always), you have to define start order of VMs as services on one VM in an exactly defined order. We tried to solve this problem with start delays in the past – or with some additional software, but there were always situations where we are unable to control all factors.
Now in Windows Server 2016 edition it is better, as we can define startup groups. This means, that we define a group of servers who will start together and another group of servers who will start later when the first group is started or also with some delay after the first group is started. Additionally, we can start just a last group of servers and because this group depends on other groups, system will first start the parent server group. So, you are not able to start some servers before all infrastructure depends on it is started. We have new cmdlets in PowerShell to define and manage Cluster Groups (you can list them with Get-Command -Noun *ClusterGroup*).
To do these settings, you have to know some concepts that are introduced in Windows Server 2016 and we will use them.
- This post explains how to create groups in Hyper-V cluster; it will not work on non-clustered servers. If you want to setup startup order for a single Hyper-V host, this is the post where you can find how to do it.
- Cluster Group: Represents clustered services or applications (resource groups) in a failover cluster – any HA VM has his group. You can view cluster groups with PowerShell cmdlet Get-ClusterGroup. You don’t need to change anything here; just leave them as they are.
- Cluster Group Set: Is a set of Cluster groups (VMs) that we want to control together. This is a set of VMs that have similar services and we want to control them as a group. Here we can control some settings (startup delay, global or local, …). Cmdlet we have to use at this point is Set-ClusterGroupSet (cmdlet syntax)
- Cluster group set dependency: Is a dependency where we specify which group and when it will start. To be clear, with dependency we define VM startup order.
How to setup environment?
I always start creating output with cmdlet Get-ClusterGroup, because it is easier to manage all VMs when I have all their names on a paper or TXT file. It is easier to review them, define services that they offer and later functionally define group sets.
When you have defined group sets (put VMs with similar services or dependencies together) it is time to create Cluster Group Sets. This operation is done in few steps:
- Create Cluster Group Set: this will create an empty group for grouping VMs. To do this you have to use cmdlet New-ClusterGroupSet -Name GroupName.
- Add Cluster Groups (VMs) to sets. In this step, we will populate Cluster Group Sets with VMs – this mean that we will put together all VMs with similar services or VMs that we need to start at the same time. When Cluster Group Set will be asked to start, all VMs that are in it will be started. There is no dependency inside the Cluster Group Set and we have no chance to control the start order inside the group. If we think that some VMs need to start before other VMs, we need more than one Cluster Group Set. To add VM to Cluster Group Set we will use PowerShell cmdlet Add-ClusterGroupToSet -Name GroupName -Group ClusterGroupName. In this cmdlet, you have to change GroupName with your Cluster Group Set name and ClusterGroupName with Cluster Group name (VM name – output in firs step). We have to repeat cmdlet for every single VM.
- Create dependency between Cluster Group Sets: We have to use cmdlet Add-ClusterGroupDependency -Group GroupName -ProviderSet GroupDependsOn. GroupName is the name of the Cluster Group Set we want to start and GroupDependsOn is a Cluster Group Set necessary to be started previously. At this point we need to create startup order (dependency) between groups. The start of any group can depend on successful start of one or more groups. If previous group will fail to start, the group who depends on it will not start. I suggest you to have in mind this situation (maybe develop a script to add and remove all VMs from groups – you will quickly solve problems if they appear).
With this few steps, we created a startup order for our environment. If it is all OK, we will never have a situation when a service will not work because some dependency server is not started. Practically, the system will look to start all VMs in a defined order. This also means, that we have to add and remove depreciated and newly deployed VMs in this groups – we have to change this mechanism every single time we change our environment. Don’t forget it.
Need to learn about Microsoft technologies? If the answer is yes, you can start downloading E-Books from here. They are completely free and very useful.
As I trust and use Kaspersky Antivirus, I had some problems in last month or two. It seems that Kaspersky is not really well integrated with Windows 10 and you have to expect some problems.
In my case, I use Kaspersky Small Office Security and this software prevents me to do a lot of actions. I found the issue when I tried to create External Network Switch in Hyper-V console – the problem is when you create a new network adapter. In this case I received an Error Access Denied – 0x80070005.
I received the same Error also when I tried to install Shrew Soft VPN Client. I was always unable to install network component due to Access Deny. Analyzing the problem, I found that there is a problem accessing to folder INF (Change) and some other system folders, but all permissions were as they should be and there was no way to establish the right permissions to get installers work.
Well, removing Kaspersky I was able to solve the problem. But be careful, just disabling the antivirus will not be enough; you have to completely uninstall the entire antivirus and reboot the computer to correct the issue.
Hope that Kaspersky will correct the issue soon. It is my preferred antivirus program and I like it, but unfortunately it is not well integrated with Windows 10.
In some cases, when you try to install Hyper-V replica broker in FailOver cluster, the installation finishes successfully, but the service itself don’t start. The reason is the insufficient permissions on AD object. Of course you (and me) are not the first one who has this problem and the solution is documented in this TechNet blog post. If it is possible, I prefer to create container for Hyper-V clusters and hosts and delegate permissions on this OU – option 2 (it is better for future changes), but is up to you what do you prefer..