none
Problem running a scheduled task as a different user with DCOM event ID 10010 RRS feed

  • Question

  • I have an interesting problem.
    Im moving a service from a Windows 2008 R2 Server to a Windows 2016 server, at the same time I am upgrading the software where the service runs. It uses a DCOM connection to communicate with another server through a special function/service account. The service is executed through a batch file every hour through a task schedule with the special user running the batch file. On the new server I, for first test purpose just ran the batch file “as a different user (userxxx)” and it runs fine and delivers the data as expected. However I was extremely surprised when I created a task schedule and using the same userxxx and it delivered a 10010 event ID with The server {GUID-NAME }did not register with DCOM within the required timeout. Checking the permissions in component services was sat proper and running procmon like a beast I realized that when I run the batch file as the different user I can see the process create/start operations are using the correct environment variables and sets user profile to the correct user, appdata to correct user and username to the correct user (userxxx). However, when I run as a task schedule it starts running the software as the correct user, but in another call for next software connection it sets the username to the computername (computername$) and profile to c:\windows\system32\config\systemprofile, and that seems to initiate the 10010 error after some timeout and automatic retries.

    Does any one have the same issue and can have any idea how to run the task schedule as with the (userxxx) environment variables the whole way? I have already created C:\Windows\System32\config\systemprofile\desktop as suggested also for the wow64 folder and the (userxxx) is a local admin on the server for now.

    • Edited by Styggo Monday, October 7, 2019 4:07 PM
    Monday, October 7, 2019 4:04 PM

All replies

  •  but in another call for next software connection it sets ….

    What exactly does that mean? What is "next software connection"? 

    I don't quite understand what this bat file is doing. Does the bat file run different executables? Or does it run the same program several times and passes a system name as a argument.... and the program then does a CreateObject targeting the specified server? Or does the bat file run one program and it makes multiple calls to a single server? 

    Are you using a START command in the bat file when running the executable?    

    Monday, October 7, 2019 5:49 PM
  • Ah, many thanks for your reply.

    No. I dont run START

    The batch file is a one-liner running a single exe file, that exe magically doest "stuff" that I dont really know, and in procmon i can see 2 other exe files start running (with different names). In procmon I filtered on "operation" start and create, and looking at the properties of these files when I run it manually as a different user (userxxx), it keeps the environment settings for the user, but when I run it through task schedule  only the first exe file keeps the enviroment settings, and the 2 next ones change settings to User=computername$ user profile to C:\windows\system32\config... SO there is obviously a difference although there shouldnt be. ALso, when I run this on a Windows 2008 R2 there is no problem in task schedule either.


    Who the hell is General Failure, and why is he reading drive C?




    • Edited by Styggo Monday, October 7, 2019 6:44 PM
    Monday, October 7, 2019 6:27 PM
  • I only have Win10 to test with. I wrote a little Powershell script to call 2 more levels of Powershell to try to recreate your situation.

    whoami.exe
    $env:USERNAME
    $env:APPDATA
    'Calling powershell to call another powershell'
    powershell.exe 'powershell.exe ''$env:USERNAME;$env:APPDATA;sleep 5'''
    

    The output that I captured all looks good. 

    C:\WINDOWS\system32>powershell.exe c:\utils\MultiProcess.ps1  
    test10b\testuser
    testuser
    C:\Users\testuser\AppData\Roaming
    Calling powershell to call another powershell
    testuser
    C:\Users\testuser\AppData\Roaming
    

    Procmon trace also looks good. Check the Parent Pid and make sure its the process in your BAT file that's launching it. Is the User the correct one (userxxx)?

    Do you see any DCOM calls or network calls in the procmon trace? 

    I did find these.

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/5e6dc56d-9069-42e3-a7e3-87437cf8ed81/scheduled-tasks-run-in-the-default-user-profile

    https://support.microsoft.com/en-us/help/3133689/ubpm-doesn-t-set-environmental-variables-correctly-when-you-run-schedu

    Monday, October 7, 2019 9:19 PM
  • Thanks, ill try to post some imeages of what happens and impersonate the stuff..

    The KB3133689 didnt apply for Windows 2016, but the articles you provided where interesting.


    Who the hell is General Failure, and why is he reading drive C?

    Tuesday, October 8, 2019 5:28 AM
  • Hi, 

    Any update? 

    If you need any further assistance, we are very glad to help. 

    Best regards. 


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, October 10, 2019 1:53 AM
  • Hi,

    Just want to confirm the current situation.

    Was your issue resolved? 

    Best regards. 


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Monday, October 14, 2019 8:03 AM