So, I have been trying to do the following via a PowerShell script:
For a list of computers, do:
Ping the computer (via WMI) to see if it's available; if not, log & break, if so, continue on
Create a folder on the root of the C:\ drive (via Invoke-WmiMethod); if fails, log & break, if successful, continue on
Copy files (includes an .exe) from another machine into that folder; if fails, log & break, if successful, continue on
Run the .exe file (via Invoke-WmiMethod); if fails, log & break, if successful, log success, done (with this computer.)
The problem I'm running into is the execution of the .exe (program installer) -- the Invoke-WmiMethod command usually works, but for some machines, it hangs (not fails, but hangs.) I've tried a whole bunch of stuff to try to get it to run as a job so I can set a timeout on the install (running the Invoke-WmiMethod command with -AsJob param, always returns Failed...; Start-Job -Computer $compname { Invoke-WmiMethod..., returns Completed but the install never happens; making sure the remote machines have Windows Firewall disabled, UAC turned off, etc. but still if I run the Invoke-WmiMethod command on them, not running as a job, it hangs. And yes, I'm running PS as a Domain Admin, so I should have rights on the target machines.)
So being a newb at all things PowerShell, I'm now at a complete loss as to what to try next... How would you tackle running a .exe on a remote system from a PowerShell script? One caveat is that the target machines don't all run PowerShell [V1|V2] (target PCs are a mix of XP, Vista and 7) or don't have remoting enabled. The other caveat being that the installer is an .exe, and not an .msi, and this can't be changed (it's a third-party app.)
Thanks in advance to anyone who can point me in the right direction here (and give me some sample code...)
What OS is running on the system (management station or central system) where these scripts are getting executed? If Windows XP, there is a known issue with WMI and -asJob.
Check this: WMI Query Script as a Job
In such a case, I'd suggest moving to a Windows 7 system and then run the script to remotely install .exe on all other machines.
Related
So I need to uninstall some program and clean all the leftovers (folders + registry)
and then install the new app with all it dependencies - all this on 150 workstation
I've created a Powershell script and it's doing all the mention above without any issues,
the issue begins when I need to run the installation, it's located on a network share, here is the syntax:
Set-Location "\\imapps\FileSiteClientInstall\Setup Imanage\DRIVE -iManage Drive for Windows 10.2.6.48"
Start-Process iManageDrive.exe /s
The issue is that i have 6 lines like this one (each installation file is in a different folder),
and when I run this from the network I'am getting this UAC
is there a way to disable it, and make my script to run fully automatically?
Thanks alot for your help :)
So, not really UAC for what most people think of UAC. This is warning about running an executable from an untrusted location (not on a local drive). You'd get the same thing with a script that you download from the internet. What you can do is use the Unblock-File cmdlet to get past that warning like this:
Set-Location "\\imapps\FileSiteClientInstall\Setup Imanage\DRIVE -iManage Drive for Windows 10.2.6.48"
Unblock-File .\iManageDrive.exe
Start-Process iManageDrive.exe /s
This should mark the file as safe, and avoid the prompt you've been getting.
I've created a script which calls 'dfsutil', and is available for all the members in my team. Some members don't have RSAT (dfsutil) installed locally, so I'd like to 'trigger' a .ps1 script independently of the source PC (PC1) to be run on a server (Server1) which has 'dfsutil' installed.
It's easy enough to trigger a remote PowerShell script from the source 'PC1' by dot-sourcing it from 'myscript.ps1':
. \\Server1\scripts\dfsscript.ps1
As we already know, the above will fail as PowerShell is looking for 'dfsutil' locally on PC1, rather than on the server 'Server1'.
'dfsscript.ps1' has been written so it can be run independently, without need to return the values to PC1.
I can't seem to find any documentation which shows how to initialise a remote script which only uses the values and conditions of the OS it was triggered on.
Any thoughts?
Dot-sourcing is about the scope of a PowerShell session, but doesn't include the computing environment, so what you are doing won't get the script on Server1 to run from Server2, but still act like it is on Server1 with access to all of Server1's installed apps, etc.
What you need to do is use PowerShell remoting to actually run the script on the remote server (i.e. trigger from Server2, but execute on Server1). For example:
Invoke-Command -ComputerName Server1 -FilePath <path>\script.ps1
I'm Running powershell script using TFS build step - Run PowerShell on Target Machines but it does not work.
Here's how script looks like:
Start-Process -FilePath 'Bginfo.lnk'
It runs shurtcut that refreshes information on pc desktop using bginfo.exe - script works fine when its executed manualy.
TFS executes that script, but it does not work - bginfo is not refreshed.
If I add to that script line that creates new file it also will be created.
Why it does not automatically update background using specified shurtcut?
I can reproduce this issue. Tried command line, batch script, PowerShell steps with /TIMER:0 /SILENT /NOLICPROMPT set and with the service account which has administrator's privilege. Seems it only works when run the script manually on target machine.
In this case, if you want to refresh the system info automatically, you can use task schedule to run the Bginfo script in target machine. Reference below threads :
BGinfo not running silently
BGInfo on Windows Server 2012
Making BgInfo work in Windows 2012 / Windows 2016
I am not able to execute the Powershell file script from C# with Invoke-Command on a remote machine but at the same time I am able to execute the same script file using Invoke-Command on a remote machine through the PowerShell Command window with out any issue.
My remote machine as well as local machine has been enabled for Remoting by executing the call Enable-PsRemoting on both the machines. I also set the ExecutionPolicy on both the machines as Unrestricted.
While executing the script I get the following error/execption:
File G:\x.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.
I cannot understand what is the issue here.
Is this machine running a 64-bit OS? If it is, there will be both 32 and 64 bit PowerShell environments, and each has it's own execution policy. Depending on how you're invoking the script you may not be running in the same environment and execution policy as what you're using interactively in the command window.
I need to know if it is possible to run powershell remotely in the following scenario:
I have a Windows XP box WITHOUT Powershell installed. From this box, I would like to run a PS script located somewhere like: \\mypc\C$\Scripts\information.ps1.
The script should be run against the machine where it resides. In this case, the “mypc” machine would be running the script and returning the result to the XP machine.
What makes this difficult is the fact that I cannot install Powershell or any third party apps on the Windows XP machine.
It’s a long shot but would this be doable?
Thanks!
While you can't actually run the script on the local machine without PS installed there, depending on what you want to actually accomplish you may be able to run it locally and simply access the remote resources. Most of a machine's resources are typically available remotely (File System, Registry, WMI, etc.) depending on the security on the machine.
EDIT: Now that my complete misunderstanding of the issue is cleared up, my answer would be: No, you do not need to have Powershell installed on a local machine to run a script on a remote machine that does have Powershell installed. Just use PSExec to kick off the Powershell process on the remote machine. I realize that the OP cannot install 3rd party apps, but there is absolutely no install associated with PSExec, it is a completely stand alone exe.
It has been a while since I had to do this so I did a quick check. This at the command line worked for me:
psexec \\REMOTEMACHINE "C:\Windows\system32\WindowsPowershell\v1.0\powershell.exe" -File C:\temp\test.ps1 -NoProfile -NonInteractive
You need to have Powershell installed. This isn't possible :(. Sorry.
Using Psexec is the only way I can think of too. However, if you are using PSexec.exe using alternate credentials, the credentials are passed over the network in plaintext. Something to be wary about if your network is visible to other people.