FriendsOfMDT
Ansible Tooling
Hello,
I've been developing some Ansible tooling for interacting with MDT and this project has been on my radar. I had some questions about this project. I didn't see a more appropriate place to post this, so please excuse my ignorance if there is somewhere better for me to ask these questions.
- Are any changes made to the object structure of Applications, Drivers, Packages, Selection Profiles, Task Sequences, etc. in PowerShell (Microsoft.BDD.PSSnapIn.MDTObject typed objects)? If so, are those documented somewhere, so I can adapt my tooling to respect those changes?
- Are any changes made to the structure of task sequences? If so, are those documented somewhere? I have not implemented tooling to edit task sequence content yet, but I plan to do so in the future and it would be helpful if I could accommodate your changes into my implementation.
I appreciate the work that has been done on this project! If there is any Ansible tooling that I could develop that would be helpful during the development process, please let me know and I'll see what I can do to help.
I would also be interested in anything Ansible as I am deploying the OS with PSD and handing it off to ansible / Semaphore UI via API call to finish any other configurations.
@trippsc2 I am primarily a UI developer on this project, but I need a good understanding of how it works, so I can answer these questions:
-
The original MDT structure remains unchanged— all XML, schema, and folder structures are the same. The most significant modification is the replacement of VBS/WSF scripts with PowerShell (PS1) scripts, all within the "Scripts" folder. Additionally, we introduced new modules within the Tools\Module folder and a "PSDResources" folder for custom configurations. We also provided new task sequence templates that must be used.
-
The task sequence structure has changed in terms of execution steps, but the generated XML schema remains unchanged. There is no in-depth documentation on PSD’s internal operations beyond what is mentioned and what you can see in the code itself. PSD still relies on the MDT engine and workbench. When a new task sequence is created using our template, the XML is still populated with the original VBS/WSF script references. However, when content is downloaded to a device, PSD dynamically updates these file paths in the TS.xml, replacing them with corresponding PowerShell scripts. This is not a simple 1:1 replacement, which is why the default task sequence steps have been reduced. Using an original MDT task sequence with PSD will result in failure.
Regarding Ansible, I am unsure of its specific capabilities in this context. However, there has been work on integrating RestPS, which enables API-based operations outside of the task sequence. More details can be found here: RestPS Guide with PSD.
Let me know if further clarification is needed!
Thank you. Your answers to my questions are helpful. It doesn't sound like much needs to be adapted in this case.
Please pardon me if I'm telling you things you already know. Ansible is used for configuration management. There are constructs in Ansible called "roles" that are effectively a series of tasks to perform to ensure a configuration result.
What I was thinking is writing one or more roles to ensure that PSD components are installed. This would allow the team to quickly create a new environment for testing and ensure that the installation steps produce the expected deployment share changes.
I would only want to do this if either:
- The development team sees benefit in it.
- The installation process is not subject to much change, so these roles would not have a high maintenance burden.