0

I recently installed Powershell 7.3.5, being "forced" to move away from 5.1 for PnP / SharepointPnP

As an admin, while running it as an admin, regardless of the scope returns :

Install-Package: Administrator rights are required to install or update. Log on to the computer with an account that has Administrator rights, and then try again, or install by adding "-Scope CurrentUser" to your command. You can also try running the Windows PowerShell session with elevated rights (Run as Administrator).

There is a reason why it could not write in user Documents folder,

I ended up manually putting the module in P7's install module folder, but this is weird.

PS C:\Windows\System32> Save-Module -Name ExchangeOnlineManagement -Path C:\Temp -Repository PSGallery
PS C:\Windows\System32> Import-Module ExchangeOnlineManagement
PS C:\Windows\System32> Connect-ExchangeOnline

So it works, but I have no idea why he can't access it, at the very list a /alluser install should work.

Not saying I want to say goodbye to the ISE, but it seems to be the way forward in most ways.

Narzard
  • 3,557
  • 14
  • 27
paypercorn
  • 1
  • Try and `Install-Module -Scope CurrentUser ExchangeOnlineManagement` and see if you get a better error? It could be some part of your `$env:PSModulePath` https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_modules?view=powershell-7.3#module-and-dsc-resource-locations-and-psmodulepath is wrong, missing, in-use, or some other state where PS can't write to it. Check whether it partially installed the module or something weird in your module folders before failing? – Cpt.Whale Jul 06 '23 at 15:55
  • Well, the current user install path is broke at the moment, on purpose and will stay that way. (User\Docs\Powershell\Modules) But the others are not. C:\Program Files\PowerShell\Modules; c:\program files\powershell\7\Modules; C:\Program Files\WindowsPowerShell\Modules; C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules; C:\Program Files\SharePoint Online Management Shell\ – paypercorn Jul 06 '23 at 16:41
  • What kind of broken? There are some common issues with installing modules when your Documents are synced with OneDrive or or use controlled folder access to block powershell (https://github.com/PowerShell/PowerShellGetv2/issues/586). Some modules usually try and check for existing versions in the user path and choke out. There are more troubleshooting steps in the linked issue to test out though – Cpt.Whale Jul 06 '23 at 17:49
  • One thing you can try is saving modules to a folder, then manually adding that folder to your `$env:PSModulePath`. This won't change the behavior of `Install-Package`, but it will let you skip using `Import-Module` in every session – Cpt.Whale Jul 06 '23 at 17:51
  • Well, I "fixed" the rights to the network share to test it out, now it installs as current user directly on the network share where user files are redirected. Now it does install as current user and the "run as admin" warning is gone. Running a module install with allusers scope just does nothing at all. No error, no install of the modules in any of the paths except Current user path... – paypercorn Jul 07 '23 at 13:11
  • Try temporarily enabling verbose/debug output with `$VerbosePreference='Continue'` and/or `$DebugPreference='Continue'`, then try installing it for AllUsers again and check whether it complains about something or uses a wrong path? If there is some module conflict, you might have to use `-Force` or `-AllowClobber`, but it should normally prompt you – Cpt.Whale Jul 07 '23 at 14:20
  • You are saying the user running it before elevating powershell 7 is a local administrator on the Windows machine and has logged off and back on since being a local admin, right? Seems to work when I just run `Install-Module ExchangeOnlineManagement` but still have to select `Y` per the powershell default security to trust no repositories even though MS maintains the psgallery repo. I guess you can run `Set-PSRepository -Name PSGallery -InstallationPolicy Trusted` to trust the ones you confirm are safe though with that command. In any event, no run as admin needed for my local admin, and worked – Vomit IT - Chunky Mess Style Jul 07 '23 at 18:43
  • I'll try those on work PC this week, but yes, elevated console on an account that has been a local admin account. – paypercorn Jul 10 '23 at 21:28
  • It seems to be working just fine now, the only thing I did was restore access to network share. It really didn't like not having access to user documents, now it's installing in C:\Program Files\PowerShell\Modules – paypercorn Jul 11 '23 at 14:31

0 Answers0