IGEL OS – VirtualCam User Settings

IGEL OS – VirtualCam User Settings

Using a webcam on a virtual desktop environment can be easy. Or it can be tricky! Read on to learn about highs and lows and what a VirtualCam has to do with it…

Where I work, we get confronted with lots of users who got their own ideas and requirements. Usually in IT, one would enforce a concept or a policy but this is not always the best solution.

For example in this case, we gave some users a mobile device (Laptop) installed with IGEL OS 11 as a thin client. The requirement that has just reached me, was to be able to use a webcam in a browser based video conferencing app. Sounds simple, huh?

The main problem without VirtualCam User Settings

On a thin client, users are usually connected to a virtual desktop environment – In our case Citrix Virtual Apps and Desktops. You do usually also not want to spend too much bandwidth on transferring video data. This is especially true for mobile clients which might access the system from external locations through an ADC (NetScaler) where you license bandwith.

The solution to this any many more issues (Buzzword: GPU requirement) is offloading.

Optimized Apps using Citrix Virtual Channel

The most common video conferencing providers like Cisco (WebEx) and Microsoft (Teams) have elaborated ways to split using their apps in a server- and a client component. This is very cool but unfortunately in our case the application was different. It’s a HTML5 app.

Browser Content Redirection

The second idea was to use Citrix Browser Content Redirection (BCR) to offload the whole webpage to the client OS. Long story short: The Application was unable to even start. The scripts were too complex to be redirected. We failed with about a thousand javascript errors.

The final solution: Citrix HDX Camera

The “fallback” is redirecting the video. Fortunately our Terminal Servers have decent GPU cards installed which allows us to process video very efficiently. Because of this, we “only” needed to enable HDX Camera Redirection. After some struggles in the first place (which were citrix policy issues) we managed to redirect the camera using this basic citrix feature quite well and it works as expected.

So far, so good…

Here comes: The User!

So initially I told, that we got some special requirements… There you go: It didn’t take long until someone figured out that their cam was actually not working as expected.

What happened?

During the pandemic we were forced to buy several different webcams as availability was a problem. So now we got about 5 to 10 different camera models plus integrated cameras in some devices. In the end a user might even have two or more cameras available, but HDX only redirects the “primary” camera (as in the first one enumerated). And this was always the integrated laptop camera for us.

How we solved it using VirtualCam

IGEL luckily just introduced the “Virtual Camera Background” feature in IGEL OS 11.08. This not only allows to blur the background for any application. It additionally provides a registry setting to set the camera source to a specific camera (by name, number or VID/PID). Then it replaces the main camera by the virtual one. This VirtualCam is then redirected by Citrix HDX.

This was the basic solution but we would need to configure the camera for every single client using the registry. While possible, that’s an annyoing sysadmin task. Additionally, a mobile user are changing workplaces from time to time. They are then often forced to use a different cam (like integrated on mobile, monitor cam at their desk).

Power to the user – Let them control VirtualCam settings!

I created a script that can be deployed to an IGEL Thin Client and linked as a custom application to allow the user to toggle and configure the VirtualCam feature.

All you need, is a basic profile to configure the Custom App and the basic VirtualCam parameters. The shell script I wrote contains the required logic.

How to install

To install the script, eighter put it into a custom partition or use the UMS’ files section to upload it into /wfs/. (For the following we assume, you uploaded the file to /wfs/virtualcam-config.sh )

Then import the profile from the XML. Make sure that your firmware feature restriction does not remove any of the Virtual Camera Background features.

The profile creates a new Folder on the desktop called “Settings” and puts a link in it, called “VirtualCam”. You might want to change that under desktop integration.

Work Done!

Are you using uncommon video conferencing tools, too?
If yes, which and did you already encounter such a situation yet? How did you solve it?

Multiple VLAN’s using Windows 10/11 Onboard Tools

Multiple VLAN’s using Windows 10/11 Onboard Tools

As Intel recently deprecated their ProSet tool for Windows 11, I had to find a solution to continue operating some computers which have to connect to multiple VLAN interfaces.

Right now those computers use a single NIC, connecting to a switch which has enabled VLAN tagging. Unfortunately (of fortunately?) most of our computers are currently running a realtek NIC. VLANs are currently configured using their Diagnostic Utility.

Fortunately (or in this case unfortunately?) our latest generation of hardware now comes with an Intel network chip. This change was pushing me into this new issue: How do I configure multiple VLANS under Windows 11 on an Intel NIC?

The Issue

Intel used to have a quite easy configuration for multiple VLANs in their advanced driver settings but as I already noted: The ProSet tool including the advanced driver functions has been discontinued by Intel.
So now, I had to find a new way to solve that demand.

On Linux you can create virtual nics easily as the VLAN function is built into the network stack of the linux kernel but I knew that windows was not able to do similar – and I was wrong-ish.

Examining the advanced tab of my NIC, I’ve seen that setting a single VLAN ID is not hard, it can be done in advanced properties of the NIC or using powershell. In our case, as we need to operate on multiple VLANs things are different. There is no option to add a virtual NIC so I started tinkering.

The solution is Hyper-V

So after some research I found out, that Hyper-V is VLAN aware and you can use their network stack without installing and running the full hypervisor. Additionally you can create multiple virtual Host-NICs attached to a VLAN aware Hyper-V-Switch.

Sounds like Rocket science? It is actually quite straight-forward but you need to configure that using powershell.

Step 1: Installing the Windows components

In the windows feature installation dialog, we have to install the two components called “Hyper-V-Services” and “Hyper-V-Module for Windows powershell”

After the setup is done, you have to reboot the computer.

Step 2: Setting up the vSwitch

Hyper-V automatically creates a “Default vSwitch” that you can not delete and unfortunately it is not VLAN-Aware. We will have to keep this one as it is and go ahead creating a second vSwitch. For this, we need to open up powershell as an administrator and enter the following commands.

Your host will lose it’s network connection – Do not do that remotely or with apps running.

# This will return a list of network adapters, find your physical NIC and note its "Name" - In most cases "Ethernet"

# This creates a new vSwitch named VLAN-vSwitch and bridging our physical NIC called "Ethernet". Also we allow to add virtual Host-NICs to this switch.
New-VMSwitch -name VLAN-vSwitch -NetAdapterName Ethernet -AllowManagementOS $true

# Hyper-V automatically creates a virtual NIC without a VLAN tag to keep the host online - Remove it, except you are using a Untagged/Tagged combination.
Remove-VMNetworkAdapter -ManagementOS -Name VLAN-vSwitch

We do now have a clean new VLAN-Aware vSwitch

Step 3: Setting up VLAN interfaces

# Now we create a new virtual Host-NIC and assign a VLAN tag 123 to it. Please note, that the interface name can be chosen freely. One might want to name them by purpose.
Add-VMNetworkAdapter -ManagementOS -Name "VLAN123" -SwitchName "VLAN-vSwitch" -Passthru | Set-VMNetworkAdapterVlan -Access -VlanId 123

# You can now add as many virtual NICs as you need
Add-VMNetworkAdapter -ManagementOS -Name "VLAN456" -SwitchName "VLAN-vSwitch" -Passthru | Set-VMNetworkAdapterVlan -Access -VlanId 456

# Finally, verify that all adapter are in place


Thats all you need to do. You do noe have replicated the VLAN feature of Realtek Diagnostic Utility or Intel ProSet with windows “onboard-tools” and this solution should be compatible with any available NIC.

What do you think? Is this a clean solution or do you still preferr using other tools, if so – which?

Title Photo by Taylor Vick on Unsplash
Migrate Proxmox Backup Server

Migrate Proxmox Backup Server

I was recently confronted with the issue that I needed to move a running Proxmox Backup server to a new host. Along the migration I also needed to update the hostname to match the new concept. However, it does not really matter if you keep the hostname or not as fortunately PBS does not really care about it’s name.

Step 1: Research

As a senior admin I know you can usually find out anything you don’t know yet using google (ar any other search enginge out there). This time however I had a hard time. Looks like virtually nobody tried to migrate a PBS yet – or maybe the fact tht it is so easy leads to noboy writing the process down.

Okay, let’s do it on our own!

The Facts

Currently PBS is running an an “old” Proxmox VE host – and I mean on the physical host. We are migrating this PBS installation to a dedicated host, a VM on Hetzner’s cloud this time. As the PBS is only occasionally taking load and the backup performance does not really matter for our project, I chose a CX21 VM with 2 vCores and 2GB of RAM. The 40 GB HDD space are enoght for the OS and PBS’s own files. Additionally a Hetzner Storage Box is available to be used as the actual datastore.

In this case the chunks (the actual backed up files) have already been stored to the Storage Box. This means in this blog post I will not migrate the actual data but if you need to, it is as simple as rsyncing the data (rsync -azh source target) from one place to the other, just take care that the mount path is the same on the new server and stop the services on both servers before migrating!

Step 2: Preparation

The Cloud VM

First of all, I booked a CX21 cloud VM from Hetzner located in the same datacenter as the storage box resides. This is very important! Using a VM in FSN1 and storage box in HEL1 has very bad performance. I mean performance like when you’re driving right behind a farm tractor on a highway.

I chose Debian 11 (and you should do so, too). Right after the setup completed, I logged in using SSH and edited /etc/hostname to include or FQDN hostname – don’t forget to add a DNS entry!

As mentioned, our chunk data is stored on a Hetzner Storage box. I copied the respective line from fstab from the old server to the new one and created the mount path using mkdir /mnt/hetzner-sb1 in my case. For reference, this is what it looks like now (username/password redacted):

//u1234567-sub1.your-storagebox.de/u1234567-sub1 /mnt/hetzner-sb1 cifs username=u1234567-sub1,password=GeneratedPaSsWoRdFromRobot,uid=34,noforceuid,gid=34,noforcegid 0 0

Then I mounted the box using mount /mnt/hetzner-sb1 and verieifed by running an ls /mnt/hetzner-sb1

Install Proxmox Backup Server software

We need to do a clean install as docuemnted here. The commands are simple and reliable:

Trust the repository key: wget https://enterprise.proxmox.com/debian/proxmox-release-bullseye.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bullseye.gpg

Add the repo to apt sources: echo "deb http://download.proxmox.com/debian/pbs bullseye pbs-no-subscription">/etc/apt/sources.list.d/pbs.list

Download package lists: apt update

Install the software: apt-get install proxmox-backup

You could also install proxmox-backu-server instead of proxmox-backup. The proxmox-backup package contains all recommended extra packages, the other onwe is a minimal setup.

Disable 2FA temporarily

If you can, you should remove 2FA configuration from the root user before migrating or create a new administrative user without 2FA if WebAuthN is used. Else you might not be able to log in anymore.

If you are changing the hostname along the migration like I do you are required to deconfigure WebAuthN and reconfigure it after migration as the hostname is the "key" for WebnAuthN accounts on the token.

Stopping services on old and new server

It is important that no backups or other jobs are running while you are migrating. Run these commands on both servers:

service proxmox-backup stop

service proxmox-backup-proxy stop

Make sure that no job or task is running before stopping the services.

Step 3: Migrate config and metadata

Proxmox backup server stores its configuration in /etc/proxmox-backup and metadata (rrd stats etc) in /var/lib/proxmox-backup – We need to sync both folders to the new host (assuming the new host has IP using rsync on the old host:

rsync -avzh /etc/proxmox-backup/* root@

rsync -avzh /var/lib/proxmox-backup/* root@

Step 4: Reboot the new server

To make sure all configs are applied and all services are running smoothly, we will now reboot the new server and verify our installation and migration.

After the reboot, visit (use the IP-Address for now)

You whould see your datastore on the dashboard now – including historical usage data graph. If so, select the datastore on the left hand menu and select the content ribbon. You should see all backups there. This might look a bit like that:

Great! The worst part is over. If you preserved the hostname, you’re done and can proceed to step 7.

Step 5: Configure SSL

This step does not apply if you keep the hostname while migrating.

Now you will need to setup Let’s encrypt again (or use your preferred method). You can do this at Configuration -> Certificates. Simply click the add button and enter yor FQDN there:

You may also want to remove the migrated old certificate. Then click the “Order certificates now” button. If everything runs smoothly, you should now have a valid SSL-certificate:

Verify this by pointing your browser to https://your-hostname.your-domain.tld:8007/

If the certificate is no used immediately, restart the proxmox-backup-proxy service

Step 6: Configuring the clients

This step does not apply if you keep the hostname while migrating.

Now you have to direct your clients to use the new server. For manual backups using proxmox-backup-client you need to edit the cronjobs or backups scripts. For Proxmox VE you can simply edit /etc/pve/storage.cfg (for example using nano) and change the “server” directive of the storage block:

Proxmox VE will reload the changed file automatically after a few seconds.

Step 7: Testing

You should try to backup a client to see that everything works. In my case I ran a manual backup from my Proxmox VE server:

While the backup is running, you will also see that in the "Tasks" bade on the top right corner of your PBS server.


You should monitor your upcoming backups and verfiy them using PBS’ builtin verifications to make sure all chunks are accessible, especially if you also migrated the chunk storage.

Also don’t forget to re-enable 2FA if you disable dit before….

…and if you changed the hostname, you have to reconfigure WebAuthN under Configuration -> Other (and the other is located at the top if you click on Configuration – The did a good job in hiding that!)

I hope you were able to follow my steps to successfully migrate your PBS installation in a rush.
Tell me, did you encounter any issues?

Valve Index: VR an der Leine – Erfahrungsbericht

Valve Index: VR an der Leine – Erfahrungsbericht

Wer mich oder den hauptsächlich von mir bedienten Twitch-Kanal von Firesplash Entertainment kennt, weiß, dass ich gerne hin und wieder für ein paar Stunden Beat Saber in die virtuelle Welt (VR) abtauche. Eine schöne Möglichkeit, vom sonstigen Alltagsstress etwas Abstand zu nehmen. Setzt man die Brille auf, ist die reale Welt erst mal auf pause, fast schon weg.
Genutzt habe ich hierfür bislang eine HTC Vive, welche ich Anfang des Jahres günstig gebraucht erstanden hatte. Auch das TPCast Wireless Kit war hier zu meinem Glück mit dabei, denn in eine virtuelle Realität eintauchen ist zumindest für mich schwierig, wenn man von einem Kabel über das man stolpert, dagegen schlägt oder sich darin verheddert immer wieder aus der sonst recht immersiven Erfahrung heraus gerissen wird. Hier möchte ich die alte Vive in den praktischen Vergleich mit der Valve Index bringen.

Die alte Vive und ihre Tücken

Die Vive steht oft in Foren oder auf Reddit wegen der relativ schlechten Bildschärfe – vor allem im Randbereich – also dem relativ kleinen, sogenannten “Sweet Spot” in der Kritik der Spieler. Auch mich hat das gestört, der Grund dafür: Als Streamer will man seinen Chat natürlich im Game verfolgen, glücklicherweise gibt es dafür im VR-Space bei Nutzung von SteamVR schon eine gute Lösung. Beat Saber hat sogar eine eigene Mod dafür. Ärgerlich ist es hingegen, dass man sehr direkt und unnatürlich durch Kopfbewegung auf den Text starren muss (statt einfach kurz nach oben zu schielen). Mal eben im Spielfluss eine Zeile des Chats lesen, ist somit so gut wie unmöglich.

Das, sowie einige Tracking-Probleme und natürlich die Neugierde haben mich dazu bewegt, mir eine Valve Index zu bestellen. Wohl wissend, dass es – zumindest derzeit – keine Möglichkeit gibt, das Kabel dieser Brille los zu werden.

Der Erste Eindruck der Index

Als die Brille kam war der Hype natürlich groß. Gerade frisch aus der Packung genommen und schnell angeschlossen habe ich das neue HMD direkt einmal im Steam VR Home ausprobiert: Genial. Das Bild ist um ein vielfaches klarer und schärfer. Die Brille liegt sehr angenehm am Kopf an und alles funktioniert – obwohl ich noch die Base Stations der Vive verwende (die offiziell kompatibel sind). Das Tracking ist flüssiger und das optische Erlebnis deutlich realistischer als bei der Vive. Definitiv ein großer Pluspunkt! Auch die durch die Fresnel-Linsen verursachten Godrays, von denen man an vielen Stellen im Netz liest, konnte ich im Gegensatz zur Vive nicht ausmachen.
(Es gibt übrigens einen Lens-Hack, der die Schärfe und die Godrays der Vive fixen soll.)

Also direkt ab zum ersten Song in Beat Saber… Die Knuckles Controller liegen sehr schön in der Hand, aber mit dem Laserschwert die Blöcke zu treffen gestaltet sich schwierig, denn das Licht schießt in einem anderen Winkel aus der Hand als bei den Vive Controllern. Ich hoffe, ich finde dafür eine Lösung, denn so verrenkt man sich doch recht stark. Na ja, who cares? Die Welt sieht auf einmal so klar aus, es ist als wache man aus einem Dämmerschlaf auf… Der Hype hält an, ich teste Weiter.

Die Realität: Ein anhaltendes Problem

Leider wird das immersive Erlebnis direkt wieder gestört. Als ich bei einem Song Noten über Kopfhöhe zerschlagen muss, verheddere ich mich mit dem Controller im an der Decke mittels spezieller Federschlaufen (nennt man die so?) verlegten Kabel. Ein Risiko, das ich bereit war einzugehen. Und es hat sich bestätigt, denn nicht nur das verheddern ist ein Problem. Ich merke den Zug des Kabels. Während des Spielens bewege ich mich instinktiv ganz langsam immer mehr in Richtung des Fixierpunktes des Kabels, so als ziehe mich jemand vom Schauplatz des Games weg.

Der versierte Kabel-VR-Gamer denkt sich jetzt wahrscheinlich warum ich mich so über ein simples Kabel so sehr aufrege, aber wenn man von Wireless kommt, ist das ein harter Rückschritt. Oder habt ihr etwa noch nie mit eurem Smartphone telefonieren müssen, als es am Ladekabel hing?

Themenwechsel: Fakten.

Kommen wir zurück zu den technischen Fakten: Im Audiobereich verspricht Valve ein realistisches Audioerlebnis. Ich kann das sehr gut nachvollziehen, den die Lautsprecher hängen ein paar Millimeter von den Ohren abgehoben in der Luft. Der Sound ist klar, und scheint tatsächlich aus der Umgebung zu kommen. Einzig im Bassbereich hat diese Technik ihre Nachteile. Der Bass bei Beat Saber klingt etwas dosig. Es fehlt einfach der Druck, den der Deluxe Audio Strap der Vive durch seinen direkten Ohrkontakt besser aufbauen kann.


Die Mitgelieferten Knuckles-Controller (offiziell Valve Index Controller) liegen optimal in der Hand, halten durch ihren Befestigungsriemen sehr gut an den Händen. Mit offener Handfläche schütteln sollte man sie ohne Sicherung jedoch trotzdem nicht. Die Controller fühlen sich sehr wertig an, das Highlight ist natürlich das vollständige Finger tracking. Ich bin gespannt, was die Entwickler daraus machen…

Mein Fazit:

Wer hatte eigentlich die Idee Kabel an VR-Brillen zu bauen? Es stört, nein nervt sogar. Mit einem gut ausgeklügelten Montage-System kann man das aber so weit minimieren, dass die technischen Vorteile der Index (mehr Subpixel, höhere Auflösung, schnellere Wiederholraten, größerer FOV, großer Sweet Spot, angenehmeres Kopfgefühl, stabileres Tracking) einfach überwiegen.
Ich werde bei der Valve Index bleiben und hoffe, dass es bald die nötige Technik für ein Wireless-System gibt und dieses dann bezahlbar auf den Markt kommt.
Was mich allerdings auch nervt, und mich momentan auch etwas hin und her reißt, vielleicht doch die Vive Pro mal zu testen ist, dass ich in einer dunklen VR-Umgebung Licht am inneren der Brille sehen kann, wenn ich auf etwas helles schaue (wie bspw das Beat Saber Logo beim Ladebildschirm).

Und was denkt ihr?

Habt ihr die Index schon getestet? Was sind eure Erfahrungen? Welche VR-Hardware bevorzugt ihr und was denkt ihr über HMD-Kabel?

Ihr wollt mehr über die Brille wissen? Dieser Beitrag ist kein Review, sondern lediglich ein Erfahrungsbericht. Vielleicht lasse ich mich ja aber noch dazu hinreißen, ein komplettes Review zu verfassen…

Weiteres Fazit nach einem Jahr:

Nach circa einem Jahr habe ich die Index nun zugunsten einer Vive Cosmos verkauft. Der Schritt hatte zwei Gründe: Sie ist Kabellos (mit Wireless Kit) und eine ganze Ecke günstiger. Ich spiele inzwischen seltener VR und für meine Anforderungen reicht eine Cosmos derzeit aus. Die Qualität ist weiterhin sehr gut, wenn auch nicht ganz so klar wie bei der Index. Die Index ist meiner Meinung nach einfach nach wie vor die technisch beste VR-Brille am Consumer-Markt, auch wenn gerade im VR-Segment in den nächsten Jahren sicherlich noch einiges auf uns zu kommt. Sie hat eben aber ihren Preis, und der ist – auch heute noch – stolz.

Bildquelle: Offizielle Valve Website

Blogbeitrag größtenteils übernommen von Cybernaut (Hier schrieb ich früher ab und an)