More Questions about MMPT remote packaging

[TIMOTHY MANGAN]

The powershell code in the MSIX Toolkit "Batch Conversion" seems to imply that a controller may work with many different worker VMs in parallel. Each parallel thread would invoke a separate instance of the local MMPT to work with a counter-part on a different remote VM.

I wanted to ask if the MMPT is truly multi-threaded to support this.  While my testing shows OK results for a couple of worker VMs, expanding beyond that seems to cause unexpected (and inconsistent) failures.  Of course there is always the possibility of resource exhaustion occurring at some point in the chain, but I wanted to be sure that this is a supported scenario.

I want to package up a very large group of apps and want to utilize 8 worker VMs (spread out on different Hyper-V hosts).  My modified scripts work OK on two workers, but going above 3 seems an issue.

[#2]

Hi Tim,

Thanks for asking. This is an intended use case for the MSIX Packaging Tool remote packaging. I'd like to learn more about the failures you are experiencing. We will do some of our own testing as well, but its always helpful to get a variety of testing when trying to determine issues.

Best,
Sharla

[#3]

@ShakersMSFT 

Thanks for the confirmation.
I am attaching an of the example failure log files. If I rerun the exact same scenario, some of these will work and others fail instead. The failures tend to appear in two places:

1. After copying files to the VM, remote execution fails (see AdobeReader example). Both controller and worker VMs, as well as Hyper-V host are domain joined and time sync properly. Sometimes the next attempt on this VM is OK, but at other times that VM will continue to fail on all subsequent passes (reverting to the "known good" snapshot) and I must manually revert the VM, log in and then I can start the automation script over and it is OK.
2. After completing the package a similar issue occurs between the file getting saved and the copy back.

Even when this condition exists, I am able to log into the problematic VM remotely or run remote PowerShell commands to it manually, so even if this is an environmental issue, the packaging tool seems to be more sensitive to it.

I have since checked out the environment further and found that one of the AD controllers seems to have had an issue with Patch Tuesday updates.  This is being repaired and I'll rerun the tests to see if it solved the issue.

[#4]

@ShakersMSFT  Here is that example log file.

[#5]

@ShakersMSFT I have some progress to report.

• Fixing the AD controller made no difference (but a good thing to do).
• There was high CPU on VMs after reverting to the snapshot.  This was traced to windows defender. I neutered defender which helped with the issue in the previously attached log file.
• There was an additional timing issue with my scripting.  At the end of a session I was shutting down the VM (Stop-VM) and sometimes it took too long to shutdown.  Changing that to a full stop (-TurnOff option added) kept the VM from getting in the way of the next pass.

I am now running with three worker VMs without issue and will soon try to expand to more.