How to run a PowerShell command in UWP?
using (PowerShell PowerShellInstance = PowerShell.Create())
{
PowerShellInstance.AddCommand(".\fpcalc.exe " + file.Path + " > out.txt");
}
Because UWP apps run in a sandbox, you cannot directly execute another processes or run PowerShell scripts. However, you can utilize Windows.ApplicationModel.FullTrustProcessLauncher if you declare such capability in your app to launch a full trust process (like a console application) which can safely execute such script.
You need to add a restricted fullTrust capability to your app's Package.appxmanifest.
You can learn more about full trust processes in UWP from documentation, UWP samples or blogposts like the excellent blogpost series from Stefan Wick.
Related
I started to write a powershell script to automate the deployment of new Windows 10 PCs.
I've done a script to install the corporate apps and mapping the network folders and printers.
But I have a problem that I must input the admin password for each program I wish to install.
I've searched the internet and all I found was the runas command, I see that is similar to the su of Linux but I can't push the password.
This is how I made the install of all applications:
Set-Content "$DESTINO\program.bat" -value 'msiexec -i C:\progtemp\program.msi /quiet'
Start-Process $DESTINO\program.bat -Wait
Do you know a better method?
The two main ways to run something as an admin automated are as follows:
Create a Scheduled task to run a script, you can choose to run this escalated and store the credentials as required
Create a startup script using powershell (or batch file if you must!)
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn789190(v=ws.11)
Startup scripts run as the user system which is the highest privilege possible. Be aware that network access may not be available at startup and some things may not be accessible to system on your local network etc.
Highly recommend looking at Chocolatey https://www.chocolatey.org and possibly boxstarter: https://boxstarter.org/
to get you started with some automation and package management.
Microsoft also have a similar technology in early stages:
https://learn.microsoft.com/en-us/windows/package-manager/
But frankly Chocolatey is an open framework and its well established and mature at this stage.
I'm working on some web-based tools for our IT department, and need to launch a PowerShell script to do remote maintenance queries prior to loaning out a laptop.
I have an existing web-based registry of the laptop inventory, when one is loaned out we get the borrower to log in before they leave to ensure their profile is on the machine. At that point, I would like to query the laptop using a PowerShell script collecting information from it which would feed to the database and show on the display page.
The page itself is restricted to IT personnel, and our environments are very homogeneous -- everyone is running Windows (7 or 10) and IE (10 or 11).
I can launch a PowerShell script server-side easily enough from the VB code.
[ CommandToRun is a textbox, PStext an output span ]
Dim app = New Process()
Dim psi As ProcessStartInfo = app.StartInfo
psi.FileName = "powershell.exe"
psi.Arguments = CommandToRun.Text
psi.RedirectStandardOutput = True
psi.RedirectStandardError = True
psi.UseShellExecute = False
PStext.InnerHtml &= "<br/>Launching app: " & psi.FileName & " " & psi.Arguments
app.Start()
app.WaitForExit(5000)
PStext.InnerHtml &= "<br/>OUTPUT<br/><pre>" & app.StandardOutput.ReadToEnd() & "</pre>"
PStext.InnerHtml &= "<br/>ERROR<br/><pre>" & app.StandardError.ReadToEnd() & "</pre>"
But it runs as the local system which does not have the authority to run remote PS commands. Lacking Administrator status, the server cannot execute anything on remote computers, therefore cannot query the laptop being loaned out.
I found a Javascript client-side solution that looks easy enough:
function tryLaunch(commandtoRun, commandParms) {
// Instantiate the Shell object and invoke its execute method.
var oShell = new ActiveXObject("Shell.Application");
// Invoke the execute method.
oShell.ShellExecute(commandtoRun, commandParms, "", "open", "1");
}
But it gets a Permission denied error launching the shell.
Other sources have had the same JavaScript with "WScript.Shell" as the ActiveXObject parameter -- that fails on the construction, whereas the "Shell.Application" version fails on the ShellExecute command.
I know what I'm doing is intentionally disallowed, as its usually a pretty dangerous idea to allow web servers to launch code on clients, and portability issues kill even the most well-meaning ideas -- but like I said, this is a very controlled and homogeneous environment.
So ... my questions:
Am I missing an obviously better way to do this?
Should I focus on trying to make PS scripts run on the client? ( If so, any clues?? )
Should I focus on running the script server-side with different
access rights? ( Can I shell as the web site user? I have their
"user" object from AD )
Am I ignoring some capability of IIS to install a PS script as an
application using an Administrator account? (Seems like this should exist, which means I'm probably looking right at it and not seeing it. )
I have an application process that runs in IBM UrbanCode. The process uses a Powershell Script that uses the CloudFoundry CLI. Our application process runs on an agent on which the CloudFoundry CLI is installed and available on the Path. Strangely enough, the Powershell plugin doesn't know that the CloudFoundry CLI is on the path. Echoing out the path via the plugin itself confirms this.
Currently, our application process looks like:
Copy CloudFoundry CLI into UCD's workspace at the start of the job.
Execute various CloudFoundry commands via the following sytax: .\cf login -u foo -p bar -o baz -s bart
I want to avoid copying the client into the workspace and having to use the .\cf sytax in order to make the scripts more portable.
How can I get the Powershell plugin to respect the Agent's path?
Sounds like the user that your powershell agent is running under does not have CloudFoundry in its path. options are
1. Ensure the PATH variable is set system wide.
2. instead of copying the CloudFoundary CLI you could manually add the path to CloudFoundry before you run the script
$env:Path += ;<PATH TO CLOUDFOUNARY>
Note: this will only persist for the current session.
To test that you have CloudFoundary in the path you can use
Get-Command cf
We have some .net applications running on a server that run powershell scripts. Is there a setting where we can log every single powershell command run on that machine, without modifying our existing applications? I already tried start-transcript . That command only captures the commands run in the current session.
I believe Microsoft calls what you're after "Over the Shoulder Transcription". It's described here, and will be available in WMF5.
I am trying to create a PS script that would read an xml file (server name list) & then run click once app on each of these servers. In my case ,Power shell script execution will be scheduled via Task scheduler.
Now the problem is : I can't find a way to run click once app via Power shell script
Any ideas?
I run app ref files by running it through the explorer so an example would be
$fileLocation="C:\temp\program.appref-ms"
explorer.exe $fileLocation
This article documents a process to getting the file path to run the ClickOnce app
https://robindotnet.wordpress.com/2010/03/21/how-to-pass-arguments-to-an-offline-clickonce-application/
If you can translate this C#/NET code into PowerShell, it should work
StringBuilder sb = new StringBuilder();
sb.Append(Environment.GetFolderPath(Environment.SpecialFolder.Programs));
sb.Append("\\Nightbird"); //ClickOnce Publisher name (eg Nightbird)
sb.Append("\\TestRunningWithArgs.appref-ms "); //ClickOnce Product name (eg TestRunningWithArgs)
string shortcutPath = sb.ToString();
System.Diagnostics.Process.Start(shortcutPath, argsToPass);
You can run a ClickOnce application by doing a start process on iexplore.exe and passing it the URL to the ClickOnce deployment. Can you do that in PowerShell? If so, then it should work.