NIC Location on domain controller shows Public network

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)

Deleting print jobs in Error on print server

I had a problem in an environment where all users print thru one print server. The printer was worst one and we always had problems to delete some jobs in error. The users were also unable to print when the printer had a job in error. So, we wanted to automate that procedure to keep printers alive as much as possible.
In this case, we found two different but similar solutions, both in PowerShell.
The first is to delete jobs in non-working hours (true the night). We used the script:

get-printer | where {$_.PrinterStatus -ne “Normal”} | get-printjob |Remove-PrintJob

This script deletes all jobs on all printers where the status of the printer is not normal. This are pros and contras:

  • It runs thru the night, so the printer could be offline for whole day,
  • All jobs on the printer are lost. We preferred to do it in this way, as we didn’t know what kind of jobs were in the queue. It could a confidential information and is better to lose the job as leave those papers in the printer,
  • It has minimum impact to the print server.

The second option is running a similar script every few minutes:

get-printer | Get-PrintJob | where {$_.JobStatus -match “Error”} | Remove-PrintJob

This script has those pros and contras:

  • It could be run every few minutes and printers are really many time online,
  • It has more impact on the print server as the previous, but the impact is still minimum. There is not real difference in server usage.

After consulting with the customer, the best choice was the second version, running every 5 minutes. Now we have printers really with better uptime and the server is running practically on the same performance. Be careful that you run this script with an account who has permissions to delete print jobs (Print Administrator) and it will work. Anyway, if it is possible is always better to find the cause of errors and repair it. It is not always possible, but try to do it, before you use the script.
Still I am convinced that the best way to solve this type of issues is assign the second option directly to an error. When the printer is going to error, it is acknowledged as Error 372; Source: PrintService. You have just to assign a task to this error..

RDP 2012R2 Web access? Why not!

Publishing terminal services through the web is more and more popular and I am still convinced that we have to use them more. Maybe with publishing this article I will help someone to decide and publish them. In this article, it is nothing new or revolutionary; there are practically few tricks, that my customers like.
There are many changes, in working with remote applications, that are coming with Windows Server 2012. After some of us really appreciated publishing remote applications with a method of distributing RDP files or MSI installers in Windows Server 2008 and 2008R2, now it is not possible to do it anymore. Many changes are visible also in the installation of RDP rules. Now we have separate steps form installing “just rules and features” – this is a good thing, because doing installation this way, there are not so many errors in RDP deployment and it is the only right way for installing web access and other RDP rules (don’t do it through rules and features!!!).
In addition, this WEB access is the functionality where I want to show some tricks.
As we know, the address is the address, where we can access to our applications. Here you can see a desired application instantly after it was installed and published.
Many times we have unhappy users, because for running those application they have »a lot of work« – they have to type this web address and login… Other not nice functionality of this web interface is that some browsers are unable to run RDP file directly from the web and they have to download it and run it.
Here we can do something for our users. In Windows 7 and newer, in the control panel it is present a setting called Remote App and Desktop Connections. This is exactly what we want to do. Just type in the apposite text box the published web address and add in the end feed/webfeed.aspx (example: This setting will put all published applications to which user has access to his Start menu under Work Resources (RADC). Need more? They are also dynamic; if you revoke permissions or deinstall application, the application will disappear from there. In addition, if you add a new one, it will simply appear there. Nice.
It is still too complex for your users? OK. Then we can try making this easier for them. There is an option to write the E-Mail address. In this case, E-Mail is used only for getting the domain name. All other work is done by DNS setting and all other process is equal as you write down a published address. Of course, the domain used in the E-Mail address must have a TXT record with this few parameters:

  • Type:                  TXT
  • Record Name:    _msradc
  • Text:         

The text is the same as you have to write it manually and the domain can be published in a different way, as is the domain in the E-Mail address. Therefore, you have really many opportunities and a user needs to know only E-Mail address, username and password. Things that, I hope, he knows.
There is also another great thing: if you publish applications this way, you can publish them from different servers and domains at the same time and you can have contemporary access to services from different hosted services / clouds. It’s great!

There is also another simple change that you can do in Internet Information Service (IIS) console. Just open the console and go to the location Sites > Default Web Site > RDWeb >Pages. At this point, open Application settings. As you can see on the picture, here are many settings that can help you with configuration:


  • DefaultTSGateway – It is used to fix which RD Gateway will be used.
  • Password Change enabled – It enables the option to change the password in RD Web console. It is very useful when a user has only RD access to our environment. But you have to be careful here, because if the user with a domain joined PC changes his password from outside, maybe he will lose some other offered services on his PC.
  • ShowDesktops – It is a setting, that determinate if it is a section »Connect to a remote PC« visible or not. Some companies want their employees to connect remotely to their PC’s, other don’t allow this option. Don’t forget, that RD connections true RD Gateway will still work, even if this setting is disabled!
  • Enabling or disabling redirections – This is actually an alternative place, where you can enable or disable redirections for printers, ports, drives, PnP devices and clipboard for all RD users. The same thing you are able to do through policies.


Publishing Remote App thru DNS

If you are delivering Remote Apps to clients via control panel (available only in Windows 7 and newer systems), you can do it in two ways. You always have to open Control Panel > Remote App and Desktop connections and here you have two options:

  • Specify the internet address of RDWeb server,
  • Specify the E-Mail address (only in Windows 8).

RDPublish1The second option sounds strange; how will I receive my RD application with specifying only the E-Mail address? Actually it’s very simple. If you specify your E-Mail address, you tell to the system your public domain name and we know where to look for the corresponding record in the DNS. Therefore, in this case, you need to add a specific DNS record to locate your RDWeb server. This is a TXT DNS record with the following information:

  • Record Name: _msrade
  • Text:

Of course, in the text you have to change with your real RDWeb server name and be careful because the end of the string webfeed.aspx is excluded!
RDPublish2The another important thing to know is that the entered E-Mail address is used only to discover a RDWeb server address and later you will be asked to enter your credentials (form this we can deduce that the E-Mail address can be different as the User name).
This approach is very useful for hosters, because they are able to link many hosted domains to only one RDWeb server..

Windows Server 2012 and 2012R2 documentation

Microsoft did a good work with Windows Server 2012 and 2012R2 documentation. They put together all TechNet documentation to one PDF document, so now you can have concentrated all the server documentation in one single file. It is complete, easy to find (OK, there are approximately 8000 pages…) and all in one place. Very nice.

This file is downloadable from TechNet by clicking this link..