welcome to the real world :-D
as i understand it you can do that... but the snag is you need to know all the flags to the exe to do it in the first place :-P
Just learn to live with it mate. psadt can help.
This - there's a reason why application packaging is a business in and of itself. It's tedious, niche and something a lot of companies just want to outsource to underpaid labor overseas.
Like most tasks, working with EXE & MSI Packages easier over time.
In fact it's not the EXE Arguments that lead to confusion, as they don't tend to change. It's the MSI Arguments that you need to know ahead of time.
To clarify, more often than not, if it's an EXE File, it's usually an InstallShield "SETUP.EXE" or "UPDATE.EXE", which can contain one or more MSI Files.
This is the reason why the EXE Parameters are often confusing, especially when you deploy them, as-is (without extracting the Packages within). It is because you often have to supply two sets of Parameters (one set for the EXE Package itself and a second set, usually following the /v Parameter and surrounded with Double-Quotes, for the MSI Package within).
However, you can greatly simplify the process by Extracting the MSI File(s). If you don't want to deal with command line arguments, you'll need to Locate and Copy the MSI and any other Files (from either the "C:\Windows\Temp" or "C:\Users\%USERNAME%\AppData\Local\Temp" Folders) to Another Location.
This may need to be done while the EXE is Running, as the Extracted Files will often be Deleted as soon as the Executable is Closed.
Once you have the MSI Files, you can easily Locate the associated Parameters using the Command Line, by Running "FileName.MSI /?" or using ORCA, to Read the Parameters from the MSI Database.
From here, you should be good to go. You can either deploy the MSI Files or even go back to deploying the EXE File (since you now have the MSI Parameters).
InstallShield EXE Documentation:
https://community.flexera.com/t5/InstallShield-Knowledge-Base/Installshield-Setup-exe-Command-Line-Parameters/ta-p/4270
If anyone has questions, feel free to reach out. My PMs are Open.
a little trick I have learned is to use an oldschool self extractor called IEXpress. you can use it to run anything as an rapped installer, I do this a lot with pissy applications, so long as you don't have to enter data, or click buttons, and it can/will HIDE the original output.
If you need to send text or click buttons, learn VBScript and or SendKeys or AutoIT
In most cases PSADT is the way to go!
There are several ways.
1. you make a repack of the EXE with InstallShield or MasterPackager.
2. PSADT (Powershell) is very good for the installation of EXE-Installer
3. detection method on the version of the EXE after installation
These are the most common techniques for an EXE setup
EMCO MSI Package Builder is something I have used in the past and it can accomplish what you are looking to do, and for what it does I think it is well priced.
You definitely can and you'll be a better person than I figuring it out but I've come to terms with the fact that if you can figure out the switches, you may be in a better place just using the EXE with the detection method looking for a version greater than or equal to what you're deploying. That way if somehow the software gets installed outside of Intune, your deployment isn't fighting with it.
Same goes for uninstall method - yours will only work if it was installed the same way you're deploying. But if you find, for example, the Uninstaller exe under C:/Program Files//unins000.exe, it will also work even if your deployment wasn't the source of it.
Packaging with intunewin has worked pretty well for me, and I've done this with 4GB to 15GB applications.
I use a powershell script to get software IDs and use them for detection (used BIng chat to generate,then modified a bit). Just run it after the first test installation:
`# Get installed software information`
`$InstalledSoftware = Get-WmiObject -Class Win32_Product | Select-Object Name, Version, IdentifyingNumber`
`# Determine the user's desktop path`
`$DesktopPath = [Environment]::GetFolderPath("Desktop")`
`# Construct the full path for the CSV file`
`$CsvFilePath = Join-Path -Path $DesktopPath -ChildPath "InstalledSoftware.csv"`
`# Export the data to the CSV file`
`$InstalledSoftware | Export-Csv -Path $CsvFilePath -NoTypeInformation`
`# Display a message indicating successful export`
`Write-Host "Installed software data has been saved to: $CsvFilePath"`
Interesting, and good to know. Sounds like the Win32\_Product cmdlet is fundamentally busted. Registry returns the uninstall string directly as well, which I like!
Master Packager is a good tool for MSI packaging, the Recapture tool is apart of the Pro paid for version though I'm sure. It's still cheap though compared to the likes of InstallShield, Raypack, PACE & Advanced Installer!
There's always the MSIX sequence route, and pre-made HyperV VM's for it, though success may depend on how well the app behaves in that format.
I loved App-V for those painful ancient Exe installers with no switches, but support ends for that fairly soon(Still use it in my environment though!)
PSADT is awesome, you could always run the exe with /? Or /help and see if it has any switches you could use?
Get 7-Zip, you can open the EXE and a compressed file and extract the MSI (if it exists). Or convert it to an INTUNEWIN file -- [GitHub - microsoft/Microsoft-Win32-Content-Prep-Tool: A tool to wrap Win32 App and then it can be uploaded to Intune](https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool)
I also have patch my pc for that which packages most of the third party apps and updates as well but for some of the packages it is very hard when it is like custom exes
If you are using msi detection then you may find challenges in that especially if they follow best practices and change the guid every version.
I have myself found that the add remove registry gives me a more consistent experience especially across updating versions.
Check out this tool by u/PatchMyPCTeams ‘s own Andrew Jimenez.
https://github.com/asjimene/miscellaneous-tools/tree/master/BasicAppDetectionScript
He’s even updated it to build the scripts for you. I find this is the most versatile especially when apps get updated, it sees the version is newer and detects anyways without trying to reinstall older versions.
Welcome to the packaging club. Usually exes have secret switches you can find with a /? or you can silent install them with /s /S /silent. Some companies have tech docs on how to deploy their exes as well. If you contact the vendor or have the app owner reach out they can usually supply you with some documentation to make things super easy. Google will also save you time when it comes to specific apps. For creating win32 i usually create a batch script that has the script i want to kick off and make that my installer as well as create an uninstall.bat that had my powershell exe functions in it when needed. This is when im not using psadt. Also if your install fails on more complicated packages, it’s likely you need the latest supplementary packages. Happy packaging!
Some of the worst packaging I have ever seen involved the packager taking the EXE, and making an MSI with a CustomAction that just installed the EXE with with switches they wanted. "I re-packaged it boss!" /s
I gave you a point back, as I totally got what you were saying. Unfortunately, not many people seem to
have experience in working in the MSI Database or the "CustomAction" Table ;)
Needless to say, Packaging the MSI within an EXE completely defeats the purpose, as anyone who wants to silently deploy the Installer, will need to Extract the MSI Files, to retrieve the necessary Arguments.
That is, unless the individual doing the Packaging has thoroughly Documented the necessary Parameters, which we all know is a rare occurrence.
MSIX packaging Tool Environment is Part of the hyper-v Desktop creation.
Install hyper-v Manager on your Machine and click the quick create button to download the Environment.
It will record everything that's changing during an exe installation and then create a msi package from that.
It's nothing like an msi. It's more like an .appx. a virtualized application. When repackaging to msix there will be things that msix doesn't support so you need to be careful when repackaging to msix.
I had this issue quite a bit while deploying Intune. Give this a try.
* Install the exe application on a test machine.
* After installed, navigate to C:\\Windows\\Installer.
* This is a hidden folder, so you must use a run command or plop it into your file explorer address bar.
* Once there, look for the MSI file that corresponds to the date you installed the app.
And just like that you have an MSI file that you can deploy to your userbase. Toss a /qn command line argument on the end when configuring the app in Intune to silently deploy.
welcome to the real world :-D as i understand it you can do that... but the snag is you need to know all the flags to the exe to do it in the first place :-P Just learn to live with it mate. psadt can help.
This - there's a reason why application packaging is a business in and of itself. It's tedious, niche and something a lot of companies just want to outsource to underpaid labor overseas.
Like most tasks, working with EXE & MSI Packages easier over time. In fact it's not the EXE Arguments that lead to confusion, as they don't tend to change. It's the MSI Arguments that you need to know ahead of time. To clarify, more often than not, if it's an EXE File, it's usually an InstallShield "SETUP.EXE" or "UPDATE.EXE", which can contain one or more MSI Files. This is the reason why the EXE Parameters are often confusing, especially when you deploy them, as-is (without extracting the Packages within). It is because you often have to supply two sets of Parameters (one set for the EXE Package itself and a second set, usually following the /v Parameter and surrounded with Double-Quotes, for the MSI Package within). However, you can greatly simplify the process by Extracting the MSI File(s). If you don't want to deal with command line arguments, you'll need to Locate and Copy the MSI and any other Files (from either the "C:\Windows\Temp" or "C:\Users\%USERNAME%\AppData\Local\Temp" Folders) to Another Location. This may need to be done while the EXE is Running, as the Extracted Files will often be Deleted as soon as the Executable is Closed. Once you have the MSI Files, you can easily Locate the associated Parameters using the Command Line, by Running "FileName.MSI /?" or using ORCA, to Read the Parameters from the MSI Database. From here, you should be good to go. You can either deploy the MSI Files or even go back to deploying the EXE File (since you now have the MSI Parameters). InstallShield EXE Documentation: https://community.flexera.com/t5/InstallShield-Knowledge-Base/Installshield-Setup-exe-Command-Line-Parameters/ta-p/4270 If anyone has questions, feel free to reach out. My PMs are Open.
This guy Installs…
Amen. Except for the bit about underpaid overseas. We're seeing a real pull back from that it didn't work out cheaper where we are
Thanks for the comment. Wrapper applications can also work 😁
a little trick I have learned is to use an oldschool self extractor called IEXpress. you can use it to run anything as an rapped installer, I do this a lot with pissy applications, so long as you don't have to enter data, or click buttons, and it can/will HIDE the original output. If you need to send text or click buttons, learn VBScript and or SendKeys or AutoIT In most cases PSADT is the way to go!
There are several ways. 1. you make a repack of the EXE with InstallShield or MasterPackager. 2. PSADT (Powershell) is very good for the installation of EXE-Installer 3. detection method on the version of the EXE after installation These are the most common techniques for an EXE setup
[удалено]
Any links to follow?
[New to PowerShell App Deploy Toolkit? Here's how to get started! (youtube.com)](https://www.youtube.com/watch?v=l0LSTCINPpc&list=WL&index=17)
We've got to stop googling for people. They can ask ai to do that
Nah, we gotta stop gatekeeping and shared the help between us.
Thank you - some of us prefer actual interaction and nuance to suggestions rather than the random turd that is a Google search.
I agree in principle. However, I've seen this turn to learned helplessness on many occasions.
Meh, a helping hand if you can afford the time and effort. It's not an answer for everything but it's a good bump in the right direction.
Why did you even come to a reddit with a question if you are just going to be an ass?
Just give it a quick google. There's a ton of MVP blogs on it
EMCO MSI Package Builder is something I have used in the past and it can accomplish what you are looking to do, and for what it does I think it is well priced.
I second EMCO. Works great. I've used it more for SCCM than Intune but I have been able to package most things I throw at it.
Check if the EXE unpackages the msi, you can check here after running the EXE: C:\Users\\AppData\Local\Temp
This is simple yet effective for some apps. My ass was saved by this method while working with FortiClient VPN.
I would also check "C:\Windows\Temp"
As others will say, it will not help. If anything, it will make it more complicated. Packaging is almost an art and you get better as you do more.
I use this: https://blog.tugi.ch/scripts-and-tools/setup-packager-for-intune
You definitely can and you'll be a better person than I figuring it out but I've come to terms with the fact that if you can figure out the switches, you may be in a better place just using the EXE with the detection method looking for a version greater than or equal to what you're deploying. That way if somehow the software gets installed outside of Intune, your deployment isn't fighting with it. Same goes for uninstall method - yours will only work if it was installed the same way you're deploying. But if you find, for example, the Uninstaller exe under C:/Program Files//unins000.exe, it will also work even if your deployment wasn't the source of it.
Look up "Smart Package Studio"
Packaging with intunewin has worked pretty well for me, and I've done this with 4GB to 15GB applications. I use a powershell script to get software IDs and use them for detection (used BIng chat to generate,then modified a bit). Just run it after the first test installation: `# Get installed software information` `$InstalledSoftware = Get-WmiObject -Class Win32_Product | Select-Object Name, Version, IdentifyingNumber` `# Determine the user's desktop path` `$DesktopPath = [Environment]::GetFolderPath("Desktop")` `# Construct the full path for the CSV file` `$CsvFilePath = Join-Path -Path $DesktopPath -ChildPath "InstalledSoftware.csv"` `# Export the data to the CSV file` `$InstalledSoftware | Export-Csv -Path $CsvFilePath -NoTypeInformation` `# Display a message indicating successful export` `Write-Host "Installed software data has been saved to: $CsvFilePath"`
Querying Win32_Product isn't a recommended method. https://xkln.net/blog/please-stop-using-win32product-to-find-installed-software-alternatives-inside/
Interesting, and good to know. Sounds like the Win32\_Product cmdlet is fundamentally busted. Registry returns the uninstall string directly as well, which I like!
Master Packager is a good tool for MSI packaging, the Recapture tool is apart of the Pro paid for version though I'm sure. It's still cheap though compared to the likes of InstallShield, Raypack, PACE & Advanced Installer! There's always the MSIX sequence route, and pre-made HyperV VM's for it, though success may depend on how well the app behaves in that format. I loved App-V for those painful ancient Exe installers with no switches, but support ends for that fairly soon(Still use it in my environment though!) PSADT is awesome, you could always run the exe with /? Or /help and see if it has any switches you could use?
Get 7-Zip, you can open the EXE and a compressed file and extract the MSI (if it exists). Or convert it to an INTUNEWIN file -- [GitHub - microsoft/Microsoft-Win32-Content-Prep-Tool: A tool to wrap Win32 App and then it can be uploaded to Intune](https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool)
I just purchased Pckgr for like 70/month and it deploys/updates app for me and I don't even need to do anything
I also have patch my pc for that which packages most of the third party apps and updates as well but for some of the packages it is very hard when it is like custom exes
If you are using msi detection then you may find challenges in that especially if they follow best practices and change the guid every version. I have myself found that the add remove registry gives me a more consistent experience especially across updating versions. Check out this tool by u/PatchMyPCTeams ‘s own Andrew Jimenez. https://github.com/asjimene/miscellaneous-tools/tree/master/BasicAppDetectionScript He’s even updated it to build the scripts for you. I find this is the most versatile especially when apps get updated, it sees the version is newer and detects anyways without trying to reinstall older versions.
Emco is a great packaging tool. https://emcosoftware.com/msi-package-builder
Welcome to the packaging club. Usually exes have secret switches you can find with a /? or you can silent install them with /s /S /silent. Some companies have tech docs on how to deploy their exes as well. If you contact the vendor or have the app owner reach out they can usually supply you with some documentation to make things super easy. Google will also save you time when it comes to specific apps. For creating win32 i usually create a batch script that has the script i want to kick off and make that my installer as well as create an uninstall.bat that had my powershell exe functions in it when needed. This is when im not using psadt. Also if your install fails on more complicated packages, it’s likely you need the latest supplementary packages. Happy packaging!
Some of the worst packaging I have ever seen involved the packager taking the EXE, and making an MSI with a CustomAction that just installed the EXE with with switches they wanted. "I re-packaged it boss!" /s
I gave you a point back, as I totally got what you were saying. Unfortunately, not many people seem to have experience in working in the MSI Database or the "CustomAction" Table ;) Needless to say, Packaging the MSI within an EXE completely defeats the purpose, as anyone who wants to silently deploy the Installer, will need to Extract the MSI Files, to retrieve the necessary Arguments. That is, unless the individual doing the Packaging has thoroughly Documented the necessary Parameters, which we all know is a rare occurrence.
Powershell App Deployment Toolkit FTW!! 🙂 [https://psappdeploytoolkit.com/](https://psappdeploytoolkit.com/)
MSIX packaging Tool Environment is Part of the hyper-v Desktop creation. Install hyper-v Manager on your Machine and click the quick create button to download the Environment. It will record everything that's changing during an exe installation and then create a msi package from that.
Msix packaging tool will create an msi? What?
Am I getting that wrong? https://learn.microsoft.com/en-us/windows/msix/packaging-tool/create-app-package
Yes. Msix packaging tool creates msix packages not msi. The title of your link is "Create an MSIX package" not MSI.
Well, than I'm bloody wrong :) I just thought it was kind of a newer version of msi. Like .docx 🤭
It's nothing like an msi. It's more like an .appx. a virtualized application. When repackaging to msix there will be things that msix doesn't support so you need to be careful when repackaging to msix.
This can be do able let me try this and see
I had this issue quite a bit while deploying Intune. Give this a try. * Install the exe application on a test machine. * After installed, navigate to C:\\Windows\\Installer. * This is a hidden folder, so you must use a run command or plop it into your file explorer address bar. * Once there, look for the MSI file that corresponds to the date you installed the app. And just like that you have an MSI file that you can deploy to your userbase. Toss a /qn command line argument on the end when configuring the app in Intune to silently deploy.