SolidWorks

Software, Tasks & Script Requests
1

I’m specifically trying to install SolidWorks 2022 at the moment, but I think the installers have been the same for years. So once the install is figured out, it should easily apply to any version.

I downloaded the 2022 SP5.0 App from here: SOLIDWORKS Download Links | GoEngineer

I ran the installer to create an admin installer.

It seems like it should only need the data within the 64-bit folder, so my latest attempt included zipping that up and trying to deploy via Immy from there.

There is a .hta (html application) file that has the following install command embedded in it:
.\sldim\sldim.exe /adminclient /new /source .\admindirector.xml /norunsw

I’m able to get that to run and install from an elevated powershell prompt if I run it as:
.\sldim\sldim.exe /adminclient /new /source .\admindirector.xml /norunsw

BUT - I do get a GUI that pops up on the screen with a countdown to automatically starting the download. This will install the application and then prompt for a restart at the end. So while a gui pops up, the experience is passive, except for requiring to manually trigger the restart at the end.

When I try to run this from ImmyBot, it just hangs.

I have no idea what’s going on. I edited the generic exe install script to:
Start-Process -Wait $InstallerFile -ArgumentList “/adminclient /new /source .\admindirector.xml /norunsw”

Could use some assistance/guidance from here. I need to get this going ASAP, before science forbid my techs just start manually installing it. I didn’t necessarily bother anyone on the Immy team with scheduling a scripting call as I figured I should be able to figure this out! :sweat_smile:

2

Two things I would check. If Immy’s running the script as system, if that’s the case then the gui pop-up thing you mentioned might just be hanging in a session that you can’t see. The other thing I’d test is if you can get any different result by using start-process to call powershell.exe and then pass the $installerfile as part of the argument list.

3

Seems to cruise along fine if I run it as system from powershell on the machine:

image
image969×191 17.4 KB

image
image

The above screenshots were taken mid-install from running as system on the machine. When running from Immy I’ll see stuff in the task manager, but with no progress:
image

And nothing gets written to Program Files when running from Immy, but it does create a directory at ‘C:\SOLIDWORKS Admins’

Not sure what the difference is…

4

There’s also this other directory where it extracts some files where it looks like it’s trying to setup a SQL Server instance.

image

But no luck so far… It just kind of stops doing anything after a short amount of time.

5

Some cursory research here: Command-Line Deployment - 2022 - SOLIDWORKS Installation Help

Indicates that this is structured similarly to AutoDesk with the concept of Administrative Images but alternatively a Command Line install. We’re interested in the Command Line install:
image

The reason we want to avoid using administrative images is because every time an update comes out you have to recreate that image, which is super time consuming.

What you’ll learn when you watch it create the image is that it is simply copying all of the data from one folder to your target folder and then simply manipulating an ini/xml file to contain the parameters you specified.

Then that config file is ingested by a Setup.exe bootstrapper which ultimately feeds those parameters to a silent installer.

So let’s start by following the instructions on command line deployment instead of Administrative Image

image
image1492×892 79 KB

As you can see there are a series of prerequisites that need to be installed. Luckily Immy can install prereqs:

image
image862×378 16 KB

You have a choice here, because even though Immy can install prereqs, SolidWorks may only work with the specific version of the prereqs contained in their package whereas Immy is going to try to install the latest version of each. Further, there may be prereqs that Immy doesn’t have, like Bonjour.

Since the prereqs are included in the package already, you might as well just use them. We do something similar in our Quickbooks install script.

Once the prereqs are installed, the installer is less likely to prompt the user.

They are even nice enough to give you the relative paths to the prereq and optional MSIs within the package: MSI File Locations for Administrative Images - 2022 - SOLIDWORKS Installation Help

As well as a list of all MSI properties available for overriding on the command line:
Command-Line Global Properties - 2022 - SOLIDWORKS Installation Help

Feeling lazy and armed with some unique search strings like SOLIDWORKSSERIALNUMBER I headed off to Github and searched for SOLIDWORKSSERIALNUMBER and filtered the results to PowerShell

SCCM-Application-Deployment-Scripts/Deploy-Application.ps1 at 368550cb6679129380ba7764aa6d70d771009c11 · bciu22/SCCM-Application-Deployment-Scripts (github.com)

Where crossan007 did the hard work for us. Here’s the meat of it:

Execute-Process -Path "$dirFiles\64bit\OfficeWeb_11\owc11.exe" -Parameters "/quiet"
		Execute-Process -Path "$dirFiles\64bit\Microsoft_C++_2005_Redistributable_(x64)\vcredist_x64.exe" -Parameters "/Q"
		Execute-Process -Path "$dirFiles\64bit\Microsoft_C++_2005_Redistributable\vcredist_x86.exe" -Parameters "/Q"
		Execute-Process -Path "$dirFiles\64bit\Microsoft_C++_2008_Redistributable_(x64)\vcredist_x64.exe" -Parameters "/Q"
		Execute-Process -Path "$dirFiles\64bit\Microsoft_C++_2008_Redistributable\vcredist_x86.exe" -Parameters "/Q"
		Execute-Process -Path "$dirFiles\64bit\Microsoft_C++_2010_Redistributable_(x64)\vcredist_x64.exe" -Parameters "/Q"
		Execute-Process -Path "$dirFiles\64bit\Microsoft_C++_2010_Redistributable\vcredist_x86.exe" -Parameters "/Q"
		Execute-Process -Path "$dirFiles\64bit\Microsoft_C++_2012_Redistributable_(x64)\vcredist_x64.exe" -Parameters "/Q"
		Execute-Process -Path "$dirFiles\64bit\Microsoft_C++_2012_Redistributable\vcredist_x86.exe" -Parameters "/Q"
		Execute-Process -Path "$dirFiles\64bit\.Net_Framework_4.5.2\NDP452-KB2901907-x86-x64-AllOS-ENU" -Parameters "/Q"
		#Execute-MSI -Path "$dirFiles\64bit\Microsoft_VSTA\vsta_aide.msi"
		Execute-Process -Path "$dirFiles\64bit\VSRemoteDebugger\install.exe" -Parameters "/Q"
		Execute-MSI -Path "$dirFiles\64bit\Microsoft_VBA\vba71.msi"
		Execute-MSI -Path "$dirFiles\64bit\Microsoft_VBA_1033\vba71_1033.msi"
		Execute-MSI -Path "$dirFiles\64bit\Bonjour\Bonjour64.msi"
		## <Perform Installation tasks here>
		Execute-MSI -Path "$dirFiles\64bit\SOLIDWORKS\SOLIDWORKS.msi" -AddParameters "INSTALLDIR=""C:\Program Files\SolidWorks"" ADDLOCAL=SolidWorks SERVERLIST=""[email protected]"" SOLIDWORKSSERIALNUMBER=""xxxx xxxx xxxx xxxx xxxx"" OFFICEOPTION=3 ENABLEPERFORMANCE=0"

Now, he is using the PowerShell App Deploy Toolkit which contains helper methods like Execute-Process and Execute-MSI. The corollaries in Immy are Start-ProcessWithLogTail and Install-MSI, respectively.

With a minor amount of massaging, I’m pretty confident we can turn this into a generic installer for SolidWorks products.

1 Like
6

You rock Darren, I’m going to give this a try today. Thank you!

7

I’ve decided of going the route of doing everything individually.

image
image740×811 52.3 KB

image
image1974×557 32.6 KB

I hacked this script together with a configuration to add parameters for the Serial Number and Licensing Server. In this way I can use this one script for all of the softwares and re-use it to deploy the software to different sites with different serial numbers/licensing servers.

# Use for all SolidWorks Products with SolidWorks Configuration Task

Invoke-ImmyCommand -Timeout 600 -IncludeLocals {
$InstallerLogFile = [IO.Path]::GetTempFileName()
$Transforms = ""
$isSolidWorks = ""
if($LicenseFilePath -and (Test-Path $LicenseFilePath) -and $LicenseFilePath -like "*.mst")
{
    Write-Host "Applying $LicenseFilePath as MSI Transform"
    $Transforms = "TRANSFORMS=`"$LicenseFilePath`""
}
if ($DisplayName -like "SolidWorks 2022") {
    $isSolidWorks = "OFFICEOPTION=3 ENABLEPERFORMANCE=0"
}
$Arguments = @"
/c msiexec /i "$InstallerFile" /qn /norestart /l "$InstallerLogFile"  REBOOT=REALLYSUPPRESS INSTALLDIR="C:\Program Files\SOLIDWORKS Corp\$SoftwareName" SERVERLIST="$LicensingServer" SOLIDWORKSSERIALNUMBER="$SerialNumber" $isSolidWorks $Transforms
"@
Write-Host "InstallerLogFile: $InstallerLogFile"
$Process = Start-Process -Wait cmd -ArgumentList $Arguments -Passthru
Write-Host "Exit Code: $($Process.ExitCode)";
switch ($Process.ExitCode)
{
    0 { Write-Host "Success" }
    3010 { Write-Host "Success. Reboot required to complete installation" }
    1641 { Write-Host "Success. Installer has initiated a reboot" }
    default {
        Write-Host "Exit code does not indicate success"
        Get-Content $InstallerLogFile -ErrorAction SilentlyContinue | select -Last 50
    }
}
}

I still need to update the licensing server and have them make sure everything is working properly, but the software is on the desktop. Just need to make sure I have all the right parameters that point the softwares to the licensing server.

image

Thankfully the teacher said he has never used and does not see himself seeing Electrical, as that involves installing SQL Server 2019 and there are no examples given for installing that one, and it states that it being overly complicated as the reason for not providing documentation on that :roll_eyes: Thanks SolidWorks! :+1:

In the end, I always knew going this way (breaking out all of the installers) was an option, I was just hoping I could avoid it and simplify things with the admin install.

1 Like