Every Task has an assigned user scope. Typically the one who created or saved it at last. If the user does not exists (anymore) the query will not resolve. So it is normal behavior. What becomes strange it that normally you can resolve it by just restarting the task
with your user which reset the scopeuser.
There are several options to solve this issue:
1) Restart the task with your user (Scope than should be set to your account)
2) Try restarting the Task with another user
3) Just recreate and start the task
4) Edit the LD_Task Table set the ScopeUser_idn to your Console User ID for this task, restart the task
Thanks for the reply.
The task shows my account as the scope user. I recreated the task and recreated the query and had the same results and error. This also happens on every other task I have tried as well.
oh that does not sound well. Needs a little more investigation here. Did you tried it with another user?
In addition you or your dba maybe can execute the following sql on your database an post the result here?
Select ldt.task_name, ldt.consoleuser_idn, (Select cu2.username from consoleuser cu2 where cu2.consoleuser_idn = ldt.consoleuser_idn) as taskowner, ldt.package_idn, ldt.ispublic, ldt.scopeuser_idn, cu.username as scopeuser from LD_Task ldt
left join consoleuser cu on ldt.scopeuser_idn = cu.consoleuser_idn
where ldt.LD_Task_IDN = <TaskID>
Replace <TaskID> with the TaskID of the corrupt task.
This should show exactly who is the owner of the task and who the scope user.
Btw. did you restarted the task from a remote console or directly from the coreserver?
And did you install any base patches after SP2?
I am waiting for our DBA to run that query on the database and I'll report back the findings.
-I have had another admin run the task and recieved the same error.
-I have restarted the task from both a remote console and directly from the core with same results.
No base patches after SP2.
maybe you should open a case with the LANDESK Support. There are several post SP2 patches available that may solve your issue.
For example here you will find the latest patch for 9.6 SP2: Support for Windows 10 in LDMS 9.5 and 9.6
But however, if you post the result of the sql query, we maybe can exclude wrong database entries as root cause.
I saw the same exact issue when on my development server after upgrading it to SP2 and applying all post SP2 component patches. I ended up having to delete the user accounts from User Management. Once the user logged back in, they were able to run the task and have the query resolve.
The weird thing was that I didn't experience this when I upgraded my production to the same patch level. The only thing I suspect is that I core synced my packages and tasks over from my production core. Not sure if that had anything do to with the issue.
Do you use core sync?
I dont believe we use core sync. We did just move to a new core last week and that is when this started happening. I was not a part of that move but I know that all of the queries, tasks, packages, etc were exported from the old core and imported to the new core. I suspected that may have been an issue so I created brand new queries and tasks on the new core but still have this issue. We use LDAP so each user of landesk console is in a Active Directoy group that is assigned certain roles.
did you had a look at the consoleuser table and the coresponding scopeuser at your LD_Task table when it happened in your environment LANDeskWizrd?
I did look at all table I could think of. I only had one account which I could run the tasks without issue. It was the account I built the dev server on. All others had this same issue as OP.
From the sound of it, whoever built the new server may have used core sync. I suspect it has something to do with that process. Creating brand new queries and tasks didn't work for me either.
I also use LDAP for user roles\scopes. You can delete the account and assign all your items to another account. Then log back in and see if you have the issue. This essentially creates a brand new consoleuser entry for your account.
Sounds like an issue that the consoleuser_id does not match anymore. Nasty Bug.
Content of the tables would be very interesting.
Fixing then should be possible via SQL or the way of recreating the affected users within the console.
Who is the owner of the scheduled task? Does this owner still exist in the LDMS Console Administration - User Management? Does this owner still exist on the LDAP server if you use it?
The owner of the task is myself. My LDAP user is still active and is still set as an LANDESK Administartor role on the core.
I do think I've made some progress in this. I noticed my user has 2 different roles assigned to it. LANDESK Administrator and IT Help Desk. I went into the properties of my user and made LANDESK Administrator the Explicit Role, recreated the task, and ran the task with the same query in it and it resolved just fine and the task completed. I'm wondering if having 2 roles assigned made them conflict with each other.