No idea at that point, I rebooted in 2022, I'm typing from it right now, your vbs works, ALT+F4 works, OpenShell's option works as well. Try to create a new testuser, and see what happens there, just to understand if the problem is systemwide or affects only your current user.
Tried this method to convert Windows Server 2022 to workstation. It generally works, but I encountered a problem with ctfmon.exe - it started to constantly crashing (see event log for error messages). The problem is exactly switching to client SKU since after switching back crashing stopped. My investigation showed that the reason is several registry keys, which are missing in server builds, but required for ctfmon.exe to work on client SKUs. The keys are: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MTFFuzzyFactors HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MTFInputType HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MTFKeyboardMappings HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Input\DataSources HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Input\HwkSettings HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Input\QuickAccent HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Input\State HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Input\Settings After copying the keys from a Windows 10 installation crashing stopped. All these keys are part of the Microsoft-Windows-InputProcessors-Settings assembly, which contains in the client package and is not present in the server installation. UPD: Added one missing registry key.
Thanks for sharing your findings. Indeed it was known problem in Server 2022, but not the older version. Personally I didn't investigate a lot given I use SKUwitch just temporary, but if you mind for wnatever reason to keep 2022 in Client mode, your finding is pretty useful.
I experienced the same thing with ctfmon when switched away from server. For both skus, I still have a keyboard problem where I can't use legacy console mode. Some chars on my keyboard are displayed incorrectly there. I also keep getting spammed with "Something happened, and we couldn't install a feature [Fix]". Zero info on what the OS wants to install. I will look into the keys added and see if they resolve anything. Edit: the additional reg entries did not fix any of my additional problems. Since the .1 release was preview quality, I updated to the latest LCU and that resolved the legacy console keyboard and spamming issues for me.
I just ran into another problem with my server 2022 installation. When connected via my Ethernet adapter, I cant access any of my network shares on my NAS. I get System error 53 has occurred. The network path was not found. When connected via the Wireless adapter I can access the shares. On my other systems both adapters work. What's different on server as compared to W10/W11 that would cause the Ethernet adapter to have this issue?
Try Set-SmbClientConfiguration -EnableMultiChannel $false and Set-SmbServerConfiguration -EnableMultiChannel $false Then restart the [lanman]server and [lanman]workstation services (or reboot the machine).
Unfortunately your suggestion did not resolve this problem. As an aside, before switching to $false, I compared the client config with the one from Windows 10 and the settings were the same with the exception of extra entries on the client side of server 2022.
So probably is some slight variation in the smb dialect of 2022, I mean because it's newer than w10, not because it's a server, did you try if enabling the smb1 feature from the server manager solves the problem?
I just noticed that LTSC 2021, Win11 EDUC show the same issue. LTSC 1809/1607 are working . Will check if smb1 is enabled on those.
Both 1607/1809 show true. I tried to enable smb1 on LTSC 2021 and got Code: PS C:\> Set-SmbServerConfiguration -EnableSMB1Protocol $true Confirm Are you sure you want to perform this action? Performing operation 'Modify' on Target 'SMB Server Configuration'. [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Set-SmbServerConfiguration : The specified service does not exist. At line:1 char:1 + Set-SmbServerConfiguration -EnableSMB1Protocol $true + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (MSFT_SmbServerConfiguration:ROOT/ Microsoft/...erConfiguration) [Set-SmbServerConfiguration], CimException + FullyQualifiedErrorId : Windows System Error 1243,Set-SmbServerConfigura tion Something may have changed recently with the FEB LCUs, because I never noticed this problem before on any of the systems. Enabling smb1 via features did not help.
What about? dism /online /enable-feature:smb1protocol And what about dism /online /get-features ? Is something related to smb1 listed? Maybe they removed it with a CU and no one (including me) noticed
I did enable it via features, but that did not have any effect. I will try a restore back to the Jan and see if ok, Code: Feature Name : SMB1Protocol State : Enabled Feature Name : SMB1Protocol-Client State : Enabled Feature Name : SMB1Protocol-Server State : Enabled Feature Name : SMB1Protocol-Deprecation State : Enabled
Being unable to access share names is somewhat of a global problem on my side after checking the rest of my systems. I just noticed it first on Server 2022. I don't think enabling SMB1 is necessary since shares worked without it before. Every OS I have after LTSC 1809 no longer recognizes the share names, so no connection can be made. This applies when on Ethernet or Wifi. I am clueless as to why the QNAP NAS is no longer showing in the network as you can see in the images. That is what is causing the shares to fail. I checked the firewall, and File and Printer Sharing is allowed for the private network. Network discovery is also on. I managed to "fix" this by adding the ip address and name of the NAS to my hosts file, but that doesn't solve the underlying issue that has recently popped up. If anyone has some ideas why the QNAP network object is missing in the network GUI on my newer systems , please let me know.
It depends on the SMB dialect spoken, by the members of the LAN. Since the dawn of time the PC shown in the network is (was) managed by the browser service (which is installed only if you have the SMB1, but even in that case can be disabled/not running for whatever reason) On more recent windows (after 1803 I think), the matter is managed by the Function Discovery Resource Publication (FDResPub) Service But #1 it's disabled by default #2 Must be running in the PC that needs to be discovered, not the PC that need to see the LAN members. So, in your case it's the NAS that must emulate that service to be visible in a SMB2/3 only LAN, so if your NAS isn't the lastest novelty it's unlikely that samba has this feature. That's in short why the SMB1 feature, usually fixes all the LAN troubles, when some of the LAN members are older Windows, or Linux machines.
This is what is currently set in the NAS for discovery. SMB3 is the highest setting. Starting FDResPub fixes the problem on Server 2022. Will check the other systems.