You wish to utilize the Central Server feature in PDQ Deploy version 13 and higher (requires an Enterprise license) in an established PDQ Deploy environment that may contain custom packages.
If you export/import schedules that have targets using PDQ Inventory collections the targets will need to be manually re-associated to their original configuration within the imported schedule. Schedules use a target ID to refer to PDQ Inventory collections that, when migrated, can be incorrectly associated with alternate target collections. (We use a target ID so that if the name of a collection changes, the target collection is still valid).
While the instructions contained in Configuring Central Server are for new installations of PDQ Deploy (version 13 or higher), there may be situations where PDQ Deploy is updated from versions prior to 13. In those cases and where the PDQ Deploy console will be operating in Client Mode, it may be necessary to export/import packages from previous versions or Local Mode prior to configuring an existing PDQ Deploy console to Client Mode.
- As install files and script references in the packages might exist in several locations, check the packages to see where any files are stored. You should consider moving all locally-stored install files and scripts to the Repository (path can be found in Preferences > Repository or Options > Preferences > Repository or Ctrl+comma) prior to exporting the packages. The default location for the Repository is %PUBLIC%\Documents\Admin Arsenal\PDQ Deploy\Repository. Instructions for organizing your file paths (especially utilizing the ($Repository) variable), can be found at the end of this document.
- These instructions intentionally leave out the exporting and importing of schedules due to the warning in the Purpose statement of this document. If you do export/import schedules, be aware imported schedules will likely need to be manually reconfigured to ensure the appropriate packages are set up to be deployed to the expected targets. Failure to do so may have unintended consequences, such as the wrong package being deployed to the wrong targets at the wrong time.
To export/import from a PDQ Deploy console that will be converted to Client Mode, perform the following (this assumes all package files and scripts are stored in the local repository):
1. In the main console of a PDQ Deploy console running in Local Mode, select one, some, or all packages. You can also just select the entire package folder. Right-click the selection and click Export from the context menu.
Or to select the Package folder:
2. Save the XML file in a location accessible by the PDQ Deploy console in Server Mode (e.g. a UNC share) or to external media. TIP: If you have admin access to the PDQ Deploy console that will be converted to Client Mode, you can access the C$ of the potential client from the server console of PDQ Deploy.
3. Navigate to the location of the Repository on the computer that will be converted to Client Mode.
4. Place any repository files referenced by the packages you exported in the same UNC share or external media (or access the C$ from the PDQ Deploy server console). See the note at the end of this section for more information.
5. Login to the PDQ server console and transfer the files from the Repository into the server's repository using any method outlined in step 4 above.
6. On the PDQ Deploy console in Server Mode, open File > Import (or Ctrl+I), navigate to the saved XML file from step 2 and import the XML.
7. The packages will then be imported to the Server’s package list in the navigation tree and reference the files you moved into the server's Repository, assuming they are in the correct location. All Client consoles will then have access to those packages.
8. Proceed to configure Client Mode on the PDQ Deploy console designated to be the client.
If a PDQ console in Client Mode needs access to any packages that exist on their local repository, it can be switched back to Local Mode, which will only use the original/local Repository and database for the Local Mode console.
If the file paths for your files are in disarray or otherwise not neat and tidy, you can clean that up with a little PowerShell magic and SQLite. Please see this blog post, Using PowerShell and SQLite to Update Package File Paths.
Additionally, you can use this SQL command (from the SQLIte3 prompt):
update InstallSteps set FileName = '[new path]' || substr(filename, length('[old path]') + 1) where FileName like '[old path]' || '%';
update InstallSteps set FileName = '\\Server\NewShare' || substr(filename, length('\\Server\OldShare') + 1) where FileName like '\\Server\OldShare' || '%';
If you have additional files listed in your packages that are not saved in your repository, you can use the following SQL command to change that (changing the paths as appropriate using the same method outlined above):
update InstallSteps set Files = (select Files from (
select PackageStepId, group_concat(part, x'0a') as Files from (
WITH RECURSIVE cte(PackageStepId, part, rest, pos) AS (
select PackageStepId, '', Files || x'0a', 0 from InstallSteps
SUBSTR(rest, 1, INSTR(rest, x'0a') - 1),
SUBSTR(rest, INSTR(rest, x'0a') + 1),
pos + INSTR(rest, x'0a') + 1
WHERE INSTR(rest, x'0a') > 0
case when part like '[old path]' || '%'
then '[new path]' || substr(part, length('[old path]') + 1)
else part end as part
WHERE pos <> 0)
group by PackageStepId)
where PackageStepId = InstallSteps.PackageStepId);