You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there, thanks for maintaining these scripts! This is a suggestion for how they could better accommodate reuse.
At the moment, the project encourages folks to make local modifications to Autounattend.xml files according to their needs (e.g. inserting a product key, disabling Windows updates, and defining the computer name). This approach is clearly serviceable for consumers, but it has a couple drawbacks. Local modifications have the potential to conflict with future revisions, complicating the task of keeping up-to-date. In the specific case of product license keys, teams of consumers will be hard-pressed to share their code with each other (even those who fork this work to a private repository will likely be reluctant to commit sensitive information to their project's revision history).
Oh I didn't follow the latest features in Packer (I only blindly updated the chocolatey package for it 😅), but this sounds very promising. Yes that static Autounattend.xml is really a bit annoying and I would be interested in having this more flexible to enter variables for maybe the user's password and the product key.
Yes, requiring Packer 1.7.1+ for these templates isn't a problem.
Hi there, thanks for maintaining these scripts! This is a suggestion for how they could better accommodate reuse.
At the moment, the project encourages folks to make local modifications to
Autounattend.xml
files according to their needs (e.g. inserting a product key, disabling Windows updates, and defining the computer name). This approach is clearly serviceable for consumers, but it has a couple drawbacks. Local modifications have the potential to conflict with future revisions, complicating the task of keeping up-to-date. In the specific case of product license keys, teams of consumers will be hard-pressed to share their code with each other (even those who fork this work to a private repository will likely be reluctant to commit sensitive information to their project's revision history).Fortunately, newer releases of Packer are able to interpret external files as templates. If this project adopts that feature (by rewriting the Packer configuration files to HCL2 and generalizing the
Autounattend.xml
files), then the files provided to Windows could be dynamically generated according to user input.The relevant Packer feature was implemented in Packer 1.7.1, released on 2021-03-31. Depending on this project's compatibility commitments, it might not be possible to make the change right now. That said, if this does sound desirable, I could get things started by implementing the change for Windows 10.
Thanks again!
The text was updated successfully, but these errors were encountered: