MSI Error 1619. Different Cause?

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.

Hi Shawn,

AV rules are the same across the board.  Just tried copying the files locally and ran with command line and that worked fine.

What's the app and version?

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.

Are you able to do a push deployment on these systems? If so then this will let us know a little more about where the failure lies.

Yes, push appears to work.  I set the same Office 2003 install to push and tried again and I can see the files being copied over to the server.

We're checking the code now to see if we're missing error codes on a pull to that OS. Will you please check your event log to see if there are any errors (file copy errors, etc.) that we may have missed?

There doesn't appear to be any errors in the log.  It also looks like it isn't every 2008 R2 server either.  A couple work fine with the Pull method. 

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?

And of course, you can also zip and attach the filtered log for further analysis.

Here is what it captured when filtered for PDQDeployRunner.exe as the process name.

And just for further information, I have tried turning off real time protection for my AV and have also added the PDQDeployRunner folder to the exclusion list.  No luck.

Ok, locate C:\Windows\PDQDeployRunner foder and remove it completely. Try a new deployment and let me know.

Oh and if there is the debug.txt, move it first C:\Windows\PDQDeployRunner\1\debug.txt

Ok, deleted the folder and still the same result.  By the way, there is nothing in the folder at all.

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.

I've done a trace on my server and the copy proces is there. Why it does not happen on your server is very strange.

The events from the debug log should be stored in the event log.

Do the trace again and create a filter by path containg the AdbeRdr11003_en_US.exe file so we have all event in the list.

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.

So I ran another trace and the only time the executable for the install is referenced is when the PDQ is looking for it.  There is no indication anywhere that it has actually tried to download the file to the target system.

Yep, thats my conclusion. Now its just the question why does it happen, but that one has to be answered by AA team.

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).