Abnrangerx67

So far got this work (outside of the TS in regards to the GuI popping up and all the controls doing what it needs to do. Next step is seeing how it works in the TS itself. I added things like domain join, auto generating computer names if a custom one is not typed in the textbox, etc. Only challenge and not a big deal, is getting the image show after the import. I tried the base64 approach but no bueno. I will provide an update and share my challenges and workarounds. One key tip if not already figured out, make sure and put your GUI/frontend step AFTER the drive partitioning step if using this as a package.

HI, love it so far, and would be giving it try. We currently use the UDI from MDT, and with MDT going away, it is time for something new. In the interim, I built a new package using the scripts from MDT, then I download the package to a central location on the device during OSD, then just use command line steps to run the same commands to the scripts that MDT was using. So far works great, but, now that VB scripts are being deprecated, time for another switch, ugh. Which put me on the search and to your option. I am mediocre when it comes to programming, but I was able to leverage PowerShell script to handle some of the logic such as if the tech checked the box for LTSC, then another GUI would show, but only gave the option to image a specific device type based on its function. I will try and incorporate some of what I have into yours and see how it goes. One other thing I do is use a device name generator built with PowerShell that pulls the last 5 of the serial, then appends based on the location the device belongs to, it also checks AD to make sure device does not already exist. I have built some WPF with PowerShell, so I understand some of the coding. I just downloaded VSCode, so I taking the plunge to learn this on the fly. I hope I can ping you for ideas or solutions. Thanks

Hi, thanks for this tutorial. If users click cancel, does the process fail or proceed as normal? More than likely, the only persons that will use the hidden ones are my team, which means no one else will know the deployment id.

Understood, but with two different boot images, one with and without the startup command, how is that controlled in terms of which one comes down when imaging is initiated? Unless the idea is that one boot image can be used even with the startup command, but bypassed if the deploymentID is not input, then the process continues to the ones not hidden. Also, can the x64 boot image be used? I noticed in your tutorial you used the x86, not sure if that is a requirement or just your choice at that time. Thanks again for your response.

I gave this a try but it did not work. Not sure if it is because I used the x64. However, it did raise a concern that I was afraid would happen. When I PXE booted, the correct WIM did come down, but as mentioned in my other post, what if this was someone else and they wanted to access the visible TSes? Aside from assigning to a known collection, how do you use this on the unknown computers collection for baremetal imaging while still using the other normal boot images for traditional imaging?

Apologies, so with the boot image in place and used by our main TS. how would have an additional boot image for the hidden TS work or affect the unknown computers collection when it is time for OSD? My concern or wonder is what happens when a new/BareMetal computer is PXE booted, how is the "correct" boot image selected to be presented for the correct imaging process?

Great post, thanks will give this a try because now that we are deploying win11, but want to keep a win10 ts but have it restricted to "as requested". By hiding it, a ticket would need to be submitted and the deployment ID provided. Is there a way to use another form of "id" that we can rotate let's say monthly? Maybe overkill, but just trying to find a way to keep this as restricted as possible, because I suspect someone will get wise and know the deployment ID is not changing so they won't ask for it anymore. Now that I think of it, maybe we can just create a new deployment every month so the ID get changed. I will see how that works, but definitely open to some ideas.