Output logs
When a deployment completes, the results of the deployment will be made available in Output logs. Output logs can assist with troubleshooting errors, gathering information, and verifying the results of individual steps.
Retrieving Output Logs
Deployments of a package (whether to one or multiple devices) are grouped as a single line on the Deployments page, with counts of each of the Deployment statuses indicating how many deployments are (from left to right) Queued, In Progress, Complete, Failed, or Canceled.
To find out more information about a deployment, including the Output Logs, click the number under the relevant status. This will take you to a list of all devices in the deployment which have that status, whether none, one, or multiple.
The pages for Completed (green checkmark, third column) or Failed (red exclamation point, fourth column) will contain a list of deployments with detailed output logs. Alternately, you can click the device count in the Deployed to column to take you to a complete list of device deployments.
To view the complete output logs, click View Output in the Output Logs column.
Partial output logs may also be viewed while a deployment is In Progress (yellow progress half-circle, second column).
Output Log Overview
The output log pop-up window allows you to view the exact execution and output of each step of the deployment, so that you can easily identify any points of failure or unexpected behavior.
In the top bar of the Output log window, you will see the name of the computer as well as the duration and timestamp of the deployment.
You can click Export log to download the entire log as a .txt file, or you can click the copy icon to copy the portion of the output log from a single package step.
You can also search the logs using the text box.
Additional details:
- If a package step is skipped due to a step condition, an explanation of that skip will appear.
Output Log Contents
PDQ Connect relies on the application or script being ran to supply logging that can be passed to the agent as output. Some applications natively create logs during the install process, while others only provide a success code. If the application being deployed does not provide its own logging, there will be no information to pass on to the Connect agent.
In the example below, we have deployed 7-zip using the command msiexec.exe /i "7z2301-x64.msi" /qn. No parameters for logging were defined, so the output window only displays actions performed by the PDQ Connect agent.
In the next example, we have deployed the same .msi file using the modified command msiexec.exe /i "7z2301-x64.msi" ALLUSERS=1 /qn /norestart /log output.log. The /log parameter is used to generate a log file that is automatically passed back to the PDQ Connect agent. As a result, the Output log in PDQ Connect contains more information about the deployment.
Understanding Task IDs
Every deployment in PDQ Connect is assigned a random GUID that uniquely identifies that specific deployment. The GUID can informally be referred to ask the "Task ID." A common reference to the Task ID can be seen in the Errors section of the Output log, where the message "Failed to run task 'dvc_task_{GUID}' may be shown. "Dvc_task_" is the preface for the GUID, indicating that it represents a deployment.
The Task ID will also match the working directory used to download temporary files and run scripts during a deployment. The working directory for any running deployment in PDQ Connect will be C:\ProgramData\PDQ\PDQConnectAgent\Downloads\dvc_task_{GUID}.
Contacting support
The Output Logs are intended to assist with troubleshooting failed deployments, and in many cases, it may be possible to find the cause of a deployment failure.
If you are seeking support assistance with a failed deployment, please be sure to include the entire Output log, as well as any information about the deployment context:
- Have you successfully deployed this package in your environment before?
- Have you successfully deployed any other package in your environment before?
- Is there anything unique about the target device(s) where the deployment failed vs. the devices where it succeeded?
- What result did you expect from the deployment, and what actually occurred?
