manniongeo's Posts

Workaround As a test, I created a new Windows 11 guest on my VMware Workstation host with the unsupported TPM (1.2) and was subsequently able to move it to and start it on a second VMware Workstatio... See more...
Workaround As a test, I created a new Windows 11 guest on my VMware Workstation host with the unsupported TPM (1.2) and was subsequently able to move it to and start it on a second VMware Workstation host, without being prompted for an encryption password. In this case, I again followed the installation instructions in support article 86207 for steps 1 and 2. But, I skipped step 3 and instead used the workflow described in the "In case you do not want to Encrypt the Virtual Machine" section to create the BypassTPMCheck registry value. I am going to rebuild the VM I created yesterday using this workaround. It'll take some time, but it's worth it to me at this early stage, to have the flexibility to move it once it's laden with more customizations.   Considerations I get the gist of the Windows 11 TPM requirements and the basics of the blog that @RDPetruska referenced above. But, I'm no expert in TPM/Windows/VMware, so take the following with caution. This workaround allows me to run Windows 11 on an unsupported platform. Obviously, there's the potential for problems - including security vulnerabilities, given that I'm using an older TPM standard. These risks are acceptable in my test environment, but make your own judgement before doing the same.   I'm unclear as to whether the BypassTPMCheck method disregards the TPM requirement entirely, or falls back to allowing the older TPM 1.2 standard. I read that there's an official Microsoft workaround (AllowUpgradesWithUnsupportedTPMOrCPU registry value) that allows 1.2 (and, apparently, will fail if you have no TPM at all) but I'm not sure about the specific BypassTPMCheck behavior. This detail doesn't impact my current use case, so I'm just going to proceed as-is. Again, do your own research.
Would you mind posting a link to "wila's blog"? I see it now; thanks. Is there a better option where I can run a Windows 11 guest on a host that doesn't not support Windows 11, and still be able to... See more...
Would you mind posting a link to "wila's blog"? I see it now; thanks. Is there a better option where I can run a Windows 11 guest on a host that doesn't not support Windows 11, and still be able to move the guest Thanks!
Environment: Workstation: 16.2.3 Host: Windows 10 Pro 21H2 Guest: Windows 11 Pro for Workstations 21H2 My physical hardware has an older TPM that is not compatible with Windows 11. Therefore, I... See more...
Environment: Workstation: 16.2.3 Host: Windows 10 Pro 21H2 Guest: Windows 11 Pro for Workstations 21H2 My physical hardware has an older TPM that is not compatible with Windows 11. Therefore, I followed the instructions in VMware support article 86207 to use a virtual TPM for the Windows 11 guest. Specifically, I used option 3A, which describes adding the following line to the guest's .vmx file: managedVM.autoAddVTPM = "software" This worked, and I was able to install and configure Windows 11 normally. The problem now is that I am trying to move this VM to another host, but the new host is prompting me for a password to decrypt the VM - and I don't have that password. After some additional reading/testing, I've found that encryption happens automatically when using the workflow in the aforementioned support article. But, Workstation neither prompts me to create a password, nor tells me which password it picked on my behalf. So, I seem to be stuck running the guest on this one host, at least for the moment. Does anyone know the default password used with the autoAddVTPM feature, or how I can discover the password for an existing encrypted VM? Thanks in advance for your help.
  • i
I'm adding one more symptom that I haven't seen reported in this thread so far: My CTRL-G / CTRL-ALT key combinations don't work, either, whenever the CAPS LOCK issue occurs My host is Wi... See more...
I'm adding one more symptom that I haven't seen reported in this thread so far: My CTRL-G / CTRL-ALT key combinations don't work, either, whenever the CAPS LOCK issue occurs My host is Windows, guest is Linux, and Workstation version is 15.5.5. In my instance, either all of these keys work, or they all don't work. Because of that correlation, I suspect that they're related to the same root cause.
I'm writing with some additional information: I upgraded to 15.1 from my 15.0.4 instance, including re-installing the Enhanced Keyboard Driver, and did not encounter the problem. I have not te... See more...
I'm writing with some additional information: I upgraded to 15.1 from my 15.0.4 instance, including re-installing the Enhanced Keyboard Driver, and did not encounter the problem. I have not tested beyond installing the upgrade, itself. Therefore, I can't state with certainty whether 15.1 lacks the issue, or it just happened to work in my particular environment. Note that the VMware Support analyst who was helping me said that he was unable to reproduce the original issue on his end. So, there's probably something something specific to my environment, anyway. The takeaway: consider 15.1 as a potential solution if you happen to experience the aforementioned keyboard issue. Good luck.
I just encountered the same, or a similar, problem when upgrading from VMware Workstation 12.something to 15.0.4 on my Windows 7 laptop. During the installation/upgrade, I elected to install t... See more...
I just encountered the same, or a similar, problem when upgrading from VMware Workstation 12.something to 15.0.4 on my Windows 7 laptop. During the installation/upgrade, I elected to install the VMware Enhanced Keyboard Driver. After rebooting, I could not use any keyboard once Windows was booted. Specifically: I tested using the internal laptop keyboard, an external USB keyboard connected via a docking station, and a different external USB keyboard connected directly to the laptop All three of the keyboards worked before Windows booted (e.g. BIOS configuration screen, boot selection screen) None of the keyboards worked once the Windows login screen appeared Additionally, once the Windows login screen appeared: The internal laptop touchpad did not work An external USB mouse was able to move the mouse cursor Note that I have a group policy set to require pressing CTRL+ALT+DEL to login. To solve the problem, I did the following: Booted the affected Windows 7 host to the Windows login screen Installed RD Client Remote Desktop app on my Android phone (thanks to the developer!) Connected to affected Windows 7 host using RD Client Android app At this point, I was able to use a keyboard connected to the phone to control the Windows 7 host. (Note that I was using Samsung DeX station with my phone, and had an external keyboard/mouse, monitor, local ethernet connected. I'm sure this isn't required, but sure made it easier - thanks Samsung!). Next: Opened Control Panel > Programs > Programs and Features Clicked VMware Workstation to highlight it Clicked Change In the VMware Workstation Pro Setup app, used the Change option to uncheck Enhanced Keyboard Driver Rebooted Windows After rebooting, I was able to use my keyboards / touchpad normally again. Holy heart attack, Batman. I'm glad I was in my office with some extra hardware and my DeX station for testing. VMware, please fix this debilitating issue - and, ideally, provide more timely support for installation-related category 1 issues for new purchases.This doesn't engender confidence as I embark on my journey with this "upgraded" product.