PC would not sync time unless we manually ran net time as an admin - Desktop Authority Management Suite (DAMS) - Desktop Authority - Dell Community

PC would not sync time unless we manually ran net time as an admin

PC would not sync time unless we manually ran net time as an admin

This question has suggested answer(s)

In DA we have Time Syncronization enabled and the time server is our primary domain controller, dc1.

In validation logic, everything is checked.

In validation logic rules its "IF Authenticating Domain Equals" our domain name.

SLtrace.htm shows this running.

However we had a call today from a user concerned because their clock was 5 minutes off.  We also had a ticket from another user a few months ago on this as well, and we applied the same fix.  Logged into expert assist as our administrative user account basically, went to command prompt and ran net time \\dc1 /set /y and then the time was corrected.

Shouldn't this be happening automatically?  What context does this run as because users do not have admin privileges.  Hence we use expert assist because we log in with an administrative account.  I would think PsExec would work too if we specify an admin level account.

All Replies

         If the trace file shows that the element is running, then the validation logic is correct.  The time server should be set to \\DC1 in the element or a dynamic variable should be used.  I prefer to use the dynamic variable $LServer which is the dynamic variable for the authenticating server which should resolve as \\DC1 in your environment if that was the authenticating server.  The command that you are executing manually is the same command that the script is automating.  If the user is a local administrator on the client machine, then the command will execute in their security context.  The trace file will show the user’s privilege level on the machine.  If the user is not a local admin, then the timesync element will execute in the security context of the domain user account that you provided for the Administrative service (which is a local administrator).

    A good test is to run CMD from an application launcher element for that user and have them logon again.  Select the checkbox to run as Admin and ensure that it is run synchronously instead of asynchronously and visible instead of hidden.  This will stop the script and launch a command prompt.  You can then type SET U and hit enter in order to see which user credentials the command window is running under (should be the domain user account provided for the Administrative service) and then type the command to sync the time:  NET TIME \\SERVER /SET /YES.

  • Ok I tried this for my username and tested logging into one of my win 7 vm's.

    SET U says



    net time \\dc1 /set /y

    Current time at \\dc1 is 6/4/2015 3:10:28 PM

    The command completed successfully


    The person's clock I fixed a few months ago IM'd me today saying their clock is ahead by 2 minutes.  So clearly something is not working correctly and I do not know what it is.

    Should I just create an application launcher element that is net time \\dc1 /set /y , run as administrator, hide screen output, launch asynchronously?

    The user scriptlogicuser... does that have to be a domain admin?  Its just a domain user at this point.  However other things in Application launcher checked off as "run as administrator" work... like silently running certain installers for example.

  • Ok that did not work adding net time as an application launcher element.

    72/72 - debf8000-f759-4c5f-8c0f-6a39e485dd0d]
    15:23:29 sub> SLexec: executing program: Target=[net time \\dc1 /set /y] Arguments=[] Flags=[- Visible Wait Admin LOGON ]
    15:23:29 Calling :: $SLcom.Exec(net time \\dc1 /set /y,,1,1,0,0,,0,)
    15:23:29 Got Back From .Exec Call
    15:23:29 Return Code: [5] Access is denied. (More Info)

    But it does not look like there are any errors for the actual time element

    15:23:25 Processing Time Sync elements [1/1]
    15:23:25 [domain 1/1 - debf8000-f759-4c5f-8c0f-6a39e485dd0d]
    15:23:25 Synchronizing time with /DOMAIN:dc1
    15:23:25 sub> SLexec: executing program: Target=[net] Arguments=[time /DOMAIN:dc1 /set /yes] Flags=[During Admin Hidden Async]
    15:23:25 Calling :: $SLcom.Exec(net,time /DOMAIN:dc1 /set /yes,1,0,1,0,,0,)
    15:23:25 Got Back From .Exec Call
    15:23:25 return code not available for async execution

  • I found this post over at Microsoft technet forums.  How would I accomplish this with DA?  How would I run a command prompt window as an administrator?

    If I run synchronous I get access denied.  If I run async it looks like it could have run but I can't be sure because it says that the return codes is not available for async execution.

    Post here:



    1.  Doman clients should automatically sync up with the domain controller(s).  To make sure this happens, enter the following commands on the client in a command prompt window (opened as "Run as Administrator"):

       w32tm /config /syncfromflags:domhier /update
       net stop w32time
       net start w32time

    2.  To synchronize a domain controller with an external time source, enter the following series of commands in a command prompt window (opened as "Run as Administrator"):

       net stop w32time

       w32tm /config /syncfromflags:manual /manualpeerlist:0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org

       w32tm /config /reliable:yes

       net start w32time

    Doug Pruiett Good News Jail & Prison Ministry Richmond, Virginia www.goodnewsjail.org

  • Hi kjstech,

            When you have multiple commands that need to run in sequence it is probably best to have them run from a script like a batch file. Then use an Application Launcher element to run that script on your machines. To have this Run as Administrator just check the box “Run as Administrator” in the Application Launcher element.

    Note: As always I suggest only validating to one machine when testing new elements this way you can work out any issues and make sure the element does exactly what you want it to do before pushing it out to more machines.

            Another option is to launch the command prompt using Application Launcher by placing “CMD.exe” in the [File name including path] field. Then place the commands in the [Arguments] field.


    Here is a KB that discusses some of the setup and troubleshooting steps when using Application Launcher.