Tell us about your request
Many of our users do not have system permissions so handling installs requires assistance from our service team. Then the updates and other activities may trip them up at some point.
https://docs.docker.com/desktop/windows/permission-requirements/#privileged-helper
Can privileged-helper be decoupled from the primary docker desktop installer? Not sure how often it needs to update compared to the primary part of the app. And we know we would need to make sure VMP and WSL were in place as Requirements as the user scoped installer wouldn't be able to handle it.
And given the move to WSL2 it's possible a number of the operations are unnecessary. So if a non-admin is detected installing the product different decisions could be made which also may allow for migration to MSIX model. Install location in %LOCALAPPDATA%, User accessible named pipe vs only docker-users, etc. Now I don't think even w WSL2 it can be eliminated given the updates to the hosts file and some of the "policy" JSONs, but if those operations are infrequent than the update for this feature reduce the need to update that part.
I would use an MSI/install flag to suppress the install of the admin parts for us who need this type of fine grain control vs only making installers. This would also allow for services like winget to assist in the update lifecycle of the primary parts of the app as well using /scope=user.
Which service(s) is this request for?
Docker Desktop Windows
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Just a less ideal user experience. Chasing versions for packaged products etc. and driving more call volume than is necessary.
Are you currently working around the issue?
Package up the installer (install as SYSTEM), but then handle docker-users through custom scripts ran after install. And self service tools are User or SYSTEM and not User w/ UAC so these installs are more fragile than I would prefer.
Tell us about your request
Many of our users do not have system permissions so handling installs requires assistance from our service team. Then the updates and other activities may trip them up at some point.
https://docs.docker.com/desktop/windows/permission-requirements/#privileged-helper
Can privileged-helper be decoupled from the primary docker desktop installer? Not sure how often it needs to update compared to the primary part of the app. And we know we would need to make sure VMP and WSL were in place as Requirements as the user scoped installer wouldn't be able to handle it.
And given the move to WSL2 it's possible a number of the operations are unnecessary. So if a non-admin is detected installing the product different decisions could be made which also may allow for migration to MSIX model. Install location in %LOCALAPPDATA%, User accessible named pipe vs only docker-users, etc. Now I don't think even w WSL2 it can be eliminated given the updates to the hosts file and some of the "policy" JSONs, but if those operations are infrequent than the update for this feature reduce the need to update that part.
I would use an MSI/install flag to suppress the install of the admin parts for us who need this type of fine grain control vs only making installers. This would also allow for services like winget to assist in the update lifecycle of the primary parts of the app as well using /scope=user.
Which service(s) is this request for?
Docker Desktop Windows
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
Just a less ideal user experience. Chasing versions for packaged products etc. and driving more call volume than is necessary.
Are you currently working around the issue?
Package up the installer (install as SYSTEM), but then handle docker-users through custom scripts ran after install. And self service tools are User or SYSTEM and not User w/ UAC so these installs are more fragile than I would prefer.