Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
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

4 Answers 4

up vote 4 down vote accepted

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

For example:

devxexec.exe /user:NETWORK_SERVICE cmd

share|improve this answer

"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 quit ELSE

strMessage = objUser.CN & " logged on to " & objComputer.CN & " " & Day(Date) & "/" & Month(Date) & "/" & Year(Date) & " " & Time & "."

objComputer.Description = strMessage objComputer.SetInfo

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

share|improve this answer

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.

share|improve this answer

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.

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

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

http://technet.microsoft.com/en-us/library/cc721871.aspx

share|improve this answer
    
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. –  boyonwheels 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. –  boyonwheels Jan 18 '11 at 13:50
    
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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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