I have a situation that revolves around security for a added Hard Disk which is defined as an entire HDD partition (Disk 1, Partition 2).
Thanks to another kind and knowledgeable member, I was helped in how to create a persistent drive using an entire partition. That issue is solved.
Further testing though reveals that:
I have checked the security on the hidden drive (before any attempts to define, add and implement the drive in VMWare 12.5) and where it appeared to be inadequate, the security was updated to include, all with appropriate authority (other than FULL)::
All needed authorities appear to be in place.
Is there a way to solve the access issue on a drive as a physical partition?
The end-state is to use the drive from a VMWare Workstation 12.5 host launch when using a Standard User profile and w/o launch using "Run as administrator". This has been easily implemented and executes w/o issue for other defined clients that do not have a partition defined as a Hard Drive.
As support, my rig is as follows:
Any guidance is greatly appreciated!
Jim
You can try this: User-Mode Raw Disk Access
... but be aware, the problem you have encountered is a restriction that is by design from Microsoft, as documented here: https://support.microsoft.com/en-us/help/942448/changes-to-the-file-system-and-to-the-storage-stack-...
As a side note, if it were me in this position, I would move on to the next project. The hoops required to get this to work crosses a line with me. It adds a layer of complexity which increases the risk of issues, that could in turn damage your reputation more than if you had just moved on to the next project now.
Can you offer more infomration? The VM relative logs, vmx settings, the Host and Guest OS and disk type. And you metioned you are helped in how to create a persistent drive using an entire partition, can you give more operation details?
Access is limited to a very specific set of criteria, specifically the launch of the VMWare Workstation Pro 12.5 host must be done as "Run as administrator".
This is a very common situation where a local admin account or a (Windows) domain account in local Administrators group doesn't seem to be able to achieve the same result in not specifying "Run as Administrator" as in specifying "Run as Administrator", which is mostly due to GPOs if the host is on a domain and controlled/managed by GPOs. In another word, it's not an issue specific to VMware, rather general to all executables. Some may give the same results regardless of this "selection" because of, again, GPOs may not put any restrictions on specific "objects".
For host and client, the original thread provided my current rig/configuration parameters. For convenience, please see:
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.
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
As I implied in my previous comment, this (topic/discussion) is not specific to VMware - rather, beyond VMware.
However, a couple of (additional) comments:
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.
If this means that the logged-in user account to run Workstation will not be put into local Administrators group, either individually/directly or "indirectly" via its domain group (membership), then I'm afraid that Workstation may not work properly.
However, I'm not an expert in this, so I hope someone or VMware documentation would confirm if running Workstation requires local admin rights. I'd not be surprised if the answer is yes because Workstation does and needs "a lot".
Then, your client may be looking for a virtualization production/application with a "client-server" architecture, in which logged-in users don't have to be local Admins and will be running VMs on the client-side of the application while VMs are "hosted" on the server-side. Workstation is only a stand-alone application, to my impression.
Hi,
AFAIK this is a windows limitation.
The direct access that you want to have to the physical disk requires administrator access.
While you might -somehow- be able to get past that by disabling some of the Windows security layers, that isn't exactly recommended and sounds like it is counteractive against what you are trying to do, have a more secure environment.
The only route I am personally unsure about that might work is to use the VM as a shared VM, but I have no idea if a shared VM can be setup to have direct disk access.
A shared VM does not run under the normal local user account like a normal VM does, so with some luck that would work.
--
Wil
You can try this: User-Mode Raw Disk Access
... but be aware, the problem you have encountered is a restriction that is by design from Microsoft, as documented here: https://support.microsoft.com/en-us/help/942448/changes-to-the-file-system-and-to-the-storage-stack-...
As a side note, if it were me in this position, I would move on to the next project. The hoops required to get this to work crosses a line with me. It adds a layer of complexity which increases the risk of issues, that could in turn damage your reputation more than if you had just moved on to the next project now.
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