MSI Error 1619. Different Cause?
Hi All,
I have an ongoing issue where installations sent to Windows 2008 R2 servers fail with an MSI 1619 error. I am aware that this indicates an issue with not being able to access the files. However, my problems only are seen when sending to servers. Sending the very same packages to workstations ALWAYS work fine and I have successfully done so hundreds of times to XP, Windows 7, and Windows 8 machines. Server 2003 and Server 2012 installs work fine as well. I am stumped on this one. The install account that I use is the same for workstation and server installs and it has admin rights to workstations and servers alike. All installs are Pull type and the copy to the local seems to work fine. Once it kicks off the install, then it fails. It implies to me that the install account doesn't have rights to the PDQDeployRunner folder but I have checked and it has full control. Any ideas?
Thanks!
-
Are the same AV rules in force for 2008R2as your other platforms? Is realtime protection applied to ADMIN$ on the 2008 whereas it's excluded in the others? An AV policy could whack the files that PDQ copies to ADMIN$ during the installation. That normally results in a 1603 error, though.
I would copy all the files for the install to a 2008R2 server and try installing via command line (using the same credentials in PDQ). See if an error is returned that way too. That might help pinpoint. If you are deploying an MSI you can enable logging which could help determine.
-
If you mean Deploy, it is 2.3.2.0. If you mean what am I trying to install, some specific examples are Adobe Reader XI (11.0.03) & Adobe Flash 11.7.700.224. Interestingly, 7-Zip seems to have worked fine through PDQ. Weird. Based on that, I just sent Java 7 Update 25 to a server as a test and it worked fine too. Incidentally, I am using packages downloaded from the PDQ library.
-
Let's turn on logging. Please choose one of the packages that uses an MSI and follow these steps. Please review the log file to see if anything jumps out.
-
I've been trying some other tests and it now appears that perhaps its the pull operation that is failing. I tried deploying MS office 2003 to one of the affected servers. I picked this because it would need a couple of minutes to actually pull the files to the server. I then monitored the contents of the PDQDeployRunner folder to see what happened and also watched the steps and status on the PDQDeploy console. I see all the various PDQ folders get created on the target but nothing ever actually gets deposited into the exec folder. Also, the copy process should take a couple of minutes as I said but it is completed almost instantly and then kicks off the install process. This of course will fail because the install files aren't actually on the target server. So that seems to be the issue, I just don't know why the Pull fails to copy any files but yet seems to have been successful as far as PDQDeploy is concerned. At this point, it doesn't seem to be an issue with the installer itself.
-
I would also check the security event log on the computer the deployment task is running from.
For me this looks like some issue where the deployment task is unable to connect to the deployment share.
Please create and share a test folder. Set the permissions on share to everyone/ReadWrite and the folder security everyone/Read. Then place the depploment package into this folder and point the deployment task to it. It should automatically find the right path. (i.e. \\server\share\deploy\package.msi)
-
Hi SelfMan. I testing things out as you suggested but I get the same results. Nothing actually gets copied over to the target. I have also logged into one of the affected servers as the account that PDQ uses to do the install and tried accessing the share and I have no issues doing so. The account also has full control over the files in the share. Also, I see nothing of use from the security logs.
-
Very odd that it's not consistent. Please let us know if you see any differences that can help us. Obviously while we look into this please use the push method on those failed systems. Because we are bumping up against the Independence Day holiday we may not get an answer as quickly as normal, but we are not putting it on the back burner.
-
Ok, lets do it the hardcore way... get ProcessMonitor from sysinternals.http://download.sysinternals.com/files/ProcessMonitor.zip
Unzip and run with admin privileges. Stop the monitoring, clear the log. Prepare deployment, Start logging and deployment task.
When the deployment finishes (error or not) stop the monitoring. Locate (CTRL+F) PDQ service and filter using context menu - include PDQ...
Then check for access denied
-
Yeah, its a weird one. Its inconsistent in that not every 2008 R2 server is affected. But it is consistent in that every package I try on an affected 2008 R2 server never works. I cant really see any differences that stand out. My first thought was along the lines of the Repository is referenced by using DFS and some of the affected servers are Name Space servers for that DFS and perhaps they were unable to "talk to themselves". However, some of the 2008 R2 servers that are working are also Name Space servers so it cant be that. Also, one of the affected servers is my Exchange 2010 server which has nothing to do with DFS at all. Would there be a way to turn on some logging on the target side to see at what point things go belly up?
-
PDQ runner creates this folder and runs all the stuff from it. What I see in the log that it cant locate the files.
Its looking for C:\Windows\PDQDeployRunner\1\AdbeRdr11003_en_US.exe but gets a "NAME NOT FOUND" error. Then it goes trough all paths from PATH variable and tries to locate the installation package.
C:\Windows\PDQDeployRunner\1 folder when the deployment is running and check the debux.txt
What I could not locate in the PML log is the copy process of the files. There is no network path in the log.
What I could see in the stacl is the Ofant.sys driver from ARCserve backup. I am just wondering if there might be conflict with it. -
While I would love to be able to read the debug.txt, it disappears well before I can open up. It is created (as is the other folders and files needed for the process) but then is deleted very quickly afterward.
I too was looking for something about the copy process and was surprised not to see anything about it.
Other servers that work fine also have an Arcserve agent installed so I don't think this is the issue.
-
After further analysys, there are no errors/failures, access denied information. Still there would/should be errors, but there are none. The copy process checks for the file existance and should copy the file to the verified location. In this case nothing happens. The only thing I can imagine now is that the .NET framework on the system has some problems.
-
Apologies for coming late to the game, but there is some additional logging that we can do however it will require that we build a special debug version. The logging that is there now will happen if the pull copy encounters an error, but for some reason the file copy API (CopyFileEx) is returning error code 0 (ERROR_SUCCESS) but not actually copying the file. Since it appears to succeed the logging information is not retained.
A few remote possibilities stand out, but none of them seem very likely. Additional logging details about the environment on the system would give us a better understanding of what's going on. Hopefully we can have something for you early next week (reduced staff for the Independence Day holiday and travel for myself will dictate).
Please sign in to leave a comment.
Comments
30 comments