Cannot run ssis packages because 64-bit dtexec is not installed

I've been able to successfully create an ssis package (.dtsx) file using the SSMS 'import data' option and the VS 2017 SSIS toolbox (SQL Server 2017). The package itself works and it reads a csv file and loads it into a database table. Simple. This is on windows 10.

I'm trying to run these packages on Win Server 2012 R2 (Azure VM) command line and it won't work (it does work from VS 2017) because the dtexec.exe files are all 32 bit. For the life of me I cannot get a 64 bit dtexec.exe file installed.

I've tried

1. the same procedure on windows 10 and it works. I create the package and then I can run it via dtexec /f "path to .dtsx"

2. I've tried to set the run time to 32 bit per ( SSIS 64 bit vs 32 bit) But this is not an option in either the SSMS import data tool or VS 2017 SSIS Toolbox settings/properties.

3. I've come across this page (https://www.sqlservercentral.com/articles/how-to-execute-an-ssis-package-from-the-command-line-or-a-batch-file) But I'm not sure that turning this package into a 'package deployment model' is the way to go.

4. I've tried copying the 64bit dtexec and related files to the Win 2012 R2 machine but the dll and code is not registered.

5. When I try to install SSMS or SQL Express on the server I don't get options for customizing the install.

I've confirmed that the server is 64-bit.

I've tried an azure logic app but I simply don't like it that way.

These are some of the errors I'm seeing

Code: 0xC001700A

Description: The version number in the package is not valid. The version number cannot be greater than current version number.

Could not create DTS.Application because of error 0x80040154

I would like to keep things simple and create an ssis package that can then be run at the server via a command line script that is scheduled. Why in the world is this so hard to set up on an Azure VM running Windows Server 2012 R2?

Below are a couple of more resources I've stumbled upon. Looks to me that the VS 2017 SSIS toolbox way of doing this is what MS wants people to use. How could it be that they make it so easy to create the workflow and store that into a package (the dataflow works on the Win 2012 R2 server inside of VS 2017) but when it comes time to roll it out and automate it everything falls apart? I must be missing something. Any help would be useful. How the hell do I tell VS 2017 to create a 32-bit compliant version of this package?

https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/integration-services/lesson-1-7-adding-and-configuring-the-ole-db-destination?view=sql-server-2017