Mark Minasi's Tech Forum
Register Calendar Latest Topics Chat
 
 
 


Reply
  Author   Comment  
Matthew

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 19
Reply with quote  #1 
When setting up scheduled tasks to run sync cycles on a MIM sync server, I seemed to have run into a possible bug when setting "when running the task use the following user account".

Server = 2016 Standard version 1607, build 14393.1770

To setup the task I exported the identical task on the 2012 R2 server we are moving away from where it works as expected.

I then imported it into the 2016 server.

Long story short, I discovered that if you disable the task, then re enable it, it will not run. The reason is task scheduler is not retaining the domain\ for the service account the task is going to run as.

When you look at the 2012 R2 server, that fields has domain\account name
When you look at the 2016 server, that field just has account name.

I deleted the task, rebuilt from scratch, no change.

Work around is to reset the account and password as part of re enabling the task.

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

Did some googling and found this
https://social.technet.microsoft.com/Forums/en-US/0ccc8ab3-089b-4f50-9028-68ec0276619b/the-task-scheduler-isnt-saving-domain-information-for-running-a-task-as-user-windows-server-2016?forum=winserverManagement

The challenge I am having is finding anything to explain what SeDelegateSessionUserImpersonatePrivilege is/does, how to enable/disable, remove etc.

no one on my team has any idea about it. googling is sending me in circles. curious if any of you have any suggestions where to look.

if you do a whoami /all or whoami /priv it will show up in the Privileges Information section.

based on other settings in that section, I wonder if it is part of the user rights you can set via GPO, but I can't find anything that ties SeDelegateSessionUserImpersonatePrivilege to a friendly name in the GPO GUI.

the only other bit of info I can find is someone suggesting this is a bug introduced in 1607 and not yet fixed.
0
wkasdo

Avatar / Picture

Administrator
Registered:
Posts: 194
Reply with quote  #2 
> 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?

__________________
[MSFT]; Blog: https://blogs.technet.microsoft.com/389thoughts/
0
Matthew

New Friend (or an Old Friend who Built a New Account)
Registered:
Posts: 19
Reply with quote  #3 

Quote:
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. 

 

0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.