rls2k5

The ports should be untagged for data and tagged for voice. On the switch the voice vlan should be marked as the voice vlan. (ArubaOS example below) vlan 100 name "DATA" untagged 1-20 vlan 200 name "VOICE" tagged 1-20 voice The handset should not need the vlan IDs set.

I could only get it to work by importing the key from the 2019 server, but RSAT was sufficient, I didn't need to install the volume activation role on it. This was back in November before any updates could of fixed the issue.

I agree that it would be better / easier to do this through the BIOS configuration. You can do this in bulk using Dell command by generating a silent EXE to run, which is what we do to set BIOS passwords. I believe it also intergrates with SCCM if you have that. Make sure you use an older version if the PCs are more than a couple of years old. You can usually find a version that works by using one of the PCs service tags on their support website. You could possibly run the created EXE using a startup script with a WMI filter in GPO?

I found the same thing, though I re added the keys with optional names so i could decipher what was what in the future. As you say activation is successful, you must of worked out that in order for windows to activate you must import the keys on the 2019 server, either by it having the volume activation role, or by installing the volume activation RSAT tools. Fortunately Office 2019 was a lot simpler.

Hi, I've been following Edugeek for years, but this is my first post. We are using Windows 10 LTSB enterprise 1607 for the bulk of our PCs and are greeted with a blue screen at login on recently deployed computers. We have recently updated our deployment image (just the standard image with updates embedded in the WIM file from WSUS to speed up deployment for MDT). The PCs this image has been deployed on show the blue login screen, the PCs with the old image (all the same updates from the same WSUS server applied over time) show the correct logon background. We also have a couple of office PCs on enterprise 1803 with all updates from WSUS in the WIM file and these also show the login background correctly. The new image PCs show the correct location for the logon background in rsop and the registry but for some reason it doesn't apply. We have tried things posted elsewhere on here such as taking ownership of folders to change permissions and we have tried copying the windows.login.ui.pri file from a pc with the old image to no avail. We don't think the issue relates to group policy as it successfully applies on all other images but have tried both UNC and local paths for the image. Does anyone know a fix for this issue? The school colours aren't blue (and don't want to open the logon colour can of worms as that appears even worse than the logon background) Any hints would be greatly appreciated.