We spent about a week working with Mathworks support and PDQ support to figure this out and they requested that I post my results here in case others have the same issue.
We specifically worked with Matlab 2017a in this case but I assume that it would work with other versions as well.
The first issue that we ran into was that the installer files were distributed to us as two ISO's. Our lab admins were manually mounting each ISO, one at a time, on each machine in order to install the software. Luckily, Mathworks provides documentation on how to merge the two ISO's into one installer package: https://www.mathworks.com/matlabcentral/answers/320198-how-can-i-obtain-a-single-installation-package-for-matlab-with-the-isos-merge-the-iso-images
Once you have done this, put the installer package up on your PDQ Deploy repository. This guide assumes that you have a network file share set up for this purpose or at least you know how to set that up. If you don't have one and don't know how then you should check out PDQ's youtube channel. It's a great resource and they have videos that can help teach you how to do that: https://www.youtube.com/user/AdminArsenal
After that you will need to create an installer_input.txt file. There should already be a Mathworks-provided example installer_input.txt file in your installer package. I recommend that you save that one for future reference and copy it to create your version. Here are the options that we uncommented and set but your experience may differ:
A few additional notes on the installer_input.txt file-- we always leave all of the products at the bottom commented out. The installer defaults to installing all of your licensed products-- if you start manually defining packages then it could install products that you are not licensed for or it could omit packages that you are licensed for. You don't want either of those things to happen. We have a FlexLM license server for Matlab but for some reason the installer still wants our license file. I'm assuming that it uses it to determine which features you are licensed for but I'm not sure. Make sure you use a UNC path to point to your license file. Put the license file in the root of your Matlab installer folder (the same folder where setup.exe is)
Now for the actual PDQ package. We did a separate package to uninstall Matlab 2016a and then embedded it into our installer package as a nested package as the last step. We used to have it as the first step during testing but our file server rebooted in the middle of a Matlab 2017a deployment, having already uninstalled Matlab 2016a from a bunch of machines. You can side-install different versions of Matlab without issue so it's safer to save the uninstall step for last. That way the worst-case scenario is that Matlab 2016a is still there and Matlab 2017a is only halfway there, so at least the workstation has one working version of Matlab.
For our next step we have a command step that sets an environmental variable so Matlab knows where our license server is. The command is:
setx MLM_LICENSE_FILE email@example.com /m
For our next step we are not going to do an install step; we are going to do a command step instead. The installer step was fraught with issues because the setup.exe passes off the installation to /bin/win64/setup.exe. That causes PDQ Deploy to think the deployment is finished and begin cleaning up the files. That will result in a "file not found" error in the Matlab installer log file, and the installation will fail. Thus, a command step:
\\server\share\PDQ_Deploy_Repo\Matlab\2017a\bin\win64\setup.exe -inputFile \\server\share\PDQ_Deploy_Repo\Matlab\2017a\installer_input.txt
Make sure to point at the \bin\win64\setup.exe and not the setup.exe in the root of the folder. I don't know why it works, but it does.
The last step is a reboot step.
For all of our steps, we set the following conditions:
O/S Architecture: 64-bit
Logged On State: Only run if no user is logged on
And that's it! This package (including uninstall) takes ~12 minutes in my testing VM (very fast, SSD) and ~30 minutes on our slowest lab machines (Core2Duo, Windows 7x64, 4GB of RAM).
Please sign in to leave a comment.