RDWeb client error: »An unexpected server authentication certificate was received from remote PC«

If you are using HTML5 web site for remote apps and you have to change a certificate, you may expect some problems.
This technology is pretty new and there are not so many posts on internet, so troubleshooting could be difficult. In addition, you have more technologies and this means more problems.
I adopted HTML5 long time ago and everything worked fine for a long time. I have to say, that it was better that I expected. But now I have to change the certificate. Well, this is not a complicated job… or it is? The answer is yes, it is.
I have changed my certificate as usual, form server manager. I tried to connect to website and everything was OK. Then I tried to launch an application and I got this error:

RDP HTML5 Connection error
Wow, what to do now?! I remember that when I setup web client framework, I had to run PowerShell cmdlet to register the certificate. So, if I had changed the certificate, I have to register a new one – rerun PowerShell cmdlet —— .
This apparently didn’t solve my issue because from my computer it seems the situation haven’t change. But then a customer tried to work from a new computer and it worked! Why???
The reason was in cookies and cache files on the computer browser! Yes, you have to delete all cookies and cache files and (at least in my case) the webpage will work again.

RDP HTML5 Firefox setting RDP HTML5 Edge setting

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..

Many free tools for administrators

For any administrator, who want to use any kind of free tools to have better access or monitor some functionalities in Windows environments, here we have a list of many free tools. Just look which is usable for you and use it:
https://4sysops.com/best-free-windows-admin-tools/
And please, test it in test environment prior you use it in production. Many times tolls are not exactly the same as you expect..

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 https://rdp_server.publicname.com/rdweb is the address, where we can access to our applications. Here you can see a desired application instantly after it was installed and published.
RDP Web
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: https://rdp_server.publicname.com/rdweb/feed/webfeed.aspx). 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:                   https://rdp_server.publicname.com/rdweb/feed/webfeed.aspx

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.
RDP2
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:

RDP3

  • 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: https://myrdwebserver.mydomain.com/rdweb/feed

Of course, in the text you have to change myrdwebserver.mydomain.com 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..