Elevation of privilege per script

Source
The designers of Windows Vista's User Account Control expressly decided not to incorporate functionality like setuid/suid or sudo found in Unix and Unix-like OSes such as Mac OS X. I think they made the right decision.  
Large parts of the Windows ecosystem have a long legacy of assuming that the end user has administrative permissions, and consequently a lot of programs work correctly only when run that way. (I'm not going to delve into that history here, nor will I entertain any finger-pointing on the topic at this time. One of these days I'll post my thoughts on that subject.) As computer security has become increasingly important, breaking that cycle became absolutely imperative. It is with the release of Windows Vista that the first major move in that direction is achieved. Indeed, the primary purpose of the technologies that comprise UAC is to make the "standard user" the default for Windows, encouraging software developers to create applications that do not require admin. It's not perfect by any means, but changing the ecosystem will take a long time, and UAC is a good first step.
Pre-approving code to run with elevated permissions without going through an elevation prompt, as described in the bulleted scenarios above, seems at first glance to be both useful and convenient. However, the negatives far outweigh those benefits. In particular:

• The "standard user by default" vision would become impossible and ultimately never happen;
• Elevation of privilege (EoP) would be trivial – any compromise could lead to full system compromise.

If it were possible to mark an application to run with silently-elevated privileges, what would become of all those apps out there with LUA bugs? Answer: they'd all be marked to silently elevate. How would future software for Windows be written? Answer: To silently elevate. Nobody would actually fix their apps, and end-user applications will continue to require and run with full administrative permissions unnecessarily.
What if the application could not mark itself for silent elevation but instead had to be marked by the consumer or enterprise administrator installing the application? Answer: the developer of the installation program (which necessarily runs with admin/system permissions in order to install machine-wide) would figure out where the setting lived, and set it. (Several major ISVs told us directly that they would in fact do exactly that.) There would be no real way to protect that setting from anything running as admin. This would be especially true if it were settable via Group Policy (which would be expected, if not demanded).
"Well, so what? We're only talking about applications I approved!" OK, let's say that's true, but how do you ensure that a malicious user cannot use the application for purposes other than those for which it was intended? And at least as important – how do you ensure that malware that has infected the user's session cannot drive a setuid application programmatically to take over the system? Ensuring strict behavioral boundaries for complex software running with elevated privileges is (at best) incredibly difficult. And ensuring that it is free of exploitable design and implementation bugs is far beyond the capabilities of software engineering today. The complexity and risk compounds when you consider how many apps have extensibility points that load code that you or your IT admin may not be aware of, or that can load code or consume data from user-writable areas with minimal if any validation.
Privilege escalation due to setuid and sudo has plagued Unix-like systems for many years, and continues to do so. In fact, several of the bugs in the recent Month of Apple Bugs fell into this category. Follow these links for lots more references: (*)

• Secunia items re SETUID and local privilege escalation
• Secunia items re SUID and local privilege escalation
• MOAB posts involving privilege escalation
• Symantec write-up on how easy it is to subvert sudo
• Ease of exploiting a sudo authn "grace period"

In the past, elevation of privilege has tended not to be noticed in Windows – there is no real "elevation" if you're already running as admin. (**) With the Vista shift toward "standard user", EoP threats become much more important, and it is vital that Windows do as much as practical to mitigate them. That is also why Windows services are no longer able to interact with the user desktop. Taking on the setuid headaches that *nix has had to live with does not seem like a profitable deal.
We expect that in ordinary day-to-day usage, users should rarely, if ever, see elevation prompts, since most should rarely, if ever, have to perform administrative tasks – and never in a well-managed enterprise. Elevation prompts are to be expected when setting up a new system or installing new software. Beyond that, they should be infrequent enough that they catch your attention when they occur, and not simply trigger a reflexive approval response. This will increasingly be the case as more software conforms to least-privilege norms, and as improvements in the Windows user experience reduces prompting further.
Having said all that, there is a Local Security Policy option to change the behavior of the elevation prompt for Administrators to "elevate without prompting". With this option selected, anything that requests elevation gets elevated without prompting the user. (The default setting is "prompt for consent"; the third option is "prompt for credentials". Note that "elevate without prompting" is available only for members of the Administrators group. The options for standard users are "prompt for credentials" and "automatically deny elevation requests".) While "elevate without prompting" may be useful in well-constrained, secure environments for automated testing and possibly for initial system setup, having this option selected otherwise is very risky and strongly discouraged. (Note also that Vista's Home SKUs do not include the policy editor.)
Nitpicker's corner (***)
(*) Pointing out the obvious: local privilege escalation by definition means that the bad actor is already on your system. However, there's a huge difference between malware running as you (non-admin) and malware running with root privileges.  If there weren't, there would be no point (from a security point of view) in running with least privilege.
(**) "Elevation of privilege" in this context means "unauthorized elevation of privilege". Technically, yes, Administrator is not as powerful as System (in that there are operations that Administrator will get Access Denied where System will succeed), and System is not as powerful as kernel-mode code (in that there are operations that fail for user-mode code running as System that succeed when called from kernel code). However, two of the things that Administrator is authorized to do include: 1) configuring arbitrary code to run as System, and running it; and 2) loading arbitrary code into the kernel, and running it. Hence, if code is running as admin, there is nothing it is not authorized to do.
(***) "Nitpicker's corner" might be a trademark of The Old New Thing.
--------------------------------------
if wscript.arguments.named.exists("elevated") = false then
  createobject("Shell.Application").ShellExecute "wscript.exe", """" & wscript.scriptfullname & """ / elevated", "", "runas", 1
else
  'what you want to do with elevated rights
end if
=================
Source
The VB Script below will raise a UAC challenge, then invoke your batch file, but it won't turn off UAC.
'---------------------------------------------
'Invoke a batch file under elevated privileges
'25.2.2011 FNL
'---------------------------------------------
bElevate = False
if WScript.Arguments.Count > 0 Then If WScript.Arguments(WScript.Arguments.Count-1) <> "|" then bElevate = True
if bElevate Or WScript.Arguments.Count = 0 Then ElevateUAC
Set oWshShell = CreateObject("WScript.Shell")
oWshShell.run "d:\temp\Ariel.bat"

'-----------------------------------------
'Run this script under elevated privileges
'-----------------------------------------
Sub ElevateUAC
    sParms = " |"
    If WScript.Arguments.Count > 0 Then
        For i = WScript.Arguments.Count-1 To 0 Step -1
            sParms = " " & WScript.Arguments(i) & sParms
        Next
    End If
    Set oShell = CreateObject("Shell.Application")
    oShell.ShellExecute "wscript.exe", WScript.ScriptFullName & sParms, , "runas", 1
    WScript.Quit
End Sub
===============================

It seems that you want to run the copy action as an administrator using the script itself.

You can refer the following URLs, hope it would be helpful.
Utility Spotlight - Script Elevation PowerToys for Windows Vista
http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx?pr=blog
How Can I Run a Script Under Alternate Credentials?
http://blogs.technet.com/heyscriptingguy/archive/2004/12/13/how-can-i-run-a-script-under-alternate-credentials.aspx

Since this issue is more related to scripting, I recommend you open a thread to Official Scripting Guys Forum in Technet so those coders can help you fix the issue in a timely manner.
Official Scripting Guys Forum http://social.technet.microsoft.com/Forums/en/ITCG/threads
Script Center:  http://technet.microsoft.com/en-us/scriptcenter/default.aspx

===============================================

Source

You should be able to get around this by using the runas command:

runas /user:administrator /savecred c:\batchfile.bat

you can also use the run as to place the admin's username and password in plain text, but that less desirable. In the above example, the batchfile.bat would contain all of your copy and install commands for the citrix client.