Windows Foundation – Glennopedia

How to re-deploy VPN in 2016 Essentials with PowerShell

Posted on August 25, 2017August 25, 2017 by Glenn

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:

RemoteAccess Default

If you try to manage it in the RRAS (Routing and Remote Access Server) console, you will see this:

legacy mode

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:
Get-RemoteAccess

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.

Why is my network profile stuck on Public?

Posted on May 3, 2017 by Glenn

Good morning. A quick tip for today on an issue I run into from time to time. I have seen a lot of Windows machines in my time. One of the problems that I run into on a fairly regular basis is network communication issues. A possible cause for these issues can be due to the Windows firewall being too restrictive. That is what we are going to discuss today in this post.

Before we get into how to fix the network profile, let’s first discuss why the network profile even matters. To do that we need to talk about the Windows firewall a little. The Windows firewall provides a barrier between the Windows operating system and the network(s) to which it is attached. It has 2 or 3 distinct profiles that it will operate in. Whether it has 2 or 3 depends on if the system is joined to an Active Directory domain. Each These 3 profiles are as follows:

Public – Windows assumes it is directly connected to the Internet or is on an unsafe or unfamiliar network. This profile is the most restrictive and blocks most incoming traffic.
Private – Windows assumes this network is isolated from the Internet and is considered mostly safe. This profile allows more traffic than the public profile, but some services are still blocked by default.
Domain – Windows assumes the network is trusted. This profile is the least restrictive and by default allows most known services through.

As you probably already guessed the profile used by the Windows firewall correlates directly with the network profile assigned to the network adapter. So if your network profile shows Public you can bet that almost all services will not work.

Now that we know about the profiles and what they do, how can we change the network profile. If this were a client operating system like Windows 8/8.1/10 then it would be easy, just go into Network and Sharing Center and change the profile. On a server operating system, for instance Windows Server 2012/2012R2/2016, the option to change the profile is not there. That is, unless you count the side pop-out asking if you want to discover computers on the network. Clicking yes on that pop-out will put the network profile into private. Clicking no will put it into public.

If you clicked no, there is still hope. There is a PowerShell command that can be used to set the network profile; Set-NetConnectionProfile. Here is the command I use to quickly change the mode of all network cards in a system.

Get-NetConnectionProfile | Set-NetConnectionProfile -NetworkCategory Private

This will set all network cards to Private profile.

If you need to set just one network card, you will need to know the interface index. To find this run the following command.

Get-NetConnectionProfile | FT Name,InterfaceAlias,InterfaceIndex -a

This will give a table of all the network adapters in the server with their names and indexes. You can then run the following command to set a single network adapter

Set-NetConnectionProfile -InterfaceIndex <index number> -NetworkCategory Private

I hope you found this article helpful. If you have anything to add or just want to leave a comment, please do so below.

How to run Windows Foundation edition as a Hyper-V virtual machine.

Posted on January 26, 2017 by Glenn

I recently needed to reproduce a customer issue in my lab environment. My lab is a Windows 10 workstation with the Hyper-V role installed. Part of reproducing the issue involved building out a Windows Server 2012 R2 Foundation virtual machine. I figured this would not be a problem as 2012 R2 runs fine as a virtual machine. This was not the case though. I ran into a major hurdle with the integration tools. I will describe the process I went through to get a Windows Server 2012 R2 Foundation virtual machine running smoothly.

Now before anyone goes out and tries the below procedure for a production system, please understand that running Foundation edition as a virtual machine is not supported by Microsoft. Also it will likely violate the EULA (End User License Agreement). Typically Foundation edition is only sold with an OEM license. That means it comes pre-installed on hardware and must remain on that hardware. So in order to do this, and not violate the EULA, a non-OEM license is required. I have a MSDN subscription and thus have a valid license. Additionally, I am not running the server for any type of production workload.

I started the process by creating a generation 2 VM (virtual machine). Unfortunately I found out this will not work as the VM bugchecked during setup. I deleted that VM and created a generation 1 VM. I was then able to get the Windows loaded. This is when I discovered the major hurdle I mentioned above. The VM responded very slowly to mouse and keyboard input. I also noticed severely degraded performance. This was to the point of the VM almost being unusable. The VM behaved as if none of the integration services drivers were installed. Unfortunately Windows 10/2016 do not have the option to insert the integration disk. I was able to get the vmguest.iso from a 2012 R2 hyper-v host. However when I tried to run the setup I was informed that the latest integration services were already installed.

At this point I realized this was not going to be easy, but I enjoy a challenge. I browsed the vmguest.iso inside the Foundation VM. I extracted the following file: D:\support\amd64\Windows6.2-HyperVIntegrationServices-x64.cab. I then went into device manager. I noticed quite a few, a dozen or so, unknown devices.
unknown-devices

I then tried to manually load the drivers from the extracted cab file. While the driver was found, it was not signed. I figured no sweat, just disable driver signing requirement in the BCD (Boot Configuration Data). Yet another roadblock. It is no longer possible to permanently disable driver signature enforcement. I was able to boot into driver signature enforcement disabled mode. I then manually loaded drivers for all the Unknown devices. This corrected the input and performance issues, at least for that boot. Booting into normal mode caused all the issues to return.

f8-boot-menu

Getting the drivers to load each time Windows booted was the final step in getting the virtual machine to run properly. I looked into the bcdedit command line options and was not able to find an option to boot to driver signing disabled mode. What I ended up doing was to add a dummy entry to the boot list and set the timeout to 30 seconds with the following commands.

bcdedit /copy {current} /d "Dummy Entry"
bcdedit /timeout 30

dummy

Presently, on each boot I press F8 to get the boot options. I then select Disable Driver Signature Enforcement. Now the VM runs with all guest integration services.

If you have been able to find a better way to do this I would like to hear about it in the comments below.

Windows Foundation Edition and Single Label domains

Posted on January 20, 2017 by Glenn

Good morning. I had an interesting issue a couple of days ago I wanted to cover in depth. I had a customer with a 2003 single label domain. He was migrating to 2012 R2 Foundation. He had added the Foundation server as a peer domain controller to the 2003 domain. The problems came up when he shutdown the 2003 domain controller. He would receive errors in the silsvc (Server Infrastructure License service) log. Initially I was under the impression that that Foundation edition does not support single label domains and this is what I told him. For my customer he preferred running in a workgroup configuration and so he removed active directory from the server. I wanted to duplicate this environment in my lab to see if I could determine the root cause of the errors and if it was possible to eliminate them.

My test environment consisted of a 2003 R2 virtual machine that was cleanly loaded. On that server, I setup a single label domain named “mydomain”. I then installed a 2012 R2 Foundation virtual machine. This was a significant challenge in itself. Look for another blog post on getting 2012 R2 Foundation working in a virtual machine. These virtual machines were linked by a private virtual switch. Once the virtual machines were setup, I joined the 2012 R2 Foundation server to the 2003 single label domain. I then promoted the 2012 R2 Foundation as a domain controller. Finally I verified that replication was working and that the DNS (Domain Name System) zones were present on the 2012 R2 Foundation server.

At this point I checked the silsvc log. All tests were passing without issue. I then shutdown the 2003 server. This was where things went awry. On the next check done by silsvc the following popup was received.
popup-error

Checking the silsvc log showed two errors. The first was an event ID 2 that stated: “The Forest Trust Check in the Licensing component did not pass because error 0x8007054B occurred in function f1 [PHQG]. The specified domain either does not exist or could not be contacted.” This error is identical to the one I saw with my customer. Additionally I received an event ID 38 that stated: “The Forest Trust Check detected a condition in your environment that is out of compliance with the licensing policy. This server will be automatically shut down if the issue is not corrected in x day(s) x hour(s) x minute(s).”

forest-trust-check-failed

I then did some digging around to determine if any of the active directory tools were affected. Everything seemed to work fine with the exception of the Active Directory Domains and Trusts. When launching that MMC (Microsoft Management Console) I received the following error: “You cannot modify domain or trust information because a Primary Domain Controller (PDC) emulator cannot be contacted. Please verify that the PDC emulator for the current domain and the network are both online and functioning properly.”
pdc-emulator

This explains why turning off the 2003 domain controller caused the forest trust check to fail. The silsvc needs to be able to contact the PDC emulator to check for trusts. If it cannot, then the check fails. I powered up the 2003 domain controller and transferred the FSMO (Flexible Single Master Operations) roles to the Foundation server. I was then able to shutdown the 2003 server without receiving any errors.

I hope you found this article informative. If you have any comments or suggestions please leave them below.