I am not sure if I got your requirements correctly. but I need to get things clear, do you try capture an image with agent? Or you want to deploy an agent during the image deployment?
I would suggest adding a step (task) within the image deployment template to install the agent. (It can be added after joining the device to the domain for example).
I'm talking about installing the agent in the image before capture.
I have not tested this in many years, but I've been asked to find ways of speeding up image deployment in our environment due to sheer volume. On some of our hardware the agent install with full inventory scan (may adjust this as well) takes almost 10 minutes. Agent is pretty standard (no AV or EPS) and we use a self-exe install from preferred server.
We now use one agent configuration during provisioning with no schedules or power management enabled, then use "Change Agent Settings" to configure the agent as needed based on the prov template used. With this setup, it makes perfect sense to me to bake the agent into the image and configure after the fact, but as I said I haven't tested in a while. I'm looking for anyone who is currently doing this to shed some light and let me know if it's working for them.
Personally, I'd always AGAINST baking the LDMS agent into an image. Have done for 10+ years, and the arguments are still valid.
1 - Images have a funny way of "being forgotten about" and all of a sudden, you're dealing with a 3+ year old image which has a 3+ year old LD agent on it, which (especially with the current security enhancement pace) may in fact not be able to communicate with the Core.
2 - The agent-install (as of 2016) creates a unique client-side cert to register with the Core (something you want to KEEP unique) ...
3 - Then there's the Unique Device ID's (in the HKLM registry, maybe other locations in the future) ...
... overall, since it's *SO* simple to just include a "go to this location and download this file" command in the imaging process (be it provisioning or something else) -- which can be a DFS'ed / DNS-alias'ed share to a common name such as -- http://MyFileShare.domain.com/MyDIrectory/MyLANDeskAgent.exe -- all you need to worry about is just replacing that agent file with "your freshest one" and that makes life easier.
It's ALWAYS (so far) been a thing that bit people in the behind (in my experience) in hard-coding an agent into the image. (Another complicating is when you switch the Core & so on ... DNS-aliasing is getting rather more complicated with higher levels of SSL certs being used, for instance).
Fun fun fun .
So - my advice ... please don't do it. Your sanity will thank you.
Thanks for the response, and trust me I hear you (11 years and counting with LDMS).
If the agent wasn't so bulky and didn't take several minutes to install this would be a non-issue. I know that sounds like small potatoes, but 5 minutes x 35,000 devices...... We're not doing one at a time, but still. There's constant pressure to speed things up, and as a school system we lose parts of the summer due to construction/painting/carpeting/etc. I'm always on the lookout for ways to improve imaging efficiency.
Our images tend to stay static for the school year with all additional config happening outside the image. We tend to coincide LDMS upgrades with our summer reimage where possible rather than doing agent upgrades/deployments during the year.
I asked this question at Interchange in an agent seminar and was specifically told this could/should be done. Maybe it was the wrong forum to ask the question, but Power Management as an agent setting was the last reason I had not to have a consolidated workstation agent.
This exercise may be for nothing, but I'm testing now to see if it's worth the potential headaches.
1 of 1 people found this helpful
And it *CAN* be done ... just the list of things to keep track of (which - again - have a funny way of being forgotten & causing massive hunting-down effort a few years down the line) tends to get longer, especially with the security enhancements that keep coming in.
In that case ...
You definitely SHOULD (ideally) still remove the HKLM registry keys before you do the final shutdown for the image (so that the client generates a new set upon boot up).
CTOS ... no "magic bullet"-s from me here. A lot depends on how you do things / your environment.
It's a little bit, but I understand wanting to give this a go. Understand your reasons. Worth a try ... just - don't forget to keep track of those changes .
Thanks. I think the only thing I'm fuzzy on is the cert-based security. Not sure where to go to "generalize" the agent in that respect so I can generate a new request post imaging.
I'd probably poke support.
The agent-cert creation process is one thing I've not reverse engineered / dug into myself yet, so can't help there.
Giving support a call about this should be fine (feel free to share the info here) ... I *suspect* it'll end up a bit of a "hack-y" solution for that, but ... will see .
You still *shouldn't* install the agent in the image itself, if you do there are some reg keys that should be deleted prior to capture, but don't be surprised if you end up with DB or machine instance issues down the line...
This is an old reply (and doesn't help the speed) but I'm installing my Agent after first login using runonce registry.