upgrade to 7.4.5 / prerequisite software

Hi all,

I try to upgrade from 7.4.4 to 7.5.5 but failing on the prerequisite software installation.
Upgrade from 7.4.3 to 7.4.4, I did a /quiet install therefore I've skipped the prerequisite installation, but now I need the azure stuff in ARS, so I want to do it the right way.

As the server doesn't have any internet connectivity, I've downloaded the nupkg packages and unzipped them to the modules folder of PowerShell, that worked so far for MS Teams etc.
The only two remaining packages are: Exchange Online PowerShell V2 module and AZ (azure az) module, although I did the same as for all the others above, it stills shows as "please install prereq software" when starting the ARS install/upgrade.

I've used the following nupkg packages:

(took the v.2.0.5)
PowerShell Gallery | ExchangeOnlineManagement 2.0.6-Preview3

(took 6.6.0)
PowerShell Gallery | Az 6.6.0

PSVersion: 5.1.14393.4583  
Windows Server 2016 Datacenter

I've installed the package with this steps:
Manually install a module from the PowerShell Gallery – PowerSQL – Bringing PowerShell and SQL together for the best of both worlds. (randomnote1.github.io)


Thanks for your support,
Micha

  • Hi Micha,

    That was when it was first discovered and we have since recommended that the modules are installed as a safety precaution. KB 33457 was updated with the offline install method.

    You may be perfectly fine without them, but if you engage Support and we discover issues that appear to be Azure-related (i.e. missing modules), errors, then we may require the modules to be installed to move forward with the service request.

    Thank you,

    Daniel Bishop

    One Identity

  • Dan - can you publish a manifest of the contents of the default modules folder with the required modules installed with paths.

    I can only assume there is one or some - small some thing not matching the expected location from the installer that's being missed.

    We've followed the same guidance - and like Micha are in the same place, considering rolling back to prior version

    We have an open SR on this issue and just updated the case with the problematic complete module folders\files list as-installed.
    I used the following command to export the module manifest and uploaded our full modules folder inventory.

    get-childitem  "C:\Program Files\WindowsPowerShell\Modules" -Recurse | select fullname

    maybe a little compare your known-good to our known-not-good will yield a clue.

    Example out -

    C:\Program Files\WindowsPowerShell\Modules\Az.ServiceBus\1.8.1
    C:\Program Files\WindowsPowerShell\Modules\Az.ServiceBus\Az.ServiceBus.psd1
    C:\Program Files\WindowsPowerShell\Modules\Az.ServiceBus\Az.ServiceBus.psm1
    C:\Program Files\WindowsPowerShell\Modules\Az.ServiceBus\Microsoft.Azure.Management.ServiceBus.dll
    C:\Program Files\WindowsPowerShell\Modules\Az.ServiceBus\Microsoft.Azure.PowerShell.Cmdlets.ServiceBus.deps.json
    C:\Program Files\WindowsPowerShell\Modules\Az.ServiceBus\Microsoft.Azure.PowerShell.Cmdlets.ServiceBus.dll

  • We found the source of our pre-requisite software install fails  - by fluke.   Like you - We had to install all the modules manually, as we are not connected to the net on any of our servers - and disallowed download of certain filetypes from the web.   Somewhere in the transposition from unzipped module folder to the path on the ARS host, the folder names 'case' was switched to all lower case.

    and I kid you not.  for this installer - case mattered.   After we switched from lowercase folder names to CamelCase - exactly as shown below, our pre-req software page was replaced with the 'ready to  upgrade' screen.  we didn't have to re-install the modules - we simply fixed the case of the folder names.

    Case matters.

    our ARS Server modules folder content

    Az.Accounts

    AzureAD

    AzureAz

    ExchangeOnlineManagement

    Microsoft.PowerShell.Operation.Validation

    MicrosoftTeams

    PackageManagement

    Pester

    PowerShellGet

    PSReadline

  • Interesting, I will have to check in our test environment as even after downgrading to the required modules listed with the installer, it still failed on Az.Accounts for me, but i didnt check the case of the folder. We ended up using the silent install as well after logging a case, as we also dont use azure modules currently. The specific version requirement I was advised was due to Microsoft deprecating an application authentication mechanism which Quest will be addressing in the future.