I am trying to install a msi from a network share remotely.
$app = [WMICLASS]"\\$pcname\ROOT\CIMV2:Win32_Product"
$app.Install($AppPath)
I am getting an err 1619. From some sources say that WMI cannot install remotely with first coping it to the local computer and running it. Some sources use this command to exactly.
That way works great, but I want to install via share so when the developer updates this msi, it will update the installed instances automagiclly. If I install them locally, the update would not be detected (not sure of this).
So I have tried using methods along these lines:
Invoke-Command -ComputerName $pcname{ msiexec /quiet /i "\\appsvr\apps\theapp.msi" }
Those commands seem to go off into the blackhole, those that command works when run locally.
Anyone have a method for doing this that works?
In your last scenario, you're credentials are likely getting lost. This is known as the "double-hop authentication" (or maybe it's "second-hop") problem. You're using creds from ServerA, to run something on ServerB, but it in the end has to connect to ServerC.
There's a fix if you have PowerShell v2 installed everywhere and are willing to accept the implications:
http://blogs.msdn.com/powershell/archive/2008/06/05/credssp-for-second-hop-remoting-part-i-domain-account.aspx
Related
currently, I am trying to get some silent install commands out of the winget cmdlet in order to deploy win32apps via intune. Most of the time I just run the powershell window without admin & when I use the below command (with adobe for example) it prompts for admin credentials and shows me the process i.e. "do you want to make following changes to your pc blabla AcroRdrDCx642200220191_MUI.exe /sAll /rs /rps /l /re"
Is there a different method to see what kind of process a cmdlet triggers? because some apps don´t need admin for their .exe´s and I can´t look up random silent install commands in the internet, neither use so called "tools" to determine them, because either they are expensive as hell or not reliable.
would be nice if someone can help me out here :)
winget install --exact --silent --accept-package-agreements --accept-source-agreements "randomapp"
If you run winget install <package> --verbose-logs you can open up the log file and see which switches were passed to the installer. The log file location is displayed via winget --info.
I've been trying to write a powershell script that automates my windows workspace setup and configuration and am currently stuck trying to redirect input to WSL when executing it for the first time. The core of the problem is that Ubuntu's first launch prompts for a username and password, then logs in to a bash shell. I tried writing down the input lines into a text file like so:
Username
Password
Password
exit
Then, I tried redirecting the input of wsl to the file:
Start-Process ubuntu2004.exe -RedirectStandardInput stdin.txt -NoNewWindow -Wait
The above didn't work as executing WSL just starts spamming Enter new UNIX username: adduser: only one or two names allowed. I tried doing same in CMD with the < input redirection, but the result is the same.
This is not exactly the answer to your question, but in my opinion, ansible is better suited for such a task.
I myself recently became interested in assembling a workspace in wsl and ansible seemed to me the best solution.
Before starting the build, you will need to perform minimal steps (create a user and install several packages, all this can be placed in the readme), but then there will be no restrictions.
You can find several ready-made examples of wsl assembly via ansible on github.
A few ideas for setting the username/password in a new Ubuntu WSL instance:
First, a "PowerShell sendkeys" via COM or Interop might work for this. It's probably the closest in behavior to what you are actually asking.
Second, and perhaps most promising, I just tried this with a new Debian WSL installed from the Store (since I didn't want to mess with my Ubuntu install).
When running debian.exe (like ubuntu2004.exe), I let it run the install, then I Ctrl+C'd out of it when it started asking for the default username/password. At that point, the WSL instance is installed, but with only root. I assume that your script can let the command run for a certain period of time, then kill the process to replicate this.
From your script, you should then be able to run wsl -u root useradd --create-home --user-group --groups adm,dialout,cdrom,floppy,sudo,audio,dip,video,plugdev,netdev --password "encryptedPassword" username (see here for creating the encrypted password). I think that will get you a stock Ubuntu user the way that WSL sets it up.
You'll then need to either create a /etc/wsl.conf file (instructions) letting the instance know that that user is the default, or LxRunOffline lists this as one of its features.
But I'd also throw in that you might just want to keep a "backup" of an existing WSL instance that you start from. Do a wsl --export <distroname> <imagename.tgz>, then you can import it when setting up the new Windows host by copying the tgz over and doing a wsl --import <DistroName> <DirectoryWhereYouwantItToLive> <imagename.tgz>.
If you want, you can keep this image up to date with your desired WSL configuration, so that you don't have to recreate it when you rebuild the Windows hosts. That said, this is where I do follow #Mystic's suggestion of using Ansible to store my WSL "configuration as code". It allows me to not only recreate my WSL instances, but also that same configuration when I set (or reset) a Linode host or another Linux system.
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 have a .msi file in my remote machine which is in a different domain from my local machine. I am able to connect to the remote machine with powershell but how can I install the msi there. The installation process has a lot of inputs to be given along with pressing 'Next' and then again giving a particular input and radio buttons and many more. Thus it is an interactive installation. In my local I am able to do it with [System.Windows.Forms.SendKeys] to imitate the keyboard inputs but as the process will be running in background in the remote machine I don't think SendKeys will work. And 'psexec' is not an option here because in my remote machine I cannot include PSTools with my Powershell. Is there any way to do it with Invoke-Command and -ArgumentList??
If there is a way then how can I choose sequentially whether to input a text in a particular field or click the next button or click any other button within the application window??
I finally got to solve this puzzle with the help of a automation tool called AutoIt. This tool has its own scripting language and can create .exe files to run a particular application and do the corresponding installation steps based on each successive window the application installer pops. After creating the .exe I copied it to my remote machine using Copy-Item or you can use robocopy, then invoked the .exe remotely with the help of psexec. As I had the misconception previously about psexec, it only needs to be integrated with powershell at the local and thus it automatically creates a session of its own and interacts with the remote machine. This is the command to run the .exe on remote machine:-
psexec -i 2 -s -d \\remote_machine_name -u Username -p Password C:\Path_to_exe\installer.exe
You can actually log on to the remote machine and see in the GUI that it is happening. And yes, obviously you need to have the .msi which will be called to be present there in the remote machine so that the .exe can do its job locally in the remote session.
We use TeamCity, nant and psexec to run a command on a remote machine as part of the release packaging. Everything works fine when I run the nant from the console but when running from teamcity psexec hangs (freezes) 50% of the times.
I looked through many forums and there seems to be workarounds that increase complexity of the call and involve loosing the output and the errorcode of the command.
Does anyone know an easier way to run a command on a remote machine?
I don't mind setting up some application on the remote machine, like a telnet server, any advices on what to do?
Thanks
I have solved this issue with a combination of RemCom and a custom MSBuild task called ExecParse.
RemCom, because it doesn't do odd things with STDOUT (thus hanging the build). We used, and ExecParse to capture the output of the remote task, and parse the Exit Code from the output, because the standard MSBuild Exec task does not capture output. Some NAnt equivalent that captures the output would work.
I've detailed this in a blog post: "Continuous Integration: Executing Remote Tasks with TeamCity, MSBuild, RemCom, and ExecParse"
PsExec does some funky things with the standard input/output, and invoking this from Java (which TeamCity is built on) raises all kinds of problems and stability issues. psexec -d did not work wither.
I solved it by using Powershell in Team City.
The script below stops an IIS 7 ApplicationPool on a remote server:
[string]$HostName = "myWebServer"
[string]$Cmd = "C:\Windows\System32\inetsrv\appcmd.exe stop apppool MyMainAppPool”
Invoke-WmiMethod -class Win32_process -name Create -ArgumentList ($Cmd) -ComputerName $HostName
More about it on my blog: http://blog.degree.no/2012/03/executing-commands-and-programs-on-a-remote-machine-using-powershell/
How about putting a (nant) time-out on the psexec and repeat the call until no time-out happens?
I use PSExec with the -d option (don't wait for it to finish) and capture the return code. The return code when you used -d is the process ID of the process running on the remote system. then I use PSList to poll the remote system for the process ID until I don't find it on the remote system any longer.
What happens if you setup TeamCity build agent on remote machine and let it perform the operation locally, passing it the binaries with "Artifact Dependencies"?