Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change msiexec flag to prevent modal dialog #14

Merged
merged 1 commit into from
Mar 7, 2016
Merged

Change msiexec flag to prevent modal dialog #14

merged 1 commit into from
Mar 7, 2016

Conversation

macjustice
Copy link
Contributor

In testing Brigadier with W8.1, we found that the modal created by msiexec was halting execution. Following TechNet's msiexec docs, we found that /qb- or another UI level that didn't include a modal dialog would complete successfully. Is there a reason not to use /qn?

In testing Brigadier with W8.1, we found that the modal created by msiexec was halting execution. Following TechNet's msiexec docs (linked below), we found that /qb or another UI level that didn't include a modal dialog would complete successfully.

https://technet.microsoft.com/en-us/library/cc759262(v=ws.10).aspx#BKMK_SetUI
@timsutton
Copy link
Owner

Thanks for the report! Originally we used /qn, but experienced issues with NVidia drivers not being installed (and I think something else, as well) - someone reported /qr to fix it, and that seemed to resolve the issue. More details here.

I'll happily put /qb- in the next version if it fixes this issue. When you mention that you're testing with 8.1, did you also test Windows 7, or was this a version of Boot Camp that supports only 8.1? Which hardware was this, specifically? My usage scenario has been mixed generation iMacs that still support Windows 7, so testing newer hardware and OS versions hasn't been high on my priority list.

I find the number of /q options for msiexec baffling, and given that we can only simulate a "real" Boot Camp install on real Mac hardware it's very difficult to cover the matrix of installers. This repo includes an MSI transform that sets a "no check" installer property that should allow the install to run and complete for packages matching models other than the OS (or in a VM) , but I'm not sure whether setting this property would have the same effect on real hardware in terms of all the individual component installers (some of which have their own setup wrappers like gfx drivers).

Since I'm by no means an expert in Windows installer technology I have to defer to the expertise of others, so if you have any more details or would be willing to test any of what I described above, please be my guest :)

@macjustice
Copy link
Contributor Author

I was testing on a few MacBook Pro Retinas and Airs, not really following any scientific method, though. I decided that we're just going to be imaging 8.1 and up since that's what BootCamp for current hardware requires, and we're going to be moving to 10 once we give it a once-over. Once I get my MDT imaging dialed in a little better I'll be able to give better feedback.

I'm barely a Windows novice myself, so I too would defer to anyone with better knowledge. Searching through those many and varied /q msiexec flags I just decided that quieter was better, and that seemed to fix the issue of the rogue modal.

@tupham81
Copy link

Hi Tim,

Thanks for Brigadier… really helped me.

As a former MSI Application Packager, my job was to capture software installs, customise, and repackage for enterprise SOEs. I would always use either /qn or /qb.

I can see how confusing it could be, as apps these days come in MSI form and they have customised it through the roof, so in many cases, the default strings won’t work. Other times you’d get an .MSI installer package that is wrapped within a setup.exe executable, and there are ways to extract the raw MSI file but I won’t get into.

In the instance of Bootcamp, Apple are actually slipstreaming vendor install packages (NVIDIA, AMD, etc) within their own MSI Install package, which I'd never recommend to a novice user. However, since you're all power users here, I'll step you through what I would do in an attempt to troubleshoot and resolve. Full disclaimer, you do the folowing at your own risk and I'm not guaranteeing you'll come to a solution either.

When using the /qn switch, it bypasses all steps involving user Interaction, forcing an issue with the NVidia install, who innocently was expecting some input values. My first goto would be to check the install logs of the bootcamp installer to see if it even tried to run the NVidia package. I dont recommend this for the feint hearted though as you need to open the MSI file using an MSI editor like ORCA. If you're a thrillseeker then open the MSI and youll see an "InstallExecuteSequence" table (for silent installs) and an "InstallUISequence" table (For User Interaction). You can ake a comparison between the two to see if the InstallExecuteSequence table is missing any lines. If it is missing, then you can copy the entried from one table to the other.. be careful though as entries from the InstallUITable can be executed under the context of the launching user, whereas the InstallExecuteSequence table can't run as launching user, as it is designed to be running in the background and usually under the local system context.

Believe it or not, it's actually a lot more complicated, so apologies for being too brief. So if I had no luck above, then I would start to look at the install log files for the nested install packages, specifically the ones failing. You can use the /L*v switch on the main bootcamp MSI install string, however that is only going to apply to the BootCamp.MSI install package and won't flow through to the nested installs. So you need to globally set the Logfile level to verbose:

To enable Windows Installer logging yourself, open the registry by using Regedit.exe, and take a backup of what you got currently under:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
REG_SZ: Logging

Create the following subkey and keys:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
REG_SZ: Logging
VALUE: voicewarmupx

I higly recommend you restore it to previous settings after you're done, as verbose logging will slow down your system unnecesarily for future installs.

Anyway, here’s my goto install string: msiexec.exe /i BootCamp.msi /qb (or use /qr to force the issue)

Take note of any error codes or messages as it will help you find the right spot in the log files.
Now if you go to your %TMP% folder just by keying it into Command prompt or explorer, you'll find your install log files. Sort by date and go through the most recent to find the NVidia log file and the main bootcamp installer log file.

Rather than sifting through the log file with notepad, I recommend you can use a log file tracer like CMTrace.exe or SMSTrace to trace through the log file. Check every instance of the error code or just search "Error" to find where it failed. The idea is to find out what input values it is missing that caused the fail, so you can specify it in your custom install package. If you are lucky and do find the values, then you can customise your nested install two ways:
Method 1) Edit the Properties within nested package directly via ORCA and save
Method 2) Edit the launching command for the nested install within the root Bootcamp install package

With regards to Method 2 above, you can actually set custom values for public properties (only the properties that appear in CAPS in the MSI Property table) through the install string.
So here’s an example of some Properties I set via the install string often;

Msiexec /i BootCamp.msi /L*v c:\bootcamp.log ALLUSERS=1 REBOOT=ReallySuppress /qb

I'm sure you all are familiar (as you see it on almost all installs) with the prompt asking whether you want to make the Application available to just the "Current User" or "All Users"? ALLUSERS is the property that gets set to whatever you choose, with 1 forcing it to installl to All Users. The REBOOT=ReallySuppress ensures that the installer doesnt automatically reboot the computer when it finishes installing.

I noticed Bootcamp 6 for Macbook Pro 11,5 appears to be packaged using an alternate packaging tool but looks like theyre all self extracting executables, which is more reliable... so all this is no longer required for newer models!

Good luck and hope this helps... but I doubt it.

@timsutton
Copy link
Owner

@tupham81 thank you for taking the time to post so many details. I have had to put this project on a distant back burner due to my org's lessening need for Bootcamp deployment, but I hope to do some more testing with current models like the retina 5K iMac.

I did do some digging a while ago with package editing tools and took a look at various properties set in the MSI, but given what you've explained here - and perhaps what you mentioned about the newest esds being of a newer style - I might have some better tools available to me, and someone I can ask!

timsutton added a commit that referenced this pull request Mar 7, 2016
Change msiexec flag to prevent modal dialog
@timsutton timsutton merged commit ffef49c into timsutton:master Mar 7, 2016
@timsutton
Copy link
Owner

Having gone back into looking at updating our Windows deployments to 10, I found the same thing with testing the newest Boot Camp installers on an iMac16,2 (retina 4K). Sorry for the very long time taken to actually merge this in, I'm going to do a release shortly including a couple of updates of the other tools.

@macjustice
Copy link
Contributor Author

Cool, glad to be able to contribute. We get a lot of mileage out of brigadier, I'd be happy to help test a new release.

@timsutton
Copy link
Owner

Did one up here. I've been using this successfully to bootstrap new Boot Camp installs on a Macmini7,1 and iMac16,2 with Win 10.

https://github.com/timsutton/brigadier/releases/tag/0.2.3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants