Windows Context - Start Script - Powershell Process is 32 Bit


(Ulrich P.) #1

Hi,

I am trying to implement some simple setup routines uitilizing the context start script (addon-context-windows 5.4.1), like setting up a domain controller on a Windows Server 2016 Core VM.

Therefore I use the following commands:
Import-Module servermanager
Install-WindowsFeature AD-Domain-Services
Install-ADDSForest -DomainName $context[“AD_Domain”] -SafeModeAdministratorPassword:(ConvertTo-SecureString -String $context[“AD_SAFEMODEPASSWORD”] -AsPlainText -Force) -force

Interactively (while I am logged in as Adminstrator) this script works fine. The command [Environment]::Is64BitProcess returns true in this case.

Running these commands in the Start Script I get an “import-module the specified module servermanager was not loaded because no valid module file was found” error. The next cpmmands also throw errors. Searching the internet indicates that this might be a problem because the powershell used by the start script is a 32 bit process. And indeed [Environment]::Is64BitProcess returns false when executed in the start script.

Question: How to fix this, so that I can run the commands mentioned above?

P.S.: For cloud-init I found a similar problem and the solution is to start the script with #ps1_sysnative Maybe there is a similar switch which I have overseen!?

Thanks
Uli


(michael_kutzner) #2

Hi Uli
issue is, that rhsrvany.exe is a 32bit executable which then starts the contextualization.
This is not yet available in the standard context packages. What I did is to not use the service (disable that before sysprepping) but add startup.vbs to the startup scripts (gpedit.msc) - also before sysprepping.
Best, M


(Ulrich P.) #3

Hi Michael,

thanks for the insights and workaround. Do you know, if providing rhsrvany.exe as a 64bit is somewhere on the horizon? Is it an issue at Redhat to provide this binary or is it an integration topic on OpenNebula side? Is there anything I can help?

I am asking this because before implementing a workaround I might still wait a couple of weeks…

Thanks
Uli


(michael_kutzner) #4

Hi Uli,

sorry - at that time when I checked it I did not find it (even I have to admit that I did not do a deep dive) - as it was a
fast workaround for us it was fine and I can change immediately if it is solved at a certain point.
Maybe it is already existing and makes it’s way into the next version…but to be honest, I don’t know

Best, M


(Vlastimil Holer) #5

Added tracking GitHub issue for this problem:

Thank you.