Multi site functionality
Hi,
I've been trying to figure out what is the best way of doing multi site deployment with dingle pdq server (so that we have one central pdq deploy server and local fileshares on all sites).
There are few other posts conserning this issue and they offer dfs or host file changes as a solution. I think both of these options are not good and can cause nightmare later on.
What I have figured is to create a fileshare on all sites to store local installation files. Then create a custom variable on pdq to point to that share. e.g. @(MYLOCALRepository) and use that in jobs instead of system default $(Repository) variable.
This seems to work but I was wondering is rhere a way (hack, script whatever) to run to folders in pdq depoy console to change all $(Repository) variables in all jobs in one folder to my @(MYLOCALRepository) so I could organize my pdq console to keep sites separated in their own folders and all jobs on that folder would automatically point to that folder's own repository?
Comments
UPDATE
I think I have found one way of doing this: First I need to create a script that exports all site folders from PDQ Deploy to xml format, then run script that replaces the default $(Repository) variable with @(folderspecificvariable) and then run script that imports those xml's back to PDQ Deploy.
Any comments on that approach?
I understand that you reject the host file changes, but what are your concerns against a DFS share?
It's working great here on 9 sites without any issues at all.
Basically DFS doesn't solve the problem how to manage jobs inside PDQ. DFS can solve file replication issue (or just plain robocopy) but I would like to get that functionality inside PDQ as well so I could have site specific folders in Deploy and all jobs in that folder automatically could point to thats sites local fileshare.
What about:
Put all site specific Folders in the global (DFS) share, copy the steps in the deployment so you have 1 step for each site and use the condition tab (like, only deploy if target ist member of Collection site A, Site B etc.).
That should solve the Problem with site specific steps inside a deployment.
Thats my way with side specific files, registry entrys or Office deployments.
Thats sounds interesting. I have to look into that more. Thanks!