The thing that uniquely identifies machines in the LANDesk database is the Global Unique Identifier (GUID). It is stored in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk\Common Api\UniqueID and HKEY_LOCAL_MACHINE\SOFTWARE\Intel\LANDesk\Common Api. If you delete those, and reboot, they are automatically regenerated.
There are several drawbacks to "baking" in the image, including it is set at that specific version that you install, and will need to upgrade them later if you upgrade your Core server.
That will take care of the LANDesk side, but having duplicate SIDS is a seperate issue regarding windows.
While you can hack the image to include the client, you should NOT do this because you will be happier in the long run if you do not do it.
If you use OS Deployment correctly, you wouldn't want or need to put the agent on the image.
I have yet to find anyone with a valid use case for putting the agent on an image. Even if you are using a separate imaging tool, you can still use our GUIRunOnce commands to install the agent.
If you think you have a good use case for putting the agent on the image, please post it.
Long time huh....
Not sure what you guys are currently doing, but if Security is still using SMS and/or the other patch util (I forget what it was called), you might be able to create a custom job there, to detect when the PC does not have it, and add it.
As part of the image, have a run once pointed to the network share of the agent (advanced agent of course).
Not sure if either of these would help.
Any more SW distro's being created?
Another solution is to use a GPO (if Active Directory exists ) to start a installation script or the use of loginscript if the users have admin rights (brrr... not a good way )
We use a script which is started by GPO for the automatic deployment:
If the installation is finished the client will be moved in the correct OU (site specific).
The client get the GPO and start the script.
After installation and the first scans the download of the patches starts...
What rhous said (I'm sure I've ranted about this before as well, but his post already says all that needs saying). Concensus is that YES, it can be done (if you're careful) but it's generally not worth it, and it's not that tricky to include an automated agent-installation as part of the imaging process :).
LANDesk EMEA Technical Lead.
but if you have more than one agent configuration you need more than one image :-)...
It's more flexible to start installation of the agent after imaging in dependency of some other criterias (computername, site of computer, OU, the weather or something else... )
If you can use LANDesk provisioning you can do it there (I've learned yesterday...), but if your clients will be installed by an external company (like DELL) it is better to install it with scripts later...
It's not a problem if you do it as part of users/organisation's login scripts.
It's all down to the detail of how environment X is working, how many configrations are needed, and so on. Hence there's no "blanket statement" answer, only general guidelines, and the general recommendation we do is that it's better NOT to include the agent.
It's not always possible, and we know that, but it doesn't change the fact that it's the best way to go for MOST people :).
LANDesk EMEA Techical Lead.
To dig thhis thread out of the relict box:
Is there a way also with LDMS9?
Because from my Experience that did not help, because the UniqueID seems also to be stored in:
And I also deleted that DB + both reg keys, it looks like after the first reboot the old key is restored from somewhere.
So is there a way to put the client in the image?
Nobody has a clue?
Another work around would be to include the self contained .exe of the client in the image (or have it copied after deployment) - and set up the GuiRunOnce to run the install.
I was thinking the same thing as LewisE in using the runonce key. You can do this in your sysprep easily. If your using LANDesk to provision, you can do this in your provisioning template.
Basically, you really don't want an agent in your image. Trying to make it work will always leave doubt if problems you are seeing in the future are because of it. And if you plan to go back to LANDesk for help, you might find it a lot harder to get support.
FYI, most agent/server based applications have the same policy on this topic.
There is an image.
There is an imaging process.
Whenever a device gets images, the imaging process lays down the image and does other work.
The agent should not be included in the image, but instead in the imaging process.
I have a scenario that I would like your opinion on. I have read your post http://community.landesk.com/support/message/2422 where you talk about how to put the agent on the "image" but I know "you should NOT do this because you will be happier in the long run if you do not do it". Here is what I am faced with. We are using Vmware View (linked clones) for our desktops. The way that this works is that there is a "base" virtual machine we take a snapshot of the base it will then create multiple virtual machines from that snapshot. If we ever need to update the base image we do a recompose and it deletes all of the workstations and recreates them. It doesn't run sysprep however it does rename all of the VMs. The whole process takes maybe 15 minutes. I would like to have the agent on the base image to keep the base up to date. My settings are currently Remove duplicate when MAC addresses match, Device Name Match (not both device names and MAC addresses match) unchecked Restore old Device IDs. Device IDs I have Identity Attributes Computer.Network.NIC.Address; Computer.Network.TCPIP.HostName, Log as a duplicate Device ID when 1 Identity Attributes Change, Reject duplicate Identities.
The reason I want the agent on the base image is that when I run a full security/compliance scan on a VM it could take about 4 hours or more to complete and I don't want to have to do that on every VM every time I recompose. I would like to 15 minutes it takes to recompose a VM to be the only step I don't want to have to follow it up with an agent install and then a scann because we do these recompose often.
I hope that this is all clear and I would appreciate any advice/guidance you have.
How frequently when you say you do this often? The benefit of using something like VMView is that the base image can be used to update the other machines keyed off it. If you are in a situation where they are rebuilt often enough then perhaps your process should simply be to do your patching within your base image and not include vulnerability scanning in your clients?
I work with a similar system for distributed virtual desktops http://nxtop.marxtar.co.uk and it pretty much removes the need to do anything like that on the client. Does it offer any kind of capability to merge certain components of the child builds with the recreated base, by this I mean can you have it protect the registry and certain file areas that contain unique identifiers? I'm not familiar with VMView but I can do that with NxTop so that the builds can be managed by LANDesk agents without needing redeploying each time it gets updated.