JML54's Posts

Thank you for your post. Based on your response, upgrading to v16.x is viable. My main question relates to the Windows 10 install of VMWare Workstation Pro. In prior installs, it required modification of registry settings, core isolation settings and other requirements. Some have created a PowerShell script to execute to handle 99% of the required modifications. With the relase of VMWare v16.x Workstation Pro have the plug-n-play approach for Workstation Pro been improved to support Windows 11 (current version) platform and not require modification of the settings needed for past Workstation Pro versions? Thank you for your guidance and time! It is much appreciated!

Thank you for the guidance. Specifically, yes a 3rd Party uninstaller was used. No other option (at launch of the update .EXE). Only a message to update the installation, and nothing specific to uninstall the previous installation. Though at the end of the uninstall process, all VMWare content (Reg, Folder, Start Link, Desktop Link) had been removed. A reinstall of 15.5.2 went w/o issue and works w/o issue (including Lic registration/activation.) The initial event that raised the risk of something out of alignment was the repeated error "Connection to Server Lost" message. This did not appear to be a normal event for my on-line connection, and it repeated despite the fact that all other on-line connections continued w/out issue, both streaming and file downloads along with my VPN tunnel to my work network location (on another device, not my home system.) So, not sure what was going on with the auto-update, so the reported issue above took up after downloading the product from VMWare site (post-sign on of course.) Jim

I have the same issue. It appears to be related to current Windows 10 Pro. The host is: Windows 10 Pro v1909 (OS Build 18363.836) - Installed 11/13/2019 Most recent/Last Update: 5/15/2020 KB4556799; plus multiple updates from ‎12/‎11/‎2019. The initial issue identified as: "Service "VMWare Authorization Service" (VMAuthdService) could not be installed. Verify that you have sufficient privileges to install system services." When failed: Attempted to back out changes. FAILED. Attempted to correct/confirm privileges, SUCCESS. Attempted to reinstall: FAILED (same error). Attempted to use "Ignore Option" - APPARENT SUCCESS. Attempted to use VMWARE Workstation 15 Player: FAILED (indicated license required; attempted to provide VMWare Workstation Pro 15 base license; Reported as License invalid.) Attempted to verify used licenses = to Registered License: Success Attempted to Launch base VMWare Workstation Pro 15: Success Attempted to power on VM Client (encrypted): FAILED (Clone of Master Image; Indicated encryption key invalid.) Attempted to power on VM Client (not-encrypted): FAILED (Original OS Install; failed with message: Unable to open /VMWare Authorization Service" at time of attempt.) Attempted to use Settings to uninstall VMWare - Not listed. Attempted to locate Uninstall option w/in Start Program List, no option available. Resorted to Revo Uninstaller - Not listed. Used logs to identify VMWare installation content, removed using Revo Uninstaller.) Rinstalled VMWare Workstation Pro 15 v15.5.2 using base license: SUCCESS Testing using existing Master and Clone Clients, SUCCESS. System is Home System, not connected to AD or otherwise used in a Business Environment (All Admin Privileges applied.) Additionally, one iteration of the cycle depicted above attempted to use built-in Admin profile, with same results as original attempt; and still failed to back out changes. ADDITIONAL NOTES: It is unclear what the issue is, research indicated signed objects during install w/in current OS requires SHA-2(?) installation object shigning, and therefore triggers the VMAuthdService install failure at 15.5.5 installation. Automated download and install of updated version, on multiple attempts resulted in "Loss of connection with server" during update download phase. Attempted to use Download file version and that version resulted in the above failures. v15.5.5 appears to be corrupt and/or out of alignment with current Windows 10 Pro x64 versions (all pushed updates installed.) This version appears to align more closely with Live Credential Guard on the current Windows 10 Pro x64 version based on VMWare information FAQ. However, it does not appear to be appropriately aligned to this version, and able to support an installation with or without Credential Guard active. I've turned off Credential Guard 1.5mo ago in the hopes that v15.5.2 would work (last update I have prior to 15.5.5.) It did work and proceeded as usual. I hope this is sufficient information provide clues to the issue and that a solution shall be found soon. Jim

Based on the findings provided it is precisely what was being sought. I know that the Threadripper is new enough technology that it shall take a bit of time for the support to permeate the software technology needed to take advantage of the capability. As to support within the AMD CPU, yes, SEV-ES is fully supported from BIOS > Hardware. It now remains for those technologies to be put to use by the products that have a need. I also know that EPYC, as the first Business level platform to be published, also supports the capability and may very well have setup the design model for the Threadripper in that regard. With today's world ever changing though, the enhanced security is needed and I suspect that the designers for VMWare are hard at work figuring out how best to implement the improvements. Given the footprint of the product though, it is unlikely to be implemented this year (or at the consumer level anyway.) For me, I have a number of clients that are exploring the deployment of a work-at-home model, and have been reluctant to do so given the nature of their business and the level of confidentiality that needs to be applied. I didn't even know of the capability until a client engineer came to me and it was raised in discussion about support options (should have known though... ) Thank you for the help and guidance. As always, I knew there would be a level of response from someone far more knowledgeable than I.

The AMD white paper may be found at: PROTECTING VM REGISTER STATE WITH SEV-ES​ Correction: SEV-ES = Secure Encrypted Virtualization (Encrypted State) Below is an updated Introduction to the White Paper published by AMD:      Recently, AMD introduced the Secure Encrypted Virtualization (SEV) technology [1] that integrates memory encryption with AMD-V virtualization to provide support for encrypted virtual machines (VMs).  Encrypted virtual machines are ideal for multi-tenant environments such as cloud computing as they enable protection from a variety of cross-VM and hypervisor-based attacks.  For instance, a hypervisor bug which enables a co-resident VM to escape its sandbox and read arbitrary memory on the system cannot be used to steal data or compromise an SEV-enabled VM.      While no security system is 100% secure, SEV significantly reduces the attack surface of VMs in the cloud by encrypting a VM’s memory with a key unique to that VM and unknown to the hypervisor.  Many secrets and important information are typically stored in a VM’s memory space and encrypting this content helps prevent attacks and leakage of sensitive data.      However, when secrets are being actively used by the VM they are often resident in CPU registers as well as memory.  Whenever a VM stops running, due to an interrupt or other event, its register contents are saved to hypervisor memory and this memory is readable by the hypervisor even if SEV is enabled.  This information could allow a malicious or compromised hypervisor to steal information or alter critical values in guest state such as an instruction pointer, encryption key, etc.      The new SEV with Encrypted State (SEV-ES) feature blocks attacks like these by encrypting and protecting all CPU register contents when a VM stops running.  This prevents the leakage of information in CPU registers to components like the hypervisor, and can even detect and prevent malicious modifications to CPU register state.  SEV-ES builds upon SEV to provide an even smaller attack surface and additional protection for a guest VM from the hypervisor.      This document presents a technical overview of the SEV-ES feature, the principles behind the architecture, and protections offered to further isolate encrypted VMs.  For additional technical details, please see the AMD64 Programmer’s Manual [2].

Sadly, it is BIOS. This then pushes towards the PLOP approach, though I've only barely skimmed the surface of this option and know nothing about it. Anyone with advise/guidance that may be able to assist, I'm all ears. (Your statement though has made me take a different approach to the build out of VM Clients - use EFI approach not BIOS. Thank you!) Jim

Okay, I'm convinced. The design paper was right on point, and shall be included in my report summary to the SLT. The use of the User-Mode Raw Disk Access approach is not a viable solution, nor would I recommend it. The scope of the need does not include bypassing the design to ensure integrity of the system/drives. This piece of information shall not be provided to the engineers (though many may be aware already) and certainly not to the SLT. Based on the results, my paper to the SLT shall reflect the constraints and the potential options, none of which shall operate below the design of the base OS and certainly none that shall include potential work-around to that design (virtual drives are not an option either, as the approach may introduce other factors that would interfere with the work of the engineers.) Your response, though not the expected answer, is in fact the answer to my inquiry. I thank you for your insight, knowledge sharing and guidance. Your response is appreciated! Jim

Thank you for the update. The environment where this is being tested is on an isolated rig, configured as close as possible to the final deployed device. This is for configuration, security and other reasons as required by the SLT (Sr. Leadership Team). - After all, mine is not to reason why... I'm a trusted independent contractor, and therefore, use my own device for this work so the companies I work with may request a whole lot of variety in what they ask of me. With maximum configuration of my rig, it can be configured - using VMWare of course - to any required environment as dictated by my clients. And, w/o worry of corrupting my own system... So, after my work is done, the remaining effort is a lot of typing and detail to hand over to my client's internal engineers. Once the POC (proof of concept) is done, they've saved money, I've made money, and all are happy. This time, I may have put my foot in my mouth, and bitten off more than I can chew... Based on your response, the issue is such that it may result in a negative report to the client's management, and conversely the cost of this effort shall increase if they choose to either drop this approach being attempted or to continue. Either one would be an impact to the cost. Me, I won't make as much as I could have; though I'll just move on to another project (with lessons learned.) The bottom line is that, the final environment where this shall be configured and used, cannot provide the Administrator Password to those where it is deployed. Jim

For host and client, the original thread provided my current rig/configuration parameters. For convenience, please see: Host: Windows 10 v1703 (build 15063.413) Client: Wincows 10 v1607 Disk drive type: HDD For setup help and guidance, I received a response to my earlier thread, titled "Insufficient permission to access file. (Windows 10)". Operationally, my system is a isolated test bed (see rig configuration in original post) for my clients as we work out the kinks to configuration and final implementation on proprietary company systems. This is a new approach for the company, not yet attempted, and was brought about by SLT discussions to permit confidential and proprietary work by engineers in a distributed environment.

Don't know if you received my email - - - I do want to thank you for your recommendation and support! Sadly, though, VMWare Workstation Pro only permits access to the HDD (defined from the partition) to be accessed when VMWare is launched "Run as Administrator". I've checked the authorities on the drive, in both VMWare and in Disk Management. The security settings appear to be good, in particular for both Group authorities, and explicitly define for user profile authorities. The authorities were setup prior to the creation of the HDD for VMWare, assigned to a full disk partition. In this case, as long as I access the partition (Disk 1, Partition 2) under a "Run as administrator" launch, everything works great, up to and including the encryption using BitLocker. Unfortunately, the client launch in a VMWare host session, NOT launched as "Run as administrator" fails every time with the message as shown in the subject line here. Since the root-cause for this thread was answered, I'll be launching a new thread, and maybe another kind member shall provide the time and guidance necessary to overcome this next step in the evolution of this effort. Thank you again! Jim

On a more serious note... I want to thank you for your time, guidance and help! It was just the prompt I needed, and the work was completed and with the expected results (it works). Further testing is now needed as I shall determine if the drive is accessible by my standard profile, when starting VMWare under normal log-in. Thanks again. Jim

Okay - my bad... Yes, I'd used my Administrator profile while doing the work. No, I did not run VMWare "As Administrator"... Took a bit for it to dawn on me what was being asked. Conclusion: Multi-tasking doesn't work well for me as it used to...

Yes. "Add Disk" built using Admin profile. Launch of Client using Admin profile. End-state shall be Client run as standard user, though testing has not moved that far yet. End-state intended to protect Host from current virus/malware/ransomware now proliferating around the world. Client's not intended to operate with confidential information, and may be created should infection occur. Storage space needed though for MS Office Pro suite of applications, and working for client. Jim