Windows 2012 – Page 2

Where are my file shares?

Posted on June 14, 2017 by Glenn

Good morning. I ran into an issue I see from time to time in support. One of my customers was unable to find where his shares were located on the filesystem. The solution is quite easy to solve with a single command.

Net Share

Running that command will display all shares on the server including hidden and administrative shares along with their paths. This command will work in any version of Windows and does not require elevation.

I hope you found this article informative. If you have anything to add, please do so by adding a comment 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.

Group Policy and the case of the missing permission.

Posted on March 31, 2017 by Glenn

Good morning. I had a case yesterday that yielded several interesting article ideas. This is probably the most interesting one, and I have seen this very issue on at least three occasions. The issue started on a domain rename. If you have ever done a domain rename, you know there are quite a few steps. After doing some checks and making some corrections we were able to complete the domain rename. My customer then advised that his Folder Redirection policy was not applying on any workstations. So in this article I am going to cover how to troubleshoot a group policy not applying and the specific fix for the situation I ran into yesterday.

The first step when troubleshooting just about any group policy issue is to pull a group policy report from a client that should be getting the policy. My preferred method is to go to a command prompt and run the following commands:

gpresult /h report.htm
report.htm

This will run the report and save it to a file called report.htm. The second line then opens that report in a web browser.

When troubleshooting an issue where a policy is not applying I like to focus on the denied sections. In our case folder redirection is a user policy, so I checked there. Below is similar to what I found.
gpo-inaccessible

There were two clues as to what the issue was here. The first clue is that the policy name is not being displayed. Instead we just see the GUID (Globally Unique Identifier). The second clue is the reason denied. We can see it was denied because the policy is inaccessible, empty or disabled.

The next step was to check to see if the policy was accessible in the SYSVOL share. In our case we had no problem accessing the files. We then checked in the group policy management console. We verified the policy was not empty or disabled. So it would appear that we have eliminated all possible issues. However there is another set of permissions.

delegation-tab

This was the set of permissions that were not correct in our case. The Authenticated Users group was missing. I have seen this issue on several occasions when one of my customers is trying to “lock down” the server. Even if you add in another group, for instance Domain Users, and the user and/or computer is a member of that group, the GPO (Group Policy Object) will still fail to apply. The fix is quite simple. Add back the Authenticated Users group and give it read permissions. After adding back Authenticated Users and running a gpupdate /force on the client the policy applied without issue.

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

The DNS management console fails to update or gets “stuck”

Posted on December 29, 2016 by Glenn

Another quick tip here. I recently had a DNS (Domain Name System) console that was failing to update. I knew that DNS was functioning properly and that all the records were there. They were just not showing up on this particular server. This is actually a pretty easy fix.

To reset the DNS console, or most mmc consoles, you just need to delete the settings file. There is a settings file for each user that has logged in. This file is located at C:\Users\<username>\AppData\Roaming\Microsoft\MMC\dnsmgmt. You may notice other files in this directory. Those files are the settings files for their respective mmc consoles.

Unable to extend an NTFS volume

Posted on July 6, 2016July 7, 2016 by Glenn

Good afternoon. I ran into an interesting issue this afternoon I wanted to share. I had a customer that was receiving the following error:

“The volume cannot be extended because the number of clusters will exceed the maximum number of clusters supported by the filesystem.”

Unable to extend, cluster size

He encountered the error when trying to extend a volume. The volume was 20TB (Terabytes) and he was trying to add another 19TB for a total of 39TB. After some research I found, based on his setup, that the maximum volume size was 32.75TB. We extended the volume to that size and we were done.

I figured someone might find it useful if I l go over the process of determining the maximum size for a volume. There are a couple pieces of key information that are required. The first is the maximum number of clusters in a NTFS volume. This is 2^32 -1 clusters, or roughly 4 billion. The second piece of information we need is the bytes per cluster. To get this information, run the following command: fsutil fsinfo ntfsinfo x:
Replace the x: with the actual drive letter. Below is output from the command. In this example we see that we are using 4096 bytes per cluster or 4K for short.

bytes per cluster

Now that we have both pieces of information we just need to do some simple math to find the maximum volume size. Multiply the maximum maximum number of clusters by the cluster size. Taking the example above, that would be 4,294,967,295 * 4096 = 17,592,186,040,320 bytes. To convert this to megabytes, divide the number by 1,048,576 (1024*1024). In this example we get 16,777,215 Megabytes.

To make this even easier, here is a handy table:

Cluster size	NTFS Max Size
512 bytes	2,199,023,255,040 (2TB)
1024 bytes	4,398,046,510,080 (4TB)
2048 bytes	8,796,093,020,160 (8TB)
4096 bytes	17,592,186,040,320 (16TB)
8192 bytes	35,184,372,080,640 (32TB)
16384 bytes	70,368,744,161,280 (64TB)
32768 bytes	140,737,488,322,560 (128TB)
65536 bytes	281,474,976,654,120 (256TB)

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

Catch a misbehaving driver with verifier

Posted on June 2, 2016June 2, 2016 by Glenn

Today I wanted to mix it up a little. I want to talk a little about debugging, more specifically about using driver verifier. If you have seen a Windows bug check, aka the blue screen of death, then you have probably seen a DRIVER_IRQL_NOT_LESS_OR_EQUAL. This particular bug check has two codes associated with it; 0x0000000A and 0x000000D1. In the majority of cases, this bug check is caused by a 3rd party driver that is misbehaving. Most of the time the cause can be identified by debugging the kernel memory dump. Sometimes however the problematic driver is paged out and is no longer present in the memory dump. In this case we can use driver verifier to catch this misbehaving driver and force a bug check to happen before the driver is paged out. The rest of this article will discuss how to enable driver verifier for this scenario.

Click Start, or in Windows 2012 and higher right-click Start, and choose Run. Type in verifier and click OK.
From the select a task options, select “Create custom settings (for code developers)” and click Next.
From the select individual settings from this full list, tick the check box for Special pool and click Next.
From the select what drivers to verify options, select “Select driver names from a list” and click Next.
Sort the driver list by provider. Tick the check box for all drivers that are not provided by Microsoft, and click Finish. We do this so that we can monitor all 3rd party drivers.
Reboot the server.

After the server is rebooted all 3rd party drivers will be monitored. If one of them should misbehave, driver verifier will force the system to bug check. It should then be fairly simple to find the problem driver in the memory dump.

If you have any suggestions for this article, please leave a comment below.

License compliance checking in Windows Essentials and Foundation

Posted on April 29, 2016 by Glenn

Good morning. I figured it was time for another post on Essentials. Some parts of this article also apply to Foundation edition.

Let’s start off with a little background on Essentials edition. Windows Server Essentials edition is designed for a small to medium sized business. It is a very good option for a small to medium sized business with less than 25 users/computers. Here are a few of the advantages to running Essentials.

It is less expense than standard edition. Typically by $200-300.
There are no additional CALs (Client Access Licenses) to purchase. Twenty five user CALs are included.
Can be easily upgraded to standard edition with a single command.
Client PC Backup is builtin. This feature automatically backs up client PCs to the server
Anywhere access is available. This is a feature that was first introduced in SBS (Small Business Server) It allows a user to remotely access computers and file shares. It also allows the administrator to access the Dashboard from anywhere. Additionally the administrator can setup a SSTP (Secure Socket Tunneling Protocol) VPN (Virtual Private Network) via a wizard.
Easy integration with Microsoft cloud solutions.

What’s the catch? There is always a catch. Windows Essentials edition is no exception. Below are the limitations imposed by running Essentials.

The Essentials server MUST be a domain controller.
The Essentials server must hold all the FSMO (Flexible Single Master Operation) roles. If you want to learn more about the FSMO roles here is a good article.
Only one domain is permitted in the forest where the Windows Essentials edition server resides.
No forest/domain trusts are permitted.
The Remote Desktop Session Host role feature is not supported and typically will not function.

So what if the server is not a domain controller or violates one of the rules above? This is where the Server Infrastructure License Service comes into play. This service regularly checks the server to verify it is not violating the EULA (End User License Agreement). If a violation is found the server will shutdown every 27.67 days (27 days, 16 hours). Why Microsoft chose 27.67 days, I have no idea. Before it shuts down though it will warn you. The events will show up in the Server Infrastructure Licensing log.

The next question is how do we fix these errors. I have seen three causes for this issue. Let’s go over each one and how to fix it. After you believe you have fixed the issue, see the the next section for a way to confirm the issue is resolved.

The first cause of this issue is also the most painful to fix. If the server is demoted, and put into a workgroup it will cause this issue. All checks will fail because the domain can no longer be contacted. Unfortunately the only fix is to reinstall Windows on the server.
The second reason these errors might crop up is due to the check failing due to an issue with Active Directory. For instance, if the server is not advertising as a domain controller due a SYSVOL issue. If an Active Directory issue is suspected, the first place to start should be to run a dcdiag. Dcdiag will test the basic functionality and report any issues found. As stated above, if there are SYSVOL issues, then the server will likely fail the advertising test.
The last reason I have seen on more than a few occasions is the following error:

Log Name:      Microsoft-Windows-Server Infrastructure Licensing/Operational
Event ID:      2
Level:         Error

Description:The Forest Trust Check in the Licensing component did not pass because error 0x80070008 occurred in function fe1 [YJBI].
Not enough storage is available to process this command.

This error seems to indicate that we are low on hard drive space. However this is not the case. This error is actually referring to a special pool in memory (RAM, Random Access Memory) called the heap. The heap is a finite size, regardless of how much RAM is in the system. Normally Windows will not experience a heap exhaustion, that is where this special pool of memory is completely depleted. However, if a program or driver is leaking memory, then the pool will eventually run out. In case you are wondering what a memory leak is, it occurs when a program or driver allocates memory, but does not free it when complete.
So in essence this error is caused by a malfunctioning program or driver. The good news is that every time I have seen this issue in Essentials or Foundation it was caused by a printer driver. There are 2 ways to fix this problem. The first way is to simply restart the printer spooler service. Restarting the printer spooler service unloads the printer drivers and frees all memory associated with them. This will temporarily eliminate the issue. A scheduled task could then be created to automatically do this on a regular basis. The optimal solution though is to find the problem driver and either remove or update it.

So to this point we have covered some of the pros and cons of running Essentials, what happens when the EULA is violated, and some common causes for the Server Infrastructure Licensing service shutting down the server. The last item I wanted to cover is how to force a new compliance check from the Server Infrastructure Licensing service. This process works for both Essentials and Foundation edition. This is useful if you are seeing compliance check errors, have taken measures to correct them, and now want to test if the issue is resolved. It is surprisingly easy to force a compliance check. Only one PowerShell command is required. Ensure you run PowerShell as administrator when running this command.

Stop-Process -ProcessName silsvc -Force

The above command forces the Server Infrastructure License service process to stop. The process will then immediately start again. The trick here is that the Server Infrastructure License does a compliance check every time it starts. You should see a compliance check within 2-3 minutes after the service stops.
Well, we covered a lot of ground with this post. If you have any questions, or any suggestions please add a comment below.

Fixing RDS when it has been improperly deployed

Posted on April 20, 2016April 20, 2016 by Glenn

In the last few articles I walked you through setting up RDS (Remote Desktop Services) in a domain, or a workgroup, and installing and activating CALs. Today I wanted to touch on how to fix RDS when it has been improperly deployed. The good news, it is typically very easy.

Typically when RDS is deployed improperly the user has installed the Session Host manually via the add roles wizard. While this is fine in a workgroup, it does not work properly in a domain environment. If this is the case, just running the Remote Desktop Services installation wizard is typically enough to fix the deployment. Just follow this guide. I have had about 90% success rate with this.

But what if the Remote Desktop Services installation wizard fails or does not complete? Don’t fret. More than likely the issue can still be resolved without removing the roles. Below are the two most common issues that I have run into when fixing an RDS deployment.

The Remote Desktop Services installation wizard fails to create the Session Collection and remote apps. Usually when this happens it is because the user has attempted to fix the installation with Group Policy. There are two legacy group policy settings for specifying the license server and license mode. These settings are not supported in 2012, do not work, and will cause the Session Collection wizard to fail. The fix is simple, remove the group polices. Set them to Not configured. Here is a screen shot of what the policies should look like and their location.
Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Licensing
The Connection Broker role service role fails to deploy and the Remote Desktop Services installation wizard indicates the server requires a restart. Rebooting the server and running the wizard will again indicate a reboot is required.
The first time I ran into the this issue it took me a bit of time to track it down. After rebooting the server and checking for the file C:\windows\winsxs\pending.xml, and not finding it. Additionally, checking the c:\windows\log\cbs\cbs.log and seeing that a reboot is not pending, I was confused. I then dug deeper into the cbs log and found that the installation was being rolled back and that roll back required a restart. So why was the install failing? The key is an error logged in the system log during the install.

Log Name: System Source:
Service Control Manager
Event ID: 7041
Level: Error
Description: The MSSQL$MICROSOFT##WID service was unable to log on as NT SERVICE\MSSQL$MICROSOFT##WID with the currently configured password due to the following error: Logon failure: the user has not been granted the requested logon type at this computer.

Service: MSSQL$MICROSOFT##WID Domain and account: NT SERVICE\MSSQL$MICROSOFT##WID

This service account does not have the required user right “Log on as a service.

The Connection Broker service requires a SQL database to store its data. By default it uses the WID (Windows Internal Database). Because the WID cannot start, the Connection Broker role service install fails and the install has to be rolled back. This typically only occurs when the RDS server is also a domain controller. It is possible though on a member server if security has been tightened. The fix is fairly easy and is documented in Microsoft KB 2832204. Because this typically occurs on a domain controller though, you cannot simply edit the local group policy or the local security policy. You must create a new GPO (Group Policy Object) and link it to the domain controllers container. Here is the process.
1. On a domain controller, launch the group policy management console. (gpmc.msc)
2. Expand Forest, Domains, your domain name, then Domain Controllers.
3. Right-click on the Domain Controllers container and choose Create a GPO in this domain and Link it here.
4. Give the GPO a descriptive name like “Allow WID logon on DC” and click OK.
5. Right click the new GPO and choose Edit.
6. Navigate to the following location: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment
7. Right-click on Log on as a service and choose Properties.
8. Check the box to Define these policy settings.
9. Click on Add User or Group and add the following user: NT SERVICE\ALL SERVICES
10. Click OK and close the Group Policy Management Editor window.
11. To make the setting take effect immediately, run gpupdate /force at an administrative command prompt.

If the above solutions did not resolve the deployment issues with RDS, there is another option. If all else fails, remove all RDS role features* and start the deployment over again. As bad as this sounds it typically only takes 30-60 minutes to remove the roles and redeploy correctly.

If I missed anything, please submit a comment below. Thanks for reading.

* If Licensing has been configured and RDS CALs (Client Access Licenses) added, it is typically best to not remove the licensing role feature. That is unless you enjoy calling the Microsoft clearinghouse. 🙂

How to properly deploy Remote Desktop Services in a workgroup

Posted on April 7, 2016July 9, 2021 by Glenn

I have previously written an article on setting up RDS (Remote Desktop Services) in domain environment. However, what if there is only one server and/or there is no domain? It is still possible to setup RDS, but the process is a little different. Connection broker, a component of RDS, does not work properly in a workgroup environment. Also it is not possible to use Remote App, another component of RDS, or create a session collection. Without a session collection, Session Host, yet another RDS component, will not be able to obtain licenses. Without licenses RDS will cease to function after the initial grace period. Typically this is 120 days. We get around this by manually editing the WMI attributes for Session Host.

Here is how to properly deploy RDS in a workgroup. I am going to use PowerShell to make this quick and easy. This guide is applicable for Windows 2012, 2012R2 and 2016 in a single server workgroup environment. If you have Windows Server 2019 or higher the process has changed. Skip to the bottom for that process.

Launch a Windows PowerShell using the Run as Administrator option.
Run the following command to install the RDS components that are required. (This will automatically restart the server)
Install-WindowsFeature RDS-RD-Server,RDS-Licensing -IncludeManagementTools -Restart
After the server restarts, log back in.
Launch a Windows PowerShell using the Run as Administrator option.
Run the following commands to manually configure Session Host*.
- $obj = gwmi -namespace “Root/CIMV2/TerminalServices” Win32_TerminalServiceSetting
- $obj.ChangeMode(2)
- $obj.SetSpecifiedLicenseServerList($env:computername)

The next step is to activate the RDS license server and install RDS CALs. You can find an article on how to do that here.

* On the $obj.ChangeMode() command:
$obj.ChangeMode(4) = Per User licensing
$obj.ChangeMode(2) = Per Device licensing (supported mode for workgroups)

An update to this article. It appears in Windows Server 2016 and 2019 Microsoft is enforcing Per Device mode in a workgroup configuration. So if you install RDS in a workgroup in 2016 or 2019, you should use Per Device mode. This is not usually an issue as RDS CALs can be converted between Per User and Per Device in the licensing manager.

Another update, July 2021. Microsoft has changed the process for Windows Server 2019. The above PowerShell script will fail to set the mode. To properly do this the registry needs to be edited.

Open Registry editor (Right-click Windows logo at the bottom left and choose Run. Type regedit and hit enter.)
Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core
Verify there is a DWORD for “LicensingMode” and it is set to 2. If not present, right-click and choose New-> DWORD (32-bit) Value. This must be set to 2 for “Per Device”
Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers
Verify there is a Multi-String for “SpecifiedLicenseServers” and it is set to the server’s name. If not preset, right-click and choose New->Multi-String Value.
Reboot the server.

How to properly deploy Remote Desktop Services on a single domain joined server

Posted on April 2, 2016 by Glenn

I have seen so many deployments of RDS (Remote Desktop Services) done incorrectly in Windows Server 2012/2012R2 that I wanted to get the correct process out there. Unlike previous versions of Windows, RDS in 2012 must be deployed with the RDS installation wizard. There is one exception to this rule. When there is only one server and it is in a workgroup, the deployment works differently. I will cover that deployment in another guide.

This guide is applicable for a Windows 2012/2012R2 server that is joined to a domain or is a domain controller. Following the below steps will take you through the setup of the first RDS server.

Join the server to the domain. If the server is also to be the domain controller*, install the ADDS (Active Directory Domain Services) role and promote the server.
Launch the Add Roles and Features Wizard in Server Manager.
1. Launch Server Manager
2. At the top right, click Manage
3. Choose Add Roles and Features
On the Installation Type screen, choose Remote Desktop Services installation and click Next.
On the Deployment Type screen, choose Quick Start and click Next.
On the Deployment Scenario screen, choose Session-based desktop deployment and click Next
On the Server Selection screen, verify the server is selected and click Next.
On the Confirmation screen, check the box to Restart the destination server automatically if required and click Deploy. The server will automatically reboot.
Log into the server after the reboot. The wizard will automatically launch and the deployment should complete. Close the wizard when complete.
Go back to Server Manager. On the left side click on Remote Desktop Services. You should see a screen similar to the following.
Click the + symbol above RD Licensing. This will launch the wizard to add a licensing server.
Add the server to the Selected list and click Next.
Click Add. When the process completes, click Close
Click the TASKS button next to DEPLOYMENT OVERVIEW and choose the option to Edit Deployment Properties.
Click the RD Licensing option on the left side. Choose the licensing mode that matches the RDS CALs purchased. The licensing server should already be populated. If it is not type in the FQDN (Fully Qualified Domain Name) and click Add. Click OK.

You now have a very basic setup of Remote Desktop Services. The next step is to activate your license server and install your RDS CALs. I will write an article on that process in the near future and update this article once it is published.

*Microsoft discourages making an RDS server a domain controller. If it is required, see this technet article.