I ran across an interesting issue I wanted to share. I had a customer that recently had a migration performed. Previously he was running SBS (Small Business Server) 2011 and is now running Windows Server Essentials 2016. After demoting and removing the SBS 2011 server, he started receiving the following error on every boot.
The error is quickly followed by an informational message indicating that DFSR (Domain File System Replication) successfully connected to a domain controller.
Based on my previous experience with similar issues I posited that the problem was due to the DFSR service starting before either the network stack was fully initialized or before the DNS (Domain Name System) service was running.
I explained that based on the behavior this could safely be ignored. This did not go over very well as the error also shows up in the Windows Essentials health report. This brings us to the solution. And this solution will work for just about any service that needs a little more time at boot. We set the startup type for the DFSR service to Automatic (Delayed Start). We restarted the server and this eliminated the 1202 error.
I hope that you found this article informative. If you have anything to add, please feel free to leave a comment below.
Good morning. In case you haven’t guessed it already I typically write these posts in the morning. As I write this now it is 6:30AM. Today I wanted to share a command line utility I just recently discovered. It has been part of Windows for quite some time though. At least since Windows Server 2008. The utility is called diskshadow. This utility allows direct interaction with VSS (Volume Shadow Copy Service). You can find the Microsoft technet article here. In this article I will go over how I used it to troubleshoot a recent issue with VSS.
I was recently troubleshooting a VSS where the snapshot was failing on release. As is typical, my customer was using a 3rd party backup software. I wanted to test outside of the backup software, so we installed the Windows Server Backup feature and tried that. Unfortunately the symptoms were identical. After quite a bit of digging I ran across the diskshadow utility. With that utility I received a different error which led me down the path of discovering the problem. It turned out that the backup software’s filter driver was stepping on VSS and causing the failure. After removing the backup software, VSS worked without issue.
So how is the diskshadow command used? It can be used to create a snapshot, mount an existing snapshot, restore a snapshot and several other things. Below I will cover the commands to take a VSS snapshot, as that is the functionality I find most useful. To take a snapshot of the C: drive and test the majority of the VSS writers there are just 3 commands that need to be run.
- diskshadow (This starts the command and puts you at a diskshadow prompt. This is similar to ntdsutil and nslookup.)
- add volume c: (This adds the C: drive to the snapshot. You could substitute another drive letter if you want to test a specific writer. The command can also be repeated with other drive letters to include them in the snapshot.)
- create (This starts the snapshot process with VSS. It is important to note that the create command by itself will create a non-persistent snapshot. That is the snapshot will be removed on exit from the diskshadow utility. A persistent snapshot can be created with additional parameters.)
This utility is considerably faster when troubleshooting VSS, taking only about 1-2 minutes to take a snapshot or fail. It also removes the requirement for a USB drive to temporarily store a backup. For these reasons I will be using whenever troubleshooting VSS in the future.
I hope you found this article informative. If you have anything to add or just want to leave a comment, please do so below.
Good morning. I wanted to share an issue I see on a regular basis. This has to do with the NLA (Network Location Awareness) service. For those that are not aware of this service it is responsible for determining the type and safety of the network(s) the computer is connected to. There are 3 network classifications that are used.
- Public – The NLA determines the computer is directly connected to the Internet or is on an unsafe network. This is also the default profile assigned to a network adapter until one of the other profiles can be determined.
- Private – The NLA determines the computer is isolated from the Internet by a NAT (Network Address Translation) device or router.
- Domain – The NLA determines that the computer is connected to a domain. It does this by attempting to contact a domain controller. More specifically it performs a DNS (Domain Name System) query for a SRV (Service) record. It will then make a connection to the domain controller. If this is all successful, the domain profile is set.
So what is the purpose of the NLA and setting a network profile? The primary purpose is for the Windows firewall. Other applications and services can also access this data though.
Now that the NLA service is sufficiently explained, on to the common issue with it. The NLA service by default is set to Automatic for its startup type. Normally this works fine and the NLA properly detects the network. There are some situations though where the service fails to set the profile correctly on startup. I typically see this on domain controllers in a domain with just one domain controller. This means that the network stack and DNS server service have to fully initialize and start before the NLA queries the network. If they do not then the NLA is not able to contact a domain controller and assumes the computer is connected to a private or public network.
Regardless of the reason why the NLA is failing at startup the solution is fairly simple. I have seen a 100% fix rate with simply setting the service startup type to Automatic (Delayed Start). Doing this forces the NLA service to wait until all Automatic services have started, giving DNS enough time to start. I have seen this little trick work with other services when they are having trouble at startup.
I hope you found this article informative. If I missed anything or you just want to comment, please feel free to do so below.
In my previous article I discussed an issue I see commonly with VPN in Essentials. In that article I gave the fix for all versions of Essentials except 2016. In this article I will cover the fix for 2016 Essentials.
As stated previously, 2016 Essentials uses PowerShell to configure the VPN. Here is what the default configuration looks like:
If you try to manage it in the RRAS (Routing and Remote Access Server) console, you will see this:
The message would imply that you could turn on legacy mode. This is true, but to turn on legacy mode requires clearing the configuration from RRAS. Clearing the configuration must be done with PowerShell. Re-deploying the VPN can be done with both PowerShell and the RRAS console. Below are the PowerShell commands.
- Launch a PowerShell session as administrator.
- Run Uninstall-RemoteAccess. Hit enter when prompted
- Run Install-RemoteAccess -VpnType Vpn -IPAddressRange 192.168.16.100,192.168.16.120
Change the ip addresses to match the range you want to use. In the command above the start IP address is 192.168.16.100 and the end IP is 192.168.16.120.
- It may be necessary to modify the SSL certificate. To check this run Get-RemoteAccess. If the SSL certificate matches the one installed by the Essentials anywhere wizard, then you are done. If not, please proceed to the next step.
- Run Set-Location Cert:\LocalMachine\My; Get-ChildItem | Subject,Thumbprint
You should see output similar to the following:
- Make note of the Thumbprint for the certificate that was created in the anywhere access wizard.
- Next assign the certificate to the VPN with the following command:
Get-ChildItem | ? Thumbprint -eq “C39ED8D5ADC2F73A05A909BE9C4692B43B963FB2” | Set-RemoteAccess
- Finally verify the correct certificate is assigned to the VPN with the command:
Clients should be able to connect and access resources via the VPN now.
I hope you found this article informative. If you have any suggestions or comments please leave them below.
Windows Server Essentials is a great product. Easy to configure and it uses the existing network infrastructure to save money and resources. There is a situation that I see fairly regularly with the VPN (Virtual Private Network) on Essentials though. I have seen this issue on all versions of Essentials from 2011 to 2016.
My customer will setup the VPN using the anywhere access wizard and it completes without any errors. He/she will then test the connection with a client. The client connects without a problem, but is unable to access any resources on the Essentials network.
The problem is that RRAS (Routing and Remote Access), the VPN server in Windows, is not able to lease an IP from the DHCP server running on the router. Failing to lease an IP, Windows reverts to using an APIPA (Automatic Private IP Addressing) address. This will be an IP in the 169.254.0.0/16 subnet. More likely than not this is on a different subnet than the rest of the Essentials network. This effectively isolates the VPN client from the Essentials network.
The fix is quite easy on Essentials 2011, 2012, and 2012 R2. Simply add a static pool to the VPN server configuration. Here are the steps:
- Install the RRAS management console, if not installed.
- Run Windows PowerShell as administrator
- Run the following command: Install-WindowsFeature RSAT-RemoteAccess-Mgmt
- Run rrasmgmt.msc to launch the RRAS console
- Right-click on the server name and choose properties
- Click on the IPv4 tab
- Click the radio button for “Static address pool”
- Click the “Add” button
- Fill in the start and end IP address for the pool. This should be a range that is not included in the router’s DHCP (Dynamic Host Control Protocol) range, but that is part of the same subnet.
- Click OK twice.
- Restart the Routing and Remote Access service. PowerShell: Restart-Service RemoteAccess
For Essentials 2016 the fix is a bit more involved. Unfortunately the RRAS configuration cannot be edited to simply add a static pool. The anywhere access wizard in 2016 uses PowerShell to configure RRAS and disables the RRAS console. This would be fine, but Microsoft neglected to include a PowerShell command to modify the IP address management. Since the configuration cannot be modified it must be torn down and re-deployed outside the anywhere access wizard. I may add this to this article in the future.
I hope this article has been informative. If you have any comments or suggestions, please post them below.
This article is for those that don’t know that 0x80070002 is “The system cannot find the file specified.” or that 0x80070020 is “The process cannot access the file because it is being used by another process”. It seems impossible to memorize all the error codes in Windows and what they mean. Thankfully there is no need to do this, as there is a utility built into Windows to decode them.
To find out what an error code means launch a command window and run this command slui 0x2a <error code>. For instance slui 0x2a 0x80070002. You will get a popup similar to the following:
You will need to Show details. The description is the error code text.
I hope you found this article informative. If you have anything to add please do so in the comments below.