Invoke-ScriptInBcContainer/Enter-BcContainer fails to load other powershell modules

[KristofKlein]

A beautiful, typical, rainy Wednesday morning! You can almost smell the summer in DK! :D

I get lately more of the following reported by the dev team:
"The Expand-Archive command was found in the module "blablabla", but the module could not be loaded." What has bccontainerhelper tp do with this? well:

What I added in our scripts was some Invoke-ScriptInBcContainer, that after I moved in some zip file to the container, is about to extract the content within the container to some folder ... and that worked well, but now I get, as I said, more and more reports on this....

Not sure what triggered this "massive" raise on reports. While I investigate I could also see, it has the same issue with Enter-BcContainer ( while Open-BcContainer just worked fine).... so that lead me to: Must be the Session handling...

So my current attempt to help people out: switch the $bcContainerHelperConfig.UsePsSession flag to false. What I don't get is: some have it others not.
There is one "unique" approach we (are forced to ) use: run everything as normal users ( IT took away the local administrator rights if you maybe recall)

So my current theory is : something is not good in identifying the circumstances about that "state" the user is trigging the commands... I recall some comment on PsSession about identifying if it should use a given Session or do docker run command instead...

And because this is all I have around this topic I will leave it to you if this is worth to look in or not :D
Maybe it is at least helping others with the same issue ?!

I could ask: Is it "ok" to force the UsePsSession to false on all our machines? Do we "lose" functionality? (not that it ends up in a like the "pick your Isolation poison" dilemma ).

[freddydk]

When you say: What I don't get is: some have it others not.
Does that mean that some people don't have this flag in config?
If they have the latest version, they should.
It should work with true or false - what I have seen earlier is that when copying files into the container, the file might not be available immediately - there might be a delay.
You can also try to run import-module explicit, which then will tell you why this error is thrown

[KristofKlein]

"keep powershell modeules" up2date...same like fighting windmills ;)

when I see it I breach it again and again....fun aside...when I say "some works others not"... so I have set it to true and I don't have any issues, but the developer with the same sort of setup: non admin, same version, does get the issue...

Well....
got this from one of the "never give up developers":
... showed me something interesting - if my container has a folder named the same as what "Get-SystemLanguage" on the host OS puts out (in my case it's "en-GB") in the location C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive, the dll update script can run without any errors (the folder contents can jut be copied from "en-US" - seems to just be some localisation strings). This is very cumbersome to do though, so it's probably easier to just change the PS variable to "false" as described above, but I thought I would share this interesting information anyway

I did try to enter-bccontainer import which did not work, and I think it did not because of the "scope" / admin ... that was also why I started to tell them set the PsSession to false such that it runs "isolated" or in it's own scope (or what ever it for real means). I will try to find someone and redo to get the correct error.

Never experienced this delay in file copy....will also have an eye on this.

[dannoe]

I got the same error message (The Expand-Archive command was found in the module...) on running localDevEnv.ps1 in the BaseApp repo (https://github.com/microsoft/BusinessCentralApps).

On further research loading the Microsoft.PowerShell.Archive module failed inside the container with the following error:

Import-Module Microsoft.PowerShell.Archive
Cannot find the Windows PowerShell data file 'ArchiveResources.psd1' in directory
'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Archive\de-DE\', or in any
parent culture directories.
    + CategoryInfo          : ObjectNotFound: (C:\Windows\syst...eResources.psd1:String) [Import-Localiz
   edData], PSInvalidOperationException
    + FullyQualifiedErrorId : ImportLocalizedData,Microsoft.PowerShell.Commands.ImportLocalizedData

So it tries to load the de-DE localization data (my host system is de-DE). On the Internet I found a workaround with copying the en-US files to the de-DE folder, but since this was done while running localDevEnv.ps1, I didn't want to fiddle with the script. I did manage to workaround this error by setting the culture to en-US inside my powershell session before calling the script:

$culture = [System.Globalization.CultureInfo]::GetCultureInfo("en-US")
[System.Threading.Thread]::CurrentThread.CurrentCulture = $culture
[System.Threading.Thread]::CurrentThread.CurrentUICulture = $culture

Not sure if this helps finding the problem.

[freddydk]

Did you add these lines to the script you invoke inside the container?
or did you run these lines on the host - before invoking the script?

[dannoe]

On the host

[freddydk]

I assume this happens because you are running process isolation?
Switching to hyperv isolation might fix the issue altogether.

But..., could you try the following:

Set the culture to de-DE on the host.

Modify the file c:\run\prompt.ps1 inside the container and add the 3 lines right after the PARAM section, like:

Then run Remove-BcContainerSession -containerName $containerName on the host

Then retry the operation - does it work?
Did the culture change on the host in that session?

[KristofKlein]

so the last guy reported the issue to me is using hyperv :(

[dannoe]

I did try process and hyperv isolation. Got the same error on both modes.
I can not modify the file inside the container, because this always happens on a fresh run of localDevEnv.ps1. (The container is recreated everytime.)

Should the container normally be created with en-US or the culture of the host?

[freddydk]

This is what I think:
The container is en-US - but the session inherits the locale of the host (apparently) - and since the container is en-US - it doesn't have de-DE (or other) resources.

If you have a running container - and then start a new PowerShell prompt and run this script:

$containerName = 'bcserver'
$containerId = Get-BcContainerId -containerName $containerName
$session = New-PSSession -ContainerId $containerId -RunAsAdministrator
$PSVersionTable | Out-Host
Write-Host "Host Culture Before: $([System.Threading.Thread]::CurrentThread.CurrentCulture)"
Write-Host "Host UICulture Before: $([System.Threading.Thread]::CurrentThread.CurrentUICulture)"
Invoke-Command -Session $session -ScriptBlock {
    Write-Host "Container Culture Before: $([System.Threading.Thread]::CurrentThread.CurrentCulture)"
    Write-Host "Container UI Culture Before: $([System.Threading.Thread]::CurrentThread.CurrentUICulture)"
    $culture = [System.Globalization.CultureInfo]::GetCultureInfo("en-US")
    [System.Threading.Thread]::CurrentThread.CurrentCulture = $culture
    [System.Threading.Thread]::CurrentThread.CurrentUICulture = $culture
    Write-Host "Container Culture After: $([System.Threading.Thread]::CurrentThread.CurrentCulture)"
    Write-Host "Container UI Culture After: $([System.Threading.Thread]::CurrentThread.CurrentUICulture)"
}
Write-Host "Host Culture After: $([System.Threading.Thread]::CurrentThread.CurrentCulture)"
Write-Host "Host UICulture After: $([System.Threading.Thread]::CurrentThread.CurrentUICulture)"

Restart the PowerShell prompt and re-run the same script.
Paste both outputs here,

Thanks

[dannoe]

I was trying it first with my still existing container:

First run (PowerShell 5 with admin rights)

BcContainerHelper version 6.0.6-preview1129
Setting MicrosoftTelemetryConnectionString =

Name                           Value
----                           -----
PSVersion                      5.1.19041.3930
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.3930
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1


Host Culture Before: de-DE
Host UICulture Before: de-DE
Container Culture Before: en-US
Container UI Culture Before: en-US
Container Culture After: en-US
Container UI Culture After: en-US
Host Culture After: de-DE
Host UICulture After: de-DE

Second run (PowerShell 5 with admin rights)

BcContainerHelper version 6.0.6-preview1129
Setting MicrosoftTelemetryConnectionString =

Name                           Value
----                           -----
PSVersion                      5.1.19041.3930
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.3930
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1


Host Culture Before: de-DE
Host UICulture Before: de-DE
Container Culture Before: en-US
Container UI Culture Before: en-US
Container Culture After: en-US
Container UI Culture After: en-US
Host Culture After: de-DE
Host UICulture After: de-DE

I couldn't run it without admin or with admin and powershell core, because on these sessions New-PSSession couldn't find the container. (It was definitely running and had enough permissions.)

I tried to reproduce the error but did a pull of the newest version from https://github.com/microsoft/BusinessCentralApps before. Now I can't reproduce it.

[KristofKlein]

I have this from one of my developers:

we get the same first and second run:

Name                           Value
----                           -----
PSVersion                      5.1.19041.3930
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.3930
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Host Culture Before: en-GB
Host UICulture Before: en-GB
Container Culture Before: en-US
Container UI Culture Before: en-US
Container Culture After: en-US
Container UI Culture After: en-US
Host Culture After: en-GB
Host UICulture After: en-GB

Same here with the New-PsSession and a containerID had to start an admin Shell to execute the command.

for the fun I checked my (just fine working) machine it says:

Host Culture Before: en-GB
Host UICulture Before: **en-US**  # that is most likely why it works fine?!

while my container says:

Container Culture After: de-DE
Container UI Culture After: en-US
Container Culture Before: de-DE
Container UI Culture Before: en-US
Container Culture After: de-DE
Container UI Culture After: en-US

[KristofKlein]

another developer, another output:

Name                           Value
----                           -----
PSVersion                      5.1.22621.2506
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.22621.2506
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Host Culture Before: en-GB
Host UICulture Before: en-GB
Container Culture Before: de-DE
Container UI Culture Before: en-US
Container Culture After: en-US
Container UI Culture After: en-US
Host Culture After: en-GB
Host UICulture After: en-GB

and the second round:

Host Culture Before: en-GB
Host UICulture Before: en-GB
Container Culture Before: de-DE
Container UI Culture Before: en-US
Container Culture After: en-US
Container UI Culture After: en-US
Host Culture After: en-GB
Host UICulture After: en-GB

[freddydk]

Looked through the code...
Could you try to add -locale 'en-US' to your New-BcContainer and see whether this solves the issue.
I can see that the locale is taken from the countrycode of the version we spin up and set inside the SetupVariables script in the generic docker image:

Maybe this is really for older versions of NAV/BC and Windows - maybe we don't need this anymore - I will investigate.

[KristofKlein]

Sorry, late to the party. I will give it a try and forward to the folks having the issue. As all works for my setup I need to find a Guinea pig ;)

[KristofKlein]

nope. that did not work.