Client Management Suite

I've just added my first computer to the CMDB since we upgraded from 7.6 to 7.6 HFA1. The normal procedure would be adding the computer to the predefined computers list, PXE booting the machine and then selecting one of the initial deployment jobs or just dropping a deployment job on to the computer object.

However the computer I have just added has an Agent Health indicator of Untracked. The console reports it is receiving updates from the client, the console shows the IP address and it is pingable.

Has anyone else experienced this? I thought I would ask a quick question here before opening a support ticket.

Howard

Hi,

Please take a look, this could be the same problem: https://www-secure.symantec.com/connect/forums/no-licensed-computers-or-targets-licensed-computers-were-assigned-0

Thank you,

Alex.

I don't think it's a licensing issue.

I was looking at another article in the link above:

https://support.symantec.com/en_US/article.TECH230183.html

It talks about the license check method changing in HF1 and there is a pointfix that will make it into HF2. However I don't get the error listed on that that page, and in fact while following that page and dropping an deployment job to my test machine I was able to deploy an image via Ghost.

The entire job that was scheduled to that machine however, by way of initial deployment, never even appeared in that machines list of jobs. The job in question has the following tasks at the start:

Boot to PXE

Deploy image

Boot to production

Refreshing the console for the machine currently imaging still shows it as Untracked however. I will allow this machine to boot to production and see if its health indicator changes then.

Hi Howard,

If I correctly understood what you are trying to get, is:

• Once machine with Agent registers with SMP Server and sends first basic inventory and get client policy request, it tracks as "untracked" until Update Membership will be performed on SMP Server

Example:

1. I've redirected SMA on new client PS to my SMP Server and now it shows this PC as Untracked.
2. After "Delta Update Member ship" update, this new PC has "Healthy" state.

Seems like , pre-defined PC doesn't send basic inventory and get client policy request, therefore it stays as untracked, until it will has SMA installed, registered in SMP and sent get client policy and basic inventory.

I'm just testing a manual Resource Membership Update now. I have run both the Poloicy update schedule (every 10 minutes) and a Delta update schedule (every 30 minutes).

Going back to the computers page this machine still has the grey stop symbol on its icon. I then sent it a task to boot to production and it did so and then went through the DeployAnywhere process.

I logged in with the local account but could not see the icon for SMA in the tool tray but it was loaded and responding according to the console. So I then dropped the task on it to add it to the domain and defined OU. It then rebooted and I was able to login with a domain account.

The agent is visible and connected and is currently upgrading from 7.5 SP1 to 7.6 HF1. I can tell that communications are working as the console is correctly reporting the current logged in user etc.

But the icon is still showing as Untracked for some reason.

After several minutes the client is now fully up to date and I can now see a green Healthy tick in the console.

I then PXE booted the machine again and this time it accepted and started the initial deployment job.

It looks like the machine, at least a newly pre-defined machine, appearing as Untracked, is not accepting these jobs for some reason. Through a number of manual resource updates an deploy job on its own was accepted and once it hit production and was upgraded to 7.6 its Health status was updated to healthy and then it was able to accept jobs in automation once more.

I think I need to log this as a support ticket, and will mention this thread for reference purposes.

I have just found a related issue. When trying to manually schedule a job to a newly pre-defined computer you get an error message.

"No licensed computers or targets with licensed computers were assigned".

This error occurs when you try and schedule a software deployment task. We have a job that boots to PXE, deploys an image, boots to production, adds the computer to the domain and then installs a load of software.

This job is not being accepted because of these software deployment jobs, I suspect. Definitely new behaviour since the 7.6 upgrade.

If you just schedule the imaging tasks and allow the machine to get to production, it will then communicate to the server, its health icon will change to healthy and at this point it will then start to accept any of the other jobs as, I assume, the server believes the machine has the software management solution agent and can therefor accept software deployment jobs.

What I would assume from this is that a further rebuild would then work, where a machine in automation/PXE will accept one of thes jobs with both imaging tasks and software deployment jobs because the computer object has evidence that the computer has the software management solution agent installed, even though it technically doesn't while in automation, as far as I am aware.

It looks like the addition of agent health might need to have some holes poked in it to allow jobs to be scheduled that have software deployment tasks, or in fact the two issues may not be interlinked at all.

Support pointed me to the following article:

https://www-secure.symantec.com/connect/forums/error-no-licensed-computers-or-targets-licensed-computers-were-assigned

For some reason this has been marked as a solution. However I don't believe this is the case. It is merely an explanation of why it might be going wrong, not a fix!

For example, I have a job that does the following:

Boot to PXE

Deploy Image

Boot to Production

Apply System Configuration (join machine to domain and specific OU)

Enable local admin account

Deploy .NET Framework 4

Deploy Office 2013

etc.

etc.

Now this job, configured as an initial deployment, will not work! Not for a new machine, because of the software deployment jobs. However, if you then drop just the image deployment related tasks with enough information to get this machine to boot to production AND allow the agent to talk to the server, this new basic inventory information is then uploaded to the server and its health will change to "Healthy".

At this point software deployments are possible. BUT, and here's the interesting bit, if you PXE boot the machine again it will now accept that earlier job. Why? Because the information regarding the agent on this machine now includes the updated agent information, even though the automation environment doesn't have it as far as I know.

So the question becomes: how do you pre-populate the autmation environment or rather the CMDB, with the required information for a brand new machine that has never had an agent running on it to accept a job that has sofware deployment jobs in it.

Because 7.5 did not have this issue and happily accepted jobs that had both imaging tasks and software deployment jobs.

7.6 and HF1 do not and this has totally broken our deployment process. Even if I separate out the deployment tasks, if they are all part of the same job it will still fail. Right now I would have to have an initial job that just imaged the machine and once it got to production and the computer object in the CMDB is fully populated, then I would need to manually scheduled the next job that does all the other stuff like software installs.

Here you can find the pointfix for the "No Licensed computers or targets with licensed computers were assigned." message: https://support.symantec.com/en_US/article.TECH230183.html

I will take a look at this and reply once testing has finished.

EDIT: Yes, this appears to work! Initially I received a different error about the machine not being capable of executing this job/task but I think this is the normal error you see immediately after a pre-defined computer has been added. The other way this issue shows itself is the machine will refuse to PXE boot because I have the server configured to not allow unknown machines to boot. After a few attempts the compute then PXE boots and accepted the job.