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.
Related
I have slow PowerShell console startup times (always more than 5 second wait) and was hoping for advice on troubleshooting steps to find out where the bottlenecks might be?
I have read that for running scripts, -NoProfile is important to prevent Modules etc loading, but how, in general, should we approach finding out what is slowing things down? I don't have many Modules installed and I know that since PowerShell 3.0, Modules are just referenced at startup and not fully loaded (a Module is only fully loaded when a function from a given Module is invoked) so I just can't understand why it takes 5+ seconds to start a bare console (my $profile also is empty).
Any advice on various steps that I can look at to debug the console startup process would be appreciated? Also, are there maybe some Microsoft or third-party tools that exist to debug the various steps in the console startup process to look for bottlenecks?
When PowerShell starts to become slow at startup, an update of the .NET framework might be the cause.
To speed up again, use ngen.exe on PowerShell's assemblies.
It generate native images for an assembly and its dependencies and install them in the Native Images Cache.
Run this as Administrator
$env:PATH = [Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()
[AppDomain]::CurrentDomain.GetAssemblies() | ForEach-Object {
$path = $_.Location
if ($path) {
$name = Split-Path $path -Leaf
Write-Host -ForegroundColor Yellow "`r`nRunning ngen.exe on '$name'"
ngen.exe install $path /nologo
}
}
Hope that helps
Step 1: Stop using PowerShell.
Now, seriously, something that needs ~13 seconds (YMMV) on an quad-core i7 cpu to launch off an ssd drive is an abomination of software architecture.
But yes, I hear you, "no viable alternative" etc...
... but if forced, bribed or blackmailed to still use it, check if your Windows has DNS cache service enabled.
For me, with DNS cache disabled and powershell executable firewalled, the built-in 5.1.19041.906 version starts quickly, but the new pwsh 7.1.4 would take around 13 seconds to get responsive to keyboard input under the same circumstances. It's so desperate to call home that it would just synchronously wait for some network timeout while blocking all user input, as if threads were a thing for the weak.
My resolution was to stick with the olden powershell 5.
My work computer stored the main profile on a remote server. Another minor problem was that it imported duplicate modules from 4 different profile.ps1 files.
Use the following commands to see where your profiles and modules are stored. Delete the unnecessary profile.ps1 and move all your modules into one directory.
echo $env:PSModulePath
$profile | select *
My loading time was reduced from 21000ms to 1300ms.
Found this solution when I googled having the same problem, but in 2022. Unfortunately this did not fix my issue.
Our systems have a group policy security requirement to "Turn on PowerShell Transcription". The policy requires that we specify "the Transcript output directory to point to a Central Log Server or another secure location". The server name changed and no one updated the policy. As soon as I updated the GPO with the new location, PowerShell opened instantly again.
Press Windows+R
Type %temp% and hit enter
C+A & SHIFT+DEL
That should do it
I have slow PowerShell console startup times (always more than 5 second wait) and was hoping for advice on troubleshooting steps to find out where the bottlenecks might be?
I have read that for running scripts, -NoProfile is important to prevent Modules etc loading, but how, in general, should we approach finding out what is slowing things down? I don't have many Modules installed and I know that since PowerShell 3.0, Modules are just referenced at startup and not fully loaded (a Module is only fully loaded when a function from a given Module is invoked) so I just can't understand why it takes 5+ seconds to start a bare console (my $profile also is empty).
Any advice on various steps that I can look at to debug the console startup process would be appreciated? Also, are there maybe some Microsoft or third-party tools that exist to debug the various steps in the console startup process to look for bottlenecks?
When PowerShell starts to become slow at startup, an update of the .NET framework might be the cause.
To speed up again, use ngen.exe on PowerShell's assemblies.
It generate native images for an assembly and its dependencies and install them in the Native Images Cache.
Run this as Administrator
$env:PATH = [Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()
[AppDomain]::CurrentDomain.GetAssemblies() | ForEach-Object {
$path = $_.Location
if ($path) {
$name = Split-Path $path -Leaf
Write-Host -ForegroundColor Yellow "`r`nRunning ngen.exe on '$name'"
ngen.exe install $path /nologo
}
}
Hope that helps
Step 1: Stop using PowerShell.
Now, seriously, something that needs ~13 seconds (YMMV) on an quad-core i7 cpu to launch off an ssd drive is an abomination of software architecture.
But yes, I hear you, "no viable alternative" etc...
... but if forced, bribed or blackmailed to still use it, check if your Windows has DNS cache service enabled.
For me, with DNS cache disabled and powershell executable firewalled, the built-in 5.1.19041.906 version starts quickly, but the new pwsh 7.1.4 would take around 13 seconds to get responsive to keyboard input under the same circumstances. It's so desperate to call home that it would just synchronously wait for some network timeout while blocking all user input, as if threads were a thing for the weak.
My resolution was to stick with the olden powershell 5.
My work computer stored the main profile on a remote server. Another minor problem was that it imported duplicate modules from 4 different profile.ps1 files.
Use the following commands to see where your profiles and modules are stored. Delete the unnecessary profile.ps1 and move all your modules into one directory.
echo $env:PSModulePath
$profile | select *
My loading time was reduced from 21000ms to 1300ms.
Found this solution when I googled having the same problem, but in 2022. Unfortunately this did not fix my issue.
Our systems have a group policy security requirement to "Turn on PowerShell Transcription". The policy requires that we specify "the Transcript output directory to point to a Central Log Server or another secure location". The server name changed and no one updated the policy. As soon as I updated the GPO with the new location, PowerShell opened instantly again.
Press Windows+R
Type %temp% and hit enter
C+A & SHIFT+DEL
That should do it
I have a batch file that calls powershell script and runs it.
Powershell.exe -ExecutionPolicy RemoteSigned -File %1
%1 argument is the file_name.ps1
When i run it from my local drive, the script runs fine.
however, I moved the scripts to run on a shared drive, and when i try running it from there, it gives this kind of prompt before proceeding:
The problem with this is autosys has to bypass this prompt, otherwise its giving error.
But why is this even an issue in the shared drive when if i run the script on local drive it doesn't prompt this? and what should i do to resolve it?
I tried passing in the Unblock-File -Path some_path in powershell but its apparently not recognized cmdlet.
Ok, so after being unable to load the zone identification for the file, I tried ByPass policy instead as follows:
Powershell.exe -ExecutionPolicy ByPass -File %1
THAT made it work....instead of RemoteSigned/Unrestricted...
Based on MSDN article here: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-6
RemoteSigned: Scripts can run.
Requires a digital signature from a trusted publisher on scripts and
configuration files that are downloaded from the Internet (including
e-mail and instant messaging programs).
Does not require digital signatures on scripts that you have written
on the local computer (not downloaded from the Internet).
Runs scripts that are downloaded from the Internet and not signed, if
the scripts are unblocked, such as by using the Unblock-File cmdlet.
Unrestricted: Unsigned scripts can run. (This risks running malicious
scripts.)
Warns the user before running scripts and configuration files that are
downloaded from the Internet.
but my script was copied locally there from one drive to another, its not downloaded from the internet...and in the file properties, there was no "Unblock" button, and Unblock cmdlet wouldnt work for me anyways.
So to avoid the warning, the only thing that worked is ByPass
Bypass: Nothing is blocked and there are no warnings or prompts.
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.
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.