Jobs for new computers will not schedule until after a Delta Resource is run on the server


Article ID: 157742


Updated On:


Deployment Solution


When a new computer boots into WinPE or LinuxPE, it connects to the NS and a new record is created.  If you attempt to schedule a job on this computer as soon as it appears in the console, it may fail with one of the following:

  • A message says that after scoping and filtering no computers could be scheduled.
  • On the schedule screen, the selected computer(s) may show a message indicating that it can not run the job selected (e.g. if you drag and drop the job on the computer)
  • If you attempt a quick-run of the task, the computer may not be on the list of available computers.

If you attempt the same thing with Initial Deployment it will work fine.


This happens because the computer has not been placed yet into all the appropriate filters/collections necessary to run the task/job.  Though the computer is in the console and database, the Delta Resource Update has not run to place the computer in all the appropriate collections.

Initial Deployment schedules the job for you without paying attention to the collections the computer is in, and essentially gets past this problem.


This is a known issue and is being worked on by Development for a fix.

The officially supported current work-around is to manually run the Delta Resource Update.  However, this can cause problems for large customers and/or large deployments.  For instance, if the Delta update takes 20 minutes to run (very large environment) that would be problematic.

There is another work-around that is provided here, "AS-IS" with no tacit support from Symantec.  It involves a direct edit of SQL to create a new trigger on a table and then insert records into two other tables directly.  It should work and several customers have reported success, but again, it is not supported.

============== Unsupported Work-around ================

 The net problem with this is that there are two values in a single linking table that must be populated with a connector to the computer record created when an agent first checks in.  Essentially, this is creating a "type" for the new account.  When Delta runs, it populates this table based on values received from basic inventory.  However, the Delta may take some time to run.  To work around this issue, we've created a filter that can be added to the basic inventory table that fires on all new computers and injects the appropriate values IF the new computer is also in automation.

To add this filter to your environment, run the following SQL:

CREATE TRIGGER [dbo].[trg_Inv_AeX_AC_Identification_insertintocollectionmembership]
     ON [dbo].[Inv_AeX_AC_Identification]


INSERT INTO CollectionMembership (CollectionGuid, ResourceGuid, CreatedDate)
               WHEN i.[OS Name] = 'Windows (TM) Code Name "Longhorn" Preinstallation Environment'
                    THEN 'E3A71B08-1612-44A6-9F71-7D359D5475B4'--Windows Computers
               WHEN i.[OS Name] = 'Deployment Preboot Linux'
                    THEN '6D05AC39-2CBF-4DA0-BCA1-0E64CA22A59C'--Linux Computers
          END, i._ResourceGuid, GETDATE ()
FROM inserted i
where i.[OS Name] = 'Windows (TM) Code Name "Longhorn" Preinstallation Environment'
     or i.[OS Name] = 'Deployment Preboot Linux'


SELECT 'EB3A1A12-E1C7-4431-B060-F0333E4E488C', i._ResourceGuid, GETDATE ()
FROM inserted i
where i.[OS Name] = 'Windows (TM) Code Name "Longhorn" Preinstallation Environment'
     or i.[OS Name] = 'Deployment Preboot Linux'




After running this, you will see a new trigger created on the Inv_AeX_AC_Identification table which wasn't there before.  If for whatever reason this causes problems, or you suspect it has, you can simply delete that trigger.

There is almost no delay in how quickly this functions, but you may see interesting results if you attempt to schedule a job before about 1 minute has transpired.