Support non-Administrator execution of cmdlets?

[FH-Inway]

In issue #590 we noticed that some cmdlets cause an error if they are executed in a PowerShell session without administrator privileges.

Since resolving the error would mean introducing a breaking change, @Splaxi raised the following question:

Finally - Do we as a community gain anything while supporting non-Administrator / non-Elevated? All CHE gives us access to the Administrator. All PowerShell sessions started by that account, auto-elevates. Onebox is a different breed entirely. Here people needs to learn how to configure the PowerShell session to always elevate (which will prompt them) - but when that is first in place, things are easier for everyone and will behave the same way.

The cmdlets identified so far that cause an error in a non-Administrator PowerShell session are:

• Disable-D365MaintenanceMode
• Enable-D365MaintenanceMode
• New-D365Bacpac
• Import-D365Bacpac

[Splaxi]

More perspective from my point of view:

The entire D365FO platform / stack has evolved over the cause of time, and along that way - we "lost" the option of MS-HOSTED tier1 developer boxes.

The remaining options are all fully capable of supporting RunAsAdministrator (Elevated) - in fact, more or less all touch points that MS has in place on either CHE (Cloud Hosted Environments) or Oneboxes (Downloaded VHD) requires administrator privileges in some way. At least if we want to fully utilize the powershell module as it is in the current state.

Stopping services from PowerShell requires RunAsAdministrator - just to point at something essential. This might be of the implementation that we did back in the days - but as this is a community effort, we also need to ensure that we can produce value with little to no effort, otherwise we'll just loose interest in keeping things running.