Trying to install software through Network shared folder
-
Hey guys I’m trying to install Kurzweil 3000 as a silent install. The command would be executed through a batch file that would give the command to install the program from a shared folder. Can’t seem to get it to work here is the log file that it gives me when I run it.
If i run the command with the file located locally within the system it runs it. What am I missing to be able to do it through a network shared folder?
=== Verbose logging started: 3/7/2018 8:20:13 Build type: SHIP UNICODE 5.00.7601.00 Calling process: C:\Windows\system32\msiexec.exe ===
MSI (D0:D0) [08:20:13:068]: Resetting cached policy values
MSI (D0:D0) [08:20:13:068]: Machine policy value ‘Debug’ is 0
MSI (D0:D0) [08:20:13:068]: ******* RunEngine:
******* Product: \10.154.72.190\K3000v15\Software\Kurzweil 3000 v.15.msi
******* Action:
******* CommandLine: **********
MSI (D0:D0) [08:20:13:068]: Client-side and UI is none or basic: Running entire install on the server.
MSI (D0:D0) [08:20:13:068]: Grabbed execution mutex.
MSI (D0:D0) [08:20:13:068]: Cloaking enabled.
MSI (D0:D0) [08:20:13:068]: Attempting to enable all disabled privileges before calling Install on Server
MSI (D0:D0) [08:20:13:084]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (34:40) [08:20:13:084]: Running installation inside multi-package transaction \10.154.72.190\K3000v15\Software\Kurzweil 3000 v.15.msi
MSI (s) (34:40) [08:20:13:084]: Grabbed execution mutex.
MSI (s) (34:80) [08:20:13:084]: Resetting cached policy values
MSI (s) (34:80) [08:20:13:084]: Machine policy value ‘Debug’ is 0
MSI (s) (34:80) [08:20:13:084]: ******* RunEngine:
******* Product: \10.154.72.190\K3000v15\Software\Kurzweil 3000 v.15.msi
******* Action:
******* CommandLine: **********
MSI (s) (34:80) [08:20:14:800]: Note: 1: 2203 2: \10.154.72.190\K3000v15\Software\Kurzweil 3000 v.15.msi 3: -2147024829
MSI (s) (34:80) [08:20:14:800]: MainEngineThread is returning 1620
MSI (s) (34:40) [08:20:14:800]: User policy value ‘DisableRollback’ is 0
MSI (s) (34:40) [08:20:14:800]: Machine policy value ‘DisableRollback’ is 0
MSI (s) (34:40) [08:20:14:800]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (34:40) [08:20:14:800]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (34:40) [08:20:14:800]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (34:40) [08:20:14:800]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (34:40) [08:20:14:800]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (34:40) [08:20:14:800]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (34:40) [08:20:14:800]: Restoring environment variables
MSI (D0:D0) [08:20:14:800]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (D0:D0) [08:20:14:800]: MainEngineThread is returning 1620
=== Verbose logging stopped: 3/7/2018 8:20:14 === -
The primary issue you have is this. The fog client runs as SYSTEM on the target computers. SYSTEM is an account with local administration rights, but doesn’t have any domain level rights (needed to access off system resources). If you need to access off system resources you will need to provide that connection information in the batch file, which from a security stance is not always the best choice.
As an example here is a batch file that will run an installer from a CIFS (SMB) share.
@echo off net use w: \\server01\share01 /user:domain\user01 p@ssW0rd w: cd installers setup.exe /qn! net use w: /delete
As you can see in the made up batch file you would use the net use command and then supply the credentials needed to connect to an external resource. By doing that then SYSTEM can reach outside of the target computer.
With that said, its much easier some times to just create a snapin pack (think zip file) to install applications so the installer won’t have to reach outside of the target computer to get all of the needed files. I understand that creating a snapin pack is not realistic in all cases (think of AutoDesk design suite and how big the installer files are > 35GB). In that case having a shared install directory is the only/best solution.
-
@george1421 will try using snap in packs looks like I’m getting the hang on how to use them. I’ll post how it turns out
-
Hi,
since it’s the system account place your installer in a share that can be accessed by anonymous.
Or use a snapin pack or something else that combines the installer into a package that makes the installer locally available.Regards X23
-
@x23piracy finally figured out snapin packs and they worked perfectly. Thanks guys