Hello all,
We just started using PSADT to deploy applications through SCCM, so my knowledge about the tool isn’t the best yet.
The question I have is: Can we deploy multiple applications but have only 1 copy of the main files (this for having only 1 AppDeployToolkitExtensions.ps1 etc, without having multiple copies of these files.
Don’t know if this has been asked before but I couldn’t find it yet.
So basically what we want is:
Have a root directory with the “main” files:
And each app having their own Deploy-Application.ps1 while they include above “main” files
This would make upgrading the app easier (not having to replace the “main” files in 100+ deployed apps) and 1 place to maintain all our own functions (AppDeployToolkitExtensions.ps1) would be a lot easier.
Hope you understand what I mean, English is not my native language.
Another screenshot for “main” files structure:
Each app having their own files but referring to the “main” files:
Sorry I couldn’t add more than 1 picture per post, hope this doesn’t make the question more difficult.
This idea is brought up all the time.
long story short: DON’T DO IT!
- SCCM already dedupes files on the DPs.
- These files DO change at times. If they were centralized and a bad change would happen, ALL packages would break at the time.
- When you make changes, you’ll need to test if the change breaks anything… in ALL Packages!
- DON’T DO IT!
2 Likes
Hello @That-Annoying-Guy,
Thank you for your answer!
I can definitely feel you there, but maintaining hundreds of applications deployed with PSADT doesn’t make it much easier does it?
Doing the what you want EXPONENTIALLY creates work b/c you’ll need to test more and more apps if you make a change.
The single copy becomes a single point of failure.
This is a divide and conquer thing. Each pkg is self-contained and KNOWN GOOD!
I understand you, but we would only add additional functions inside AppDeployToolkitExtensions.ps1, where function a { would only be used by application A.
So when there’s something wrong with that function, it would only break application A, right?
For now, Yes.
It seems it not going to convince you to not shoot your foot off and my 20+ years of Application packaging and distribution are useless to you.
Please proceed and report back.
I never hear back from people who HAVE gone down this One Copy rabbit hole.
2 Likes
No I’m sorry if I gave you the feeling I don’t appreciate your answers, because I truly do!!
I was just looking for an easy way to manage all our own written functions AND not having to update 100+ packages when an PSADT update is available.
I will not proceed with the idea so I will not report back 
GOOD!
BTW: My AppDeployToolkitExtensions.ps1 is copied to all packages in-case need them.
I add more and more as I see fit. It’s now about the same size as the Main PS1.
That was my alternative indeed, just copy it over to other applications.
How are you handling PSADT updates?
Also copy the new files over to your applications?
If they are deployed in PROD and working fine… HELL NO!
Stuff in development… sure.
Great, thank you for your answers!
While we’re at it, is there any way to set the logging location instead of having to edit the settings xml file?
For the filename I have $logName = ‘LOGNAME.log’ in the Deploy-Application.ps1 and that works great, but I can’t find out if this is possible to set the directory where I want to have the logs.
Sorry for asking stupid questions.
MSI log or PSADT script Log?
Any log location really, but PSADT would be nice.
If you try to change the logging location from inside Deploy-Application.ps1, you’ll end up with 2 log files.
Edit the XML.
Logging in native PSADT is lacking but you can use a temporary logging folder and then let it merge all the log files into one ZIP file. I modified PSADT to merge mine into one log file instead.
1 Like
Okay thank you.
Thought it could be as simple as the filename with $logName.
logging starts in the main PS1. that’s why you’ll have 2 log files for PSADT.
1 Like