🤘 7 reputation



Joined: 4/26/2018

Last seen: 2/28/2019

  • To add to what Robert wrote, we have been monitoring, evaluating, and shaking our fists at these behavioral problems (the agent's therapist says it's an adjustment disorder -problematic, but shouldn't require institutionalization). The general release of the PDQ Inventory Agent resulted in extreme stress to our existing infrastructure, with the agent itself performing below our standards. Frankly, we weren't prepared for just how popular and widely-used it would be by y'all (think Sally Field's 1984 Oscar speech).

    As such we are reverting the PDQ Inventory Agent back into beta status, which will hopefully reduce the mass adoption rate (not ready for production and all that) while we make some fundamental changes to the architecture and costs associated. We don't have a timeline on when these changes will be completed, but we're going to be thorough. The agent will still be available for non-prod consumption and for your testing pleasure.

  • One thing to keep in mind: a heartbeat may not always capture a reboot depending on the heartbeat interval. For heartbeat to work, a state change must be recognized, meaning the machine has to be marked as offline in the database and then come back online.

    Let's say you have a heartbeat interval set to every five minutes or 300 seconds. We send out a heartbeat at 5:10pm and the machine is marked as online. At 5:11pm the machine restarts. The machine comes back online at 5:14pm. Another heartbeat is sent at 5:15pm and the machine status remains unchanged (online) since the heartbeat never had the opportunity to mark the machine as offline. In this case, the heartbeat trigger would not be initiated even though the machine did reboot.

  • The deployment for XD had initially failed on the webcast machine with the 1603 error. I ran the test again on a Win 7, 8, and 4 Windows 10 versions and all MSI installs received the 1603 error, even on machines that were fresh and sparkly new from the VM-maker machine.

    Using the setup.exe, I was able to get the error code 6 on three of the six deployments (the other three succeeded). I did change the Package "Run As" option to Deploy User (interactive) rather than the standard Deploy User. On the three machines that had that exit code, I deleted the Program Files/Adobe directory and tried again and got the same result.

    I then ensured the machines were updated and rebooted those machines. Upon deploying, I had the same result. All three machines still failed with the error code 6.

    So, I tried running the install from the command line using the setup.exe and a network share to the installer. Basically, this reproduces the setup exactly as Deploy would perform it but from an elevated command prompt within the target OS. This also failed with the same error code 6.

    As a last test, I copied over the installation directory in full over to the failed machines. I then ran the setup.exe --silent from a command prompt locally on one machine, ran the msi command on another, and then manually ran the msi file (double-click method) on the last machine.

    On the one where I ran the setup with the --silent parameter, it failed. On the second where I ran the msi command, it failed with a 1603 error. On the third machine where I ran the msi installer manually, it also failed with the 1603 error.

    The failures occurred on Windows 7, 8.1, and Windows 10 1607. All other Windows 10 versions past 1607 succeeded using the setup.exe. That is curious! I did some checking on why this might be, and indeed, XD will not install on Windows versions older than 1703. https://helpx.adobe.com/xd/system-requirements.html

  • No worries, John. If the issue persists, shoot an email to support@pdq.com and we can go into full-on troubleshooting mode.

  • Perfect. I'm assuming the Deploy User is also a local admin on the machine (otherwise, terrors). I was able to get some to "fail" (the machine needed a reboot) and have Output Logs for those failures. Do you also get those? If so, is the same elevation error presented as the disposition of the attempted update?

    enter image description here

    If it is the same elevation issue, can you deploy some other package that requires elevation to the machine? Since I'll assume that would be successful (but we do want to rule that out), change the credentials (Options > Credentials) in PDQ Deploy to some other account that has local admin privileges on the failed target, set those credentials as default (set them back afterwards, however), then attempt to deploy. Do you get the exact same error?

  • Okay. Would you post a screenshot of the install step from your RUM deployment package, like the one above? Also, a screenshot of the Options tab for the step. It might also have to do with the origin of the RUM. Did you download that from the Adobe admin console for CC or from a machine with Adobe CC products installed?

  • Hi John,

    If you download the RUM from the admin console in Adobe CC, extract the executable, create a package and then deploy that package, what results do you get?

    Here is the package I created: RUM Package

  • Yep, a company that loves, lives, and breathes automation uses automation. That's us.

    More good news, doesn't look like search is terribly broken.

  • For Windows 10, you can do this manually: Windows Defender Security Center > Virus and Threat Protection > Virus & Threat Protection Settings > Exclusions.

    For Windows 10, automatically, you can configure Group Policy to handle exclusions: See the "Exclusions" in the Location column of this article: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-antivirus/use-group-policy-windows-defender-antivirus