Version 4 is quite new, and I’m still experimenting with it to fully understand how it works. It’s possible that I might have missed the information…
To put it simply, I want to change the log file path as well as the log file name (and a few other things related to MSI switches and probably some more parameters in the future)
As in v3, theses infos are stored in a config file, this time it’s a signed PSD1 file. Since altering the file breaks the authenticode sig, how are we supposed to change the parameters without having our own authenticode signature chain to resign the code after making the changes ?
If your environment doesn’t require that this file is signed you won’t have an issue with modifying it and breaking the signing.
If your environment requires signing of this file you would need to re-sign it yourself after modifying it. And if you are in this situation you need to have a (secure) code-signing solution in place.
Well, this has nothing to do with my env : there is a blocking function inside the template itself that checks all the files for a valid signature and exit the template if “badfiles” are found.
By reading the release notes, i saw that there is a way to override the config parameters by setting registry keys, i suppose using GPOs (ADMX mentioned)
Hey there! I’m Mitch, one of the new developers on the project.
What you’re supposed to do is after importing the module, run New-ADTTemplate and have it output a new deployment template for you to use. We currently also provide pre-generated templates on our GitHub releases page.
The scaffolded template will have duplicated config/strings folders that are for you to customise as required. We put strict measures on the module for the security of our users to ensure our signed module isn’t tampered with in any way, including modifying the module’s default config/strings.
If you modify the module in any way, meaning you need to import it while you’ve got PowerShell ExecutionPolicy bypassed, etc, you’d then be able to modify the module’s default/built-in config/strings as you’re “on your own” at that point.
If you’re needing to customise the module in a private fork, doing this against the release build with its monolithic 23,000 line .psm1 file would be a bad idea. Our repo should be forked and your changes committed to your fork so that you can easily merge in our changes/fixes/improvements.
In v3 prior, I modified the config xml to remove the psadt name from logs and notifications and to write verbose logs to one location for deployments (.msi etc) as default to help our desks troubleshoot.
From what I am reading, if i have amended the config psd1 file, this will break the downloaded template I have?
I never got an official answer but I suspect you can provided you do not have ExecutionPolicy enabled (e.g. RemoteSigned or Bypass, etc.), you can do what you want.