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

Parents
  • Did you also install the MSOnline module?

    Did you reboot after performing your module installations?

  • Able to get past this issue?   I'm working with my team now to get 7.4.5 installed in our dev environment ... should be the easiest install of all.  nope.

    we have the module folders copied into the default module location and can see the commandlets associated when we run get-command *exo*  .. *team* etc.
    we are being prompted for all the modules and a SQL connector, each of which we have in place.   

    If there was a be-all ending to this question ... can you share?

Reply
  • Able to get past this issue?   I'm working with my team now to get 7.4.5 installed in our dev environment ... should be the easiest install of all.  nope.

    we have the module folders copied into the default module location and can see the commandlets associated when we run get-command *exo*  .. *team* etc.
    we are being prompted for all the modules and a SQL connector, each of which we have in place.   

    If there was a be-all ending to this question ... can you share?

Children
  • Hi, I went with the quiet install, I couldn't pass all requirements (install the modules offline). As I don't use the Azure parts in ARS anyway, that was working for me. 

    E:\ARS_Software\Active_Roles_7.5\ActiveRoles.exe /quiet /install /IAcceptActiveRolesLicenseTerms /log "E:\ARS_Software\Active_Roles_7.5" 

    Regards,
    Micha

  • we used this method too - Micha - thanks for the reply. it allowed us to get past the install pre-req check, but that leaves me with no confidence in the post-install ability to fill the needs of all the tools we support / or will soon support that require these modules to be installed and properly configured.  we have an onsite Microsoft rep who confirmed with us that a module-is-just-a-folder-with-stuff-inside.  there are no registry keys, no magic environment variables involved.  the installer should see and accept the module found at the default location.    We're working with OneIdentity support to evaluate why - despite putting the extracted folders in place - that the pre-requisites screen still tells me 3 modules are not installed.   Where I work - We can't just d/l ... there are a number of hoops to jump, with each module requiring it's own separate set of hoops.  I don't fully understand why  - given all the 'check here to accept this and that license for 3rd party tools' already in place in the 7.5.3 installer  ... why the dev team couldn't just include the required modules in the redistributables folder, and auto-install where needed.     

    We're proceeding with support, and while that plays out, testing out the new silently installed version in DEV ...  we are exporting production templates/scripts/workflows/websites to make sure our customizations still play nice in the new version.   

    Thanks again for the feedback.  Helped us get on our way.

  • Many thanks for that answer, I too reported to oneIdentity that the modules should be part of the installation and still hoping this will be the case in a later version because I've lost too much time for this topic already in the past. The statment from microsoft is very helpful to me too, thanks!

  • We are reviewing the PowerShell requirements for a future release of Active Roles.

    For the current releases of Active Roles, not having them installed may put customers in an unsupported configuration as this has not been officially tested.

    Please refer to KB 333457 for details:

    https://support.oneidentity.com/active-roles/kb/333457/active-roles-powershell-module-prerequisites

    Thank you,

    Daniel Bishop

    One Identity

  • Hi Daniel, the quiet install was suggested by the OneIdentity Support as the install did not recognize the offline installed module folders. So I do not hope that this will put me in an unsupported configuration now. Unfortunately the support team wasn't able to find any other solution at this time.

  • 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