I'm toying with an idea for a script that would update a computer's details in Active directory with its make and model information. Ideally, I'd like this script to access AD via its computer account, which means I'd need to have the script run as "NT Authority\NetworkService". Is this something that's possible? Alternatively, could I impersonate NetworkService in the script/executable?

  • Depending upon your end goal, you might want to look into SpiceWorks. It harvests much of this information automagically without tweaking AD.
    – hurfdurf
    Jan 17 '11 at 18:44

You can use devxexec: http://blog.developex.com/?p=1053

For example:

devxexec.exe /user:NETWORK_SERVICE cmd

  • Sadly, this doesn't seem to work on windows 2008r2 or newer, it throws error 0x000142
    – aseques
    Apr 11 '19 at 13:15
  • @aseques: Read the (archived) manual, it explicitly explains why this error occurs, and how to solve it.
    – AntoineL
    Oct 22 '20 at 9:12

"The scripting guy" has already answered this question here: http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr05/hey0429.mspx

You'll just need to include the WMI call to grab the machine model number...

My implementation went like this:

Set objSysInfo  = CreateObject("ADSystemInfo")
Set objUser     = GetObject("LDAP://" & objSysInfo.UserName)
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName) 

If objComputer.operatingSystem = "Windows*Server*" Then
    strMessage = objUser.CN & " logged on to " & objComputer.CN & " " & Day(Date) & "/" & Month(Date) & "/" & Year(Date) & " " & Time & "." 

    objComputer.Description = strMessage
End If

Call the above script from a GPO, using: User Config -> Windows Settings -> Scripts -> Logon

Then just update the permissions on the OU, so that users can modify the computer object descriptions, like this: screencap


I'm not sure how feasible it is to do what you want. Escalating permissions might be better asked over in StackOverflow. However, what not run the script as the local admin. With the exception of DC's, the account exists. On the \DC's you can run it as a domain admin or some other account that would have limited permissions for this task.


If the computers already exist in AD I would approach this problem from the other direction -- on the server side iriterate through the computer objects and use PsExec to find the information you require on the remote system and return it.


I'd then run the script under the account with the permissions required using Task Scheduler.


  • 1
    The problem with running psexec to query remote machines is that it's more complicated to deal with machines that are unavailable. If I configure a login script or an agent via GPO, I can sit back and wait for the computers to check in on their own rather than running query after query to catch every machine. As I think about it, though, it may be better to write this as an agent with a service that can easily run as NetworkService anyway.
    – bshacklett
    Jan 17 '11 at 22:22
  • And then the ridiculousness of installing a service just to push make/model info to AD hits me.
    – bshacklett
    Jan 17 '11 at 22:31
  • That's a fair criticism/annoyance. Sticking with the same theme you could push out the scheduled task to all of the client machines using a GPO. Jan 18 '11 at 13:41
  • That way you get the benefit of both: schedule tasks permission escalation and the "one time check-in" by running it on the client side. Jan 18 '11 at 13:50
  • 1
    After trying it and doing some research, it appears that the Network Service account does not have rights to run as a batch job.
    – bshacklett
    Jan 20 '11 at 12:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.