Problems deploying software through Microsoft Deployment Toolkit
I have a Microsoft Deployment server that I recently stood up, and I am having a problem with a few of the applications that are to be installed during the deployment process.
When the deployment process runs the software in question (7-zip, Adobe Acrobat 9, AutoCAD Design Review 2013 and Tight VNC) are all returning Unexpected Return Code 1620.
That code is described as "1620 This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package." according to the MSDN page I found (http://msdn.microsoft.com/en-us/library/windows/desktop/aa367988%28v=vs.85%29.aspx). But when I run the command line from Powershell it installs correctly.
Attached you will find the BDD.log file that was generated on the last deployment attempt.
Can anyone tell me why I am getting this error message with the MDT but not through Powershell?
BDD.log
When the deployment process runs the software in question (7-zip, Adobe Acrobat 9, AutoCAD Design Review 2013 and Tight VNC) are all returning Unexpected Return Code 1620.
That code is described as "1620 This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package." according to the MSDN page I found (http://msdn.microsoft.com/en-us/library/windows/desktop/aa367988%28v=vs.85%29.aspx). But when I run the command line from Powershell it installs correctly.
Attached you will find the BDD.log file that was generated on the last deployment attempt.
Can anyone tell me why I am getting this error message with the MDT but not through Powershell?
BDD.log
strivoli
I would check the credentials used to perform the deployment.
Can you post the full command lines you are using?
I have installed 7zip and Adobe myself so know they are ok.
If you can install via powershell you can call the script directly instead of running the installer.
I have installed 7zip and Adobe myself so know they are ok.
If you can install via powershell you can call the script directly instead of running the installer.
I see the following in the log:
Do you need quotes around that path?
ie
msiexec /q /i "\\den-fs-001\software\Dow
About to run command: \\DEN-DEP-001\DeploymentShare$\Tools \X64\bddru n.exe msiexec /q /i \\den-fs-001\software\Down loaded\Aut oDesk\Auto desk_Desig n_Review_2 013\MSI\Se tupDesignR eview2013. msi
Do you need quotes around that path?
ie
msiexec /q /i "\\den-fs-001\software\Dow
ASKER
I am using a domain admin account so the credentials are not an issue.
The command lines are as follows;
msiexec /q /i \\den-fs-001\software\down
msiexec /q /i "\\den-fs-001\software\dow
msiexec /q /i "\\den-fs-001\software\dow
msiexec /q /i "\\den-fs-001\software\dow
Running the script directly causes the system to either ignore the /q flag or fail with an unknown error code (don't have the actual code, but I can get it to generate one if needed)
Adding quotes to the command lines does not make a difference. The scripts that do have quotes, have them to force the system to ignore the spaces in the path.
The command lines are as follows;
msiexec /q /i \\den-fs-001\software\down
msiexec /q /i "\\den-fs-001\software\dow
msiexec /q /i "\\den-fs-001\software\dow
msiexec /q /i "\\den-fs-001\software\dow
Running the script directly causes the system to either ignore the /q flag or fail with an unknown error code (don't have the actual code, but I can get it to generate one if needed)
Adding quotes to the command lines does not make a difference. The scripts that do have quotes, have them to force the system to ignore the spaces in the path.
Not sure if it makes a difference but I always have the command as follows:
msiexec /i "<filepath>" /qn /norestart
msiexec /i "<filepath>" /qn /norestart
Hi,
I looks like a path limitation in Windows. The share name has a 12 character limit apparently.
http://support.microsoft.com/kb/294978.
To test, forget MDT and just try installing the MSI from that path manually. Either
\\DEN-DEP-001\DeploymentSh
or
msiexec /i \\den-fs-001\software\down
It's not a magic feature of PowerShell. I've learn with deployments that MSI behaviour differs according to the path where it's run from. The error codes can often be misleading.
Mike
I looks like a path limitation in Windows. The share name has a 12 character limit apparently.
http://support.microsoft.com/kb/294978.
To test, forget MDT and just try installing the MSI from that path manually. Either
\\DEN-DEP-001\DeploymentSh
or
msiexec /i \\den-fs-001\software\down
It's not a magic feature of PowerShell. I've learn with deployments that MSI behaviour differs according to the path where it's run from. The error codes can often be misleading.
Mike
ASKER
Moving the /q to the end does not seem to make a difference.
The MSIs works when installed manually.
I tried moving the installs to a drive on the local machine (new command lines below) and now all return error code 1619.
msiexec /i E:\Software\7-Zip\x64\7z46
msiexec /i E:\Software\Acrobat_9\Acro
msiexec /i E:\Software\DesignReview_2
msiexec /i "E:\Software\TightVNC x64\tightvnc-2.6.4-setup-6
The MSIs works when installed manually.
I tried moving the installs to a drive on the local machine (new command lines below) and now all return error code 1619.
msiexec /i E:\Software\7-Zip\x64\7z46
msiexec /i E:\Software\Acrobat_9\Acro
msiexec /i E:\Software\DesignReview_2
msiexec /i "E:\Software\TightVNC x64\tightvnc-2.6.4-setup-6
I can't see any successful applications install in your log. Do you have any installing correctly?
Can you add /i <pathtologfile.txt> into the command line which will hopefully log some more information.
Can you add /i <pathtologfile.txt> into the command line which will hopefully log some more information.
This really ought to be credentials? I don't know under what security context the install occurs. Give all users Read on that folder and see what happens.
ASKER
Some software is installing successfully, but I am not running those installs as they are fine. I can produce a BDD.log with all software installs included if you like.
I will add the flag you are requesting and post a new bdd.log with the results.
The attached image is of the user rights for the folder containing all of the installs in question. As you can see all users have full control, so it can't be credentials. Also, as I mentioned earlier, I am using a domain admin account so there should be no credential issues in the first place.
I will add the flag you are requesting and post a new bdd.log with the results.
The attached image is of the user rights for the folder containing all of the installs in question. As you can see all users have full control, so it can't be credentials. Also, as I mentioned earlier, I am using a domain admin account so there should be no credential issues in the first place.
ASKER
Here is a new bdd.log file after adding the /li flag to the command line.
I do not see separate log files generated by the /li flag in the root of C:. Do you know the default output location for these log files?
BDD.log
I do not see separate log files generated by the /li flag in the root of C:. Do you know the default output location for these log files?
BDD.log
Sorry, that should have been /l not /i. (L)
The log file should be wherever you have written the path in your command
The log file should be wherever you have written the path in your command
Hi
If you are getting *any* error code returned from the MSI, then it's not a share permissions thing - you would get a different MDT based error code
Putting /q at the end or the start will make no difference.
The key thing is this: if you copy the MSI and all files it uses locally and still can't install it, it will never work from MDT. Error 1619 is a specific MSI error usually meaning the MSI is broken, locked by something, can't be read or is missing one or more files.
As I said running from a network is different from local and from USB.
If all MSI installs fail, but something like Silverlight works, then it's an MSI issue. Seeing as you don't have any non-MSI installs, try installing the EXE version of 7-zip with /s.
How can I install 7-Zip in silent mode?
For exe installer: Use the "/S" parameter to do a silent installation and the "/D=dir" parameter to specify the "output directory". These options are case-sensitive. 7-Zip uses the NSIS installer by Nullsoft.
Please attach this log: C:\Users\ADMINI~1\AppData\
it might have more evidence, but it's looking like an MSI issue now.
How have you created them? I don't see any MST options. Is each app in it's own folder with all the files?
The full command line for silent, deploy-friendly MSI installs is:
%windir%\system32\msiexec /i yourapp.msi /qn REBOOT=ReallySuppress /l*v "%programfiles%\Logs\MDT_y
I give the path to msiexec to stop an error about the path; it works without it but I don't like seeing errors!
/qn is quiet no GUI
REBOOT=ReallySuppres is case specific and prevents reboot
/l*v path\file.log will create a verbose log file.
Mike
If you are getting *any* error code returned from the MSI, then it's not a share permissions thing - you would get a different MDT based error code
Putting /q at the end or the start will make no difference.
The key thing is this: if you copy the MSI and all files it uses locally and still can't install it, it will never work from MDT. Error 1619 is a specific MSI error usually meaning the MSI is broken, locked by something, can't be read or is missing one or more files.
As I said running from a network is different from local and from USB.
If all MSI installs fail, but something like Silverlight works, then it's an MSI issue. Seeing as you don't have any non-MSI installs, try installing the EXE version of 7-zip with /s.
How can I install 7-Zip in silent mode?
For exe installer: Use the "/S" parameter to do a silent installation and the "/D=dir" parameter to specify the "output directory". These options are case-sensitive. 7-Zip uses the NSIS installer by Nullsoft.
Please attach this log: C:\Users\ADMINI~1\AppData\
it might have more evidence, but it's looking like an MSI issue now.
How have you created them? I don't see any MST options. Is each app in it's own folder with all the files?
The full command line for silent, deploy-friendly MSI installs is:
%windir%\system32\msiexec /i yourapp.msi /qn REBOOT=ReallySuppress /l*v "%programfiles%\Logs\MDT_y
I give the path to msiexec to stop an error about the path; it works without it but I don't like seeing errors!
/qn is quiet no GUI
REBOOT=ReallySuppres is case specific and prevents reboot
/l*v path\file.log will create a verbose log file.
Mike
ASKER
I am using the x64 version of 7-zip which has no .exe available. There is only an .MSI file. I could go to the x86 version, but I would prefer to keep things consistent.
I have a number of non-MSI installers in the MDT. I have just been running the installers that I have been having trouble with. I have attached the BDD.log from a full install, including the functioning .exe installs.
I have also attached the SMSTS log file as well.
I have not built any of the MSI files that I have been using. They are all the .MSI's that are available from the software manufacturer.
The Design Review 2013 .MSI is the file that was specifically recommended in a thread (on the Autodesk site) about silently installing the software (though not through MDT).
BDD.log
I have a number of non-MSI installers in the MDT. I have just been running the installers that I have been having trouble with. I have attached the BDD.log from a full install, including the functioning .exe installs.
I have also attached the SMSTS log file as well.
I have not built any of the MSI files that I have been using. They are all the .MSI's that are available from the software manufacturer.
The Design Review 2013 .MSI is the file that was specifically recommended in a thread (on the Autodesk site) about silently installing the software (though not through MDT).
BDD.log
ASKER
Here are the logs from the latest install attempts of the 7-Zip, Acrobat 9, Design Review 2013, and TightVNC.
Everything looks like it is working correctly, but I am new to reading these logs, so I am not sure of that.
7zip.txt
acrobat.txt
DRVW2013.txt
Tightvnc.txt
Everything looks like it is working correctly, but I am new to reading these logs, so I am not sure of that.
7zip.txt
acrobat.txt
DRVW2013.txt
Tightvnc.txt
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Cutting out the path did the trick.
Thanks a ton Mike. You are awesome.
Also. thanks for pointing out the typo. I am dyslexic, so those things can be hard for me to spot sometimes.
Thanks a ton Mike. You are awesome.
Also. thanks for pointing out the typo. I am dyslexic, so those things can be hard for me to spot sometimes.