The scheduled ODS are configured to run on a weekly base and I didn't configure any credentials for these tasks (as mentioned from McAfee in several posts). I am scanning some shares on this way.
When I start these tasks manually (logged in) from the Scanning system everything works fine. As soon as I am not logged on anymore the tasks are not working properly. They finish (logs) as completed but with no scanned files. I tested also with implemented credentials within the tasks from ePO. I encountered the same issue with manually created ODS task on the scanning system.
Well, I think this may be a problem with Shares and User Rights to those shares, when Not Logged In. This would explain why it works when logged in and run manually.
If no credentials are configured, the job running manually uses the current user for it's rights to network objects. When run automatically (on schedule) and no credentials, I believe it uses the System user which by definition does not have rights to network shares (unless Null Shares have been set up -- Not Recommended).
So, is this a NAS that you are scanning?
Why would you not run the ODS jobs locally and not across the network?
Hope this is helpful,
it's a special Server share and the service owner do not want to have a VSE locally installed. My problem is that it was working prior some times.
Isn't it possible to define an account for these scanning tasks? There is a form to define one.
And yes, it is using the System user.
Thanks for your fast response.
These issues are tricky.
We don't have any visibility into the inner-workings of the OS once we've executed the task with the provided credentials.
We don't have existing debug logging that we can enable surrounding that area of code.
And so we don't capture any failed return from the Microsoft API(s) we've called either. We only see the final result, Authentication Failed.
It's further complicated in that there are multiple branches of code we could've gone down, i.e. trying different authentication methods, calling different APIs when a previous attempt failed to return with Success. So if it worked before we don't know which code path that was.
The place to start, I think, is in helping us understand the structure of the domain; where the server sits in relation to the nearest DC, what security-related GPOs are in place, what account is being provided (if different from yours), and any other relevant info that comes to mind.
These issues should be reproducible for us, but we haven't learned how to reproduce them yet and trying to find the reason via inferring behaviors based on testing and diagnostics is extremely difficult. It's possible to solve though, just it'll be a painful investigative process until we know how to reproduce it.