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)
Some of my customers and friends had a problem: after installing KB4041676, VMs on Server 2016 didn’t boot. The problem is in update – Microsoft releases the update with a mistake and correct this update immediately the same afternoon, but in some cases the old update remained in cache on devices or WSUS servers. To be sure, that you have the right update, check this link and retrieve the right delta update.
What if you are already there and your VM is not booting?
To solve the issue, follow this steps:
- Start the VM from the media (DVD, ISO…)
- At the installation menu, select Repair computer and in Advanced options select Command prompt
- In command prompt, you have to execute this commands:
- reg load hklm\temp c:\windows\system32\config\software
- reg delete “HKLM\temp\Microsoft\Windows\CurrentVersion\Component Based Servicing\SessionsPending” /v Exclusive
- reg unload HKLM\temp
- After correcting the registry, we still need to remove the update with commands:
- Use dism /image:c:\ /get-packages to list all installed packages to check if the package is really installed
- When you find the package, you can uninstall with command: dism /image:c:\ /remove-package /packagename:packageidentity /scratchdir:c:\temp (package identity is an identity reported in output from previous command)
- Reboot the server
Hope it is helpful.
Well as I know many users are trying to find Windows key with some key viewer software. Nothing wrong, but this software is not always “nice” and can do something else than just show you a key. Of course, with Windows 8.1 and Windows 10 you have many times a key in BIOS, so there is no need to search for it.
Anyway, if you feel better when you have a key printed on a piece of paper, you can do that simply with one PowerShell cmdlet:
Get-WmiObject -query ‘select * from SoftwareLicensingService’
This will show you more than only a key. There are a lot of information on licensing, like KMS server, OS version, … In some cases it can be useful.
I recently bought Minix Z83 mini PC and the first think I did was to upgrade it to the latest version of OS. Unfortunately, I received immediately an upgrade error with a code 0xc1900200. This means that UEFI partition on the disk is too small. It should be at least 350MB, but deployed size is 64MB.
Well, no problem, you have just to resize the partition and this is very simple. I use a tool named EaseUS Partition Master, which gave me very good results everywhere. But there was a second disappointment: I was not able to move or resize the partition “Other” with size 16MB and in Minix forums there is no explanation what this partition is used for or if I can delete it.
I did some research what to do with current file system, why we have an additional partition and finding some answers I decided to delete this 16MB partition.
So, my steps to solve the problem were:
- Install and start EaseUS Partition Master
- Resize the system partition (C:) in a way to reduce size for 270MB and apply free space in a front of partition
- Restart the computer (EaseUS needs to restart a computer to apply changes on system partition)
- Start EaesUS Partition Master again
- Delete the partition with the size 16MB
- Resize UEFI partition to 350MB
- Apply all changes (You can see the final situation on the image)
- Close EaseUS Partition Master and restart the computer
- Update Windows with Windows 10 Upgrade Assistant.
This step will guarantee you to upgrade your OS to the latest version and avoid problems in the future. The steps are valid also for other systems and other configurations, but be careful when you have more than only needed partitions. Any additional partition is there for some reason and is better to find why before you remove or resize it.
Of course you have heard about the new malware, which yesterday created a lot of problems in industry. Unfortunately it is not an unknown problem.
Microsoft released a patch for this type of vulnerability already in March, but it seems once again that administrators are not patching their systems.
So, if you haven’t patched your systems at least every month, if you haven’t patched your system from March, is time to do it. And don’t forget to have a good defense system (antivirus and other prevention mechanisms). Update them to!
You can find additional information in this link.
Here is a link to post how was neutralized and who did this.
Anyway, we have already a version 2.0; you can read about this version here.
Again, please patch your systems! This update will solve a vulnerability. And don’t forget: this is not the first malware who was written on known vulnerability – patch your systems constantly!
Additionally, please disable SMB1 protocol – it is not new that it is not secure. Here and here are some guidelines how to do it via GPO.