I have seen other users accomplish this with their own custom Powershell or VBScript, but I do not know how they made sure it popped up where the user would see it. As of LDMS 2016, the Windows 10 version of WinPE also supports .NET programs, giving you another method to pop-up a prompt to gather the information. If anyone has an example they could post that would be great.
"Possible" - yes ... the problem usually lies in making sure that the custom data will survive. "Best" way for that is usually to make sure that said custom data gets injected into the OS image at the same time.
Here's the problem in a nutshell.
- You (somehow) send custom data while in WinPE.
- Data gets applied to the device - so far so good.
- Provisioning finishes up ... and you install the full agent.
- In its Windows "full scan", the device does NOT send the custom data (since it's not included in the OS) ... and thus it gets deleted on the Core since "hey, this is no longer part of the device".
... so that's why I strongly advise / suggest to make sure that the custom data is "on the finished device" as well. This also protects against "doh!" moments (if someone deletes the device entry you're not facing a "it's all gone" situation).
That out of the way, here's a few pointers on the "how" side of things.
- First up, basic sending of impromptu custom data can be done via miniscan (or "ldiscn32 /mini" these days) as per here -- Sending Custom Data with a Miniscan (if you're on 9.6 or newer, you shouldn't have a "miniscan.exe" - LDISCN32 has that function incorporated now).
- You can also use data files (especially once the OS is "fully loaded") that get read out automatically (using the LDISCNHLP.INI). Steps on how to do that can be found here -- How to extend the Inventory Scanner capabilities .
... the rest is "up to you" by and large. Use Powershell if you want, or whatnot. Personal preference. The above should give you the information & tools needed to get this to work I hope .
Thank you both for your input! I'll review the document and see if we can write the answer to the local machine. Sounds like we should trigger a .Net prompter and write out the answer to a file to be consumed later by our scripts.