Originally Posted by wkasdo
> If I export the task and look at the xml file it only shows a SID where you would expect to see domain\account name
This is a good thing. The SID uniquely identifies the account and the domain. Try resolving the SID, you will see that it translates back to the domain account.
I tried disabling and enabling a task on Windows Server 1607. This worked fine. Any more details to your repro? Perhaps post the sanitized XML?
I do understand what SIDs are, but I am not sure I agree this is a good thing. I should be able to look at the Task Scheduler GUI tools and be able to tell at at a glance if the "run as" account is a local or domain. If I export the xml for any reason then open it and read it's content, I shouldn't have to take the step of resolving the SID to see what it's friendly name is.
when I see an unresolved SID in tools that had previously shown the friendly account name, I typically associate that with an issue of some kind.
On your test, was the task created prior to you having applied the 1607 update? I wish I had kept it, but I seem to remember reading in one of my google search results that earlier version of Windows 2016 didn't have this issue, and any tasks created pre 1607, not modified post 1607 were ok, but once modified would have this problem. I am trying to locate a pre 1607 ISO to verify this.
I was bouncing this off my MS field engineer for FIM/MIM and he felt this might be an issue with the Trigger time/date. we played with it a bit, and that does appear to be a factor. But I am not sure how to isolate just that part yet with a domain server and account. In the lab and production, the server was a member of the domain, the run as account was a domain account and simply reapplying the account/password got the task running again. When you make a change such as changing the initial trigger / time and date you are prompted for the user name and password when saving the task. So was it the change to the trigger time and date or reapplying the password that got the task running again?
So to do as clean a test as I could, I installed Windows 2016 Standard with the only ISO I had on hand and it came up as
Windows Server 2016 Standard version 1607 build 14393.447
No patches added, not joined to a domain.
I created a task that just runs a batch file that creates a text file so that I know it for sure ran or not. I am logged on with just the local administrator account and the task is running with the local administrator account set as the "run as" account.
If I set the trigger time and date into the future, enable the task. wait a minute, disable, wait a minute, re enable all prior to the trigger time and date the task will run successfully.
If I then disable the task then re enable the task, the task does not run.
A check of the application, security and system logs do not appear to provide any relevant information.
If I open the properties of the task, on the general tab, Security options, click on the change user or group to reapply the admin account and password, then save this "change", based on the domain based server and run as account in production or the lab the expected result was that the task would run again. When the server is stand alone and the account is local, it appears this does not get the task running again.
I have been focusing on the effect of disable and re enable and can now add reboot to what breaks the task.
The only thing I can find googling solution wise is the suggestion for removing or enabling SeDelegateSessionUserImpersonatePrivilege. But I am embarrassed to say I have no clue how to do that.