I have the following script that updates the computer description in active directory with the logged user but it only works if the logged user has admin rights. Can anyone tell me how can I modify the following code to make it work for users that have not any admin rights...lets say to impersonate another domain account to run this script.

strComputer = "."

Dim adsinfo,nw
Set adsinfo = CreateObject("adsysteminfo")
Set ThisComp = GetObject("LDAP://" & adsinfo.ComputerName)
Set oUser = CreateObject("WScript.NetWork")
Thiscomp.put "description", " User: " & oUser.UserName

This is very urgent for me as I have to do it this weekend for 5000 computer accounts.

thanks a lot in advance
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Chris DentPowerShell DeveloperCommented:

Perhaps this little tool will help...


It would allow you to run the script as Admin without having to write the password in a place people can "borrow" it.

PollinAuthor Commented:
Hello Again Chris:

is there any way to pass the password encrypted?
I am not allowed to use unencrypted passwords as many users has read access to the domain policies.
Chris DentPowerShell DeveloperCommented:

Yep, that's one of the features of the tool and really why I suggested it over something like the runas command.

You need to create a Job file first, then that's what you end up running. Lets see, it should be something like:

cpau -u yourdomain\administrator -p <password> -ex "<VbScriptName>" -file "<This is the file we're creating>" -enc


cpau -u domain\administrator -p Password324 -ex UpdateCompDescription.vbs -file UpdateCompDescription.txt -enc

Now all you need to do is run that Job file from the logon script:

cpau -file UpdateCompDescription.txt -dec -profile

Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

Chris DentPowerShell DeveloperCommented:

By the way, you will need to put CPAU in a shared location as well as the VbScript and the Job file you create.

PollinAuthor Commented:
thanks Chris,
I am trying to use the syntaxis you gave me but there is an error:

To encode I use:

     cpau -u testdomain\teastadmin -p PWD$$ -ex pcdescription.vbs -file pcdescription.txt -en

To run it:

     cpau -file pcdescription.txt -dec -profile

The Error:

          CPAU V01.11.00cpp Joe Richards (joe@joeware.net) November 2005

          Current Security Context: testdomain\testuser
          Attempting to use job file pcdescription.txt
          Successfully Processed Job File
          Error: Couldn't create Process: (193) Unknown Error

The command did not complete successfully.

Do you have any idea why?
Chris DentPowerShell DeveloperCommented:

-en should be -enc but I guess that's just a typo in the question if it's created the Job file.

Chris DentPowerShell DeveloperCommented:

The pcdescription.vbs file is in the same place you're running cpau from right?

I just wonder if you need more of a path there.

PollinAuthor Commented:
Yes all are in the same directory, I am testing before configuring it as a logon script.
Also I have been reading the help file of the utility and it says something like if it will be used as a logon script it should be copied locally as the utility doesn't work with network paths... here is the notes:

  I had to add some protection to this app. It seems people were running this with
  a networked drive for the current working directory. Microsoft prevents cross-
  security context access of network drives on purpose, this causes CPAU
  to not be able to fire the process up. To correct for that, if CPAU realizes
  your current working directory is a network drive it will change the CWD to the
  default local path (usually c:\windows\system32). To override this functionality
  you must specify the CWD option, note that if you set it to a network
  drive you most likely will not function properly. Also note that this is
  not a bug in CPAU, this is purposeful functionality from MS. You can see this
  out of anything that changes your local security context.

  If you are using this for a logon script or something else where
  you need the permissions to take affect locally, you need to specify the
  -lwp (or -profile) switch. By default the process spawned has the current
  user's security context locally and the new security context remotely. Also
  keep in mind the note above concerning network drives, logon scripts run from
  network drives, you will need to set the CWD to a local machine
  (c:\temp maybe) and copy whatever files are necessary locally and then run cpau.

What do you think?

Chris DentPowerShell DeveloperCommented:

Reading the help files would always be helpful and it sounds like it describes the problem you're having.

The user should have permission to write to their own temp directories at the very least, i.e. %userprofile%\local settings\temp. It would certainly be worth copying the files there before running them to see if it solves the problem.

PollinAuthor Commented:
just done it but still doesn't work.

What about using the createprocess method from WMI to impersonate a user?
I have this code that runs a command on a remote computer impersonating a domain user account but don't know how to convert my script to access active directory using WMI impersonation.

This script optain the free space data on a remote server:

strComputer = "Server1"
Set objWMIService = GetObject("winmgmts:" _
    & "{authenticationLevel=Pkt}!\\" _
    & strComputer & "\root\cimv2")
Set colDisks = objWMIService.ExecQuery _
    ("Select * from Win32_LogicalDisk")
For each objDisk in colDisks
    Wscript.Echo "DeviceID: " & vbTab & _
        objDisk.DeviceID & vbNewLine & _
        "FreeSpace: " & vbTab & objDisk.FreeSpace
    NextstrComputer = "."
    Set objServices = GetObject( _
        "winmgmts:{impersonationLevel=impersonate," _
        & "authenticationLevel=pktPrivacy}!root/cimv2")
    Set objProcessSet = objServices.ExecQuery _
        ("SELECT Name FROM Win32_Process",,48)
    For Each Process in objProcessSet
        WScript.Echo Process.Name

do you know how to change it to update an active directory object?
Chris DentPowerShell DeveloperCommented:

You're not actually raising your priviledges with the WMI script though, that's not what the ImpersonationLevel and AuthenticationLevel are there for - so it wouldn't help too much with allowing a User to update AD (even though there is a WMI interface for AD).

With ImpersonationLevel set to Impersonate you're basically executing the remote WMI query with the User Account running the script. I believe Impersonate is the default as the two lower levels of impersonation (Anonymous and Identify) really aren't all that useful for running scripts remotely.

Authentication Level is used to control the data flow, and in effect it requests that it be secure. There's no guarantee of that security though.

You can read all about WMI monikers on the MS Site:


Except for using a tool such as CPAU I can't really think of a way to allow end-users to update AD.

Chris DentPowerShell DeveloperCommented:

Can a standard user actually run the Job file with CPAU after logon (that is, not as part of the logon script)? Or does it just not work at all?

If it doesn't work does it work when run as Administrator?

Chris DentPowerShell DeveloperCommented:

Incidently you could use something like CreateProcess to launch the script on the local machine as Administrator. But if you're doing that you may as well just run the entire thing remotely as the currently logged on user and the computer model (discussed in the other question) are available to anyone with access to WMI.

While that method isn't good for a continual update, or even for dealing with PCs where the user is away it should be able to capture the majority.

PollinAuthor Commented:
using the utility doesn't work even if i am logged as the administrator, it returns the same error.
Maybe I am using wrong the utility? the .txt is created so I think is not a problem when encoding.
do I need the parameters -profile or -pdw ?
please help me Chris!!!!
I just want my users to update the computer description in AD doesn't matter how, I just don't wanna give them any additional rights.
thanks much
Chris DentPowerShell DeveloperCommented:

Sorry for the delay, bit of a busy weekend.

-profile should really achieve the same as -lwp, if it doesn't work with either then it implies something else is wrong. Did you also copy the script locally and do -cwd <local path>?

If that is the case then it should all be simplified a little, first try running the script with CPAU but without encrypting everything:

CPAU -u domain\administrator -p <Password> -ex <ScriptName> -profile -cwd <Local Path of script>

We could potentially just run through every PC on the network and pull the details from WMI to write into the computer account, but it would be difficult to ensure that the right details are being added. However, if you're interested in trying it then let me know and I'll drop something in.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.