RDS: HP Thin OS resolution problem in Full Screen mode !

Hi everyone

Today I wanted to share a small error I found into the HP thin client that has the Thin OS.

The error impact that RDP setting when you create a RDP connection;

The resolution can bug on the setting page. You ask me what bug it can cause ? well if you do a RDP’s session in fullscreen mode, the user will think they use a resolution X, but in reality the terminal server will see the correct resolution Y.

The bug happen with different display adapter or monitor.

The Thin OS seem to detect the possible resolution from the monitor and limit the choice, but the GUI is not limited to that list. xrandr offer a list while the GUI offer the full list.

As you can see in that printscreen is that exact problem, I set 1280×768 into the left windows, no error, and it’s set, but in the right windows we see the current resolution is 1920×1080 and 1280×768 is not possible..

The tip is to issue an xrandr command to see what we can use;

and to set it to one of those resolution..

For me it’s a bug, as if you manually set the resolution with xrandr, like in my example 1280×768 that I tried without success with the GUI, but it work if I set it with xrandr by hand.. but no config file are possible to change to add an custom mode resolution.. So the change is lost on reboot.

Enjoy the small tip, got me some time to manage that the GUI is in error.

Advertisement

Unable to rename domain controller: Account already exists

Hi everyone

I seen an interesting bug yesterday, it was about Windows Server 2019 and a error when you try to rename a new domain controller to the old name of a retiered’s one;

The error Windows was giving was:

The account already exists.

The culprit into that case was a left over that was visible in ADSI Edit. The exact location was;

Configuration -> CN=Sites -> CN=Default-First-Site-Name -> CN=Servers -> CN={Old Domain Controller}.

 

As simple as that, but it need a bit of playing in ADSI Edit 🙂

 

Windows Update Error 80243004

Hi everyone

If you stumble into the Windows Update error 80243004 please know there is an easy way to resolve it.

The bug is related to missing icon in the systray, so we go check there, we right-click the systray and click property;

We click personnalize;

On that windows we click to show all icon in the systray.

 

After that the Windows Update should work correctly 🙂

Windows 10 and the faulty network adapter

Hi sysadmin !

Today I wanted to share a small bug I encountered, and how to solve it.

After all the update, if you lost all your network connection, and in your device manager they are all yellow in error, please check the status of them;

Network Adaptor error: Windows is still setting up the class configuration for this device. (Code 56)

If that happen to you, any new devices you will try to install will fall into the same state.

The Windows update will try to reinstall the driver, but will fail.

The recovery step is easy, check your VPN software installed, one is not Windows Ready for that build.

In my case it was CheckPoint VPN

Uninstall and the bug disappear live, no reboot necessary !

Windows Server 2019 RDS: Install Error: dismapi_error__failed_to_enable_updates rds-web-access

In Windows Server 2019, if you ever find yourself hit by a bug when you try to add the rds-web-access, then please follow these step;

Problem

In the eventlog

Install-WindowsFeature RDS-Web-Access -IncludeAllSubFeature
+ CategoryInfo : InvalidOperation: (@{Vhd=; Credent…Name=localhost}:PSObject) [Install-WindowsFeature],
Exception
+ FullyQualifiedErrorId : DISMAPI_Error__Failed_To_Enable_Updates,Microsoft.Windows.ServerManager.Commands.AddWindowsFeatureCommand

Step tried

• Installing with Server Manager GUI
• DISM /Online /Cleanup-Image /RestoreHealth
• DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:1 /limitaccess
• sfc /scannow
• Install-WindowsFeature RDS-Web-Access -source D:\sources\install.wim
• Install-WindowsFeature RDS-RD-Server -IncludeAllSubFeature will work at first, but revert the change at the reboot.

Issue

A previous installation of IIS is the culprit

Solution

Removing IIS:

After that; then you migh have to remove the IIS directory completly;

netsh http show urlacl

netsh http delete urlacl http://+:80/ netsh http delete urlacl https://+:443/

Windows Machine Unknown state on ESX

Today I will share a small tip if your Windows VM get an Unknown state in your ESX.

The problem can be easily fixed by first removing the machine from the inventory, without deleting the files.

After that you will have to go back into your datastore to re-add the machine back to the inventory, by right-clicking the .VMX file, and select the Add to Inventory option.

 

After that the state will be green 🙂

RDS: Published App + Dell / Wyse ThinOS + Juniper DHCP relay’s option

Hi everyone

Today I wanted to share a bug I had with some Juniper SRX-100 model and newer, when with the SSG5 it was ok.

The bug appear on the terminal when they boot on a remote subnet (DHCP relay), the DHCP take time to deliever them an IP from the DHCP relay. The problem does not appear in the local subnet where the DHCP server is. The problem appear only on newer tunnel with the Juniper.

After a *lot* of research I found out that the newest JunosOS does not handle correctly custom DHCP’s option when the relay happen…

For reference all the possible option. The important’s one in my case is the 161

The terminal were getting the IP of the server where the root configuration is, where the root configuration to pre-configure the terminal with all my RDS’s option.

The problem found was the Juniper don’t handle correctly an IP into that field, like if the ftp server is named CENTRAL_FTP with the IP 192.168.1.50, then you must use the short DNS’s name, not the full FQDN.

In my case I changed the DHCP option from  192.168.1.50 to CENTRAL_FTP and maked sure the DNS option was set correctly, and voila, the DHCP’s option started to work flawlessly via my VPN tunnel with the Juniper !

Strange bug it’s, but kinda why I share it, took time to find that culprit !