I try to deploy IBM Client Access V7r1 to multiple computers on the network
Silent installation doesn't work for me.
I created a patch file as:
#echo off
net use x: /delete
net use x: \\Path Of client setup file
x:
setup /s /v"REBOOT=REALLYSUPPRESS ADDLOCAL=ALL CWBADDSECLANG=ALL /qn" /l "c:\v7log.txt"
I try to deploy this patch through PDQ deploy, but the problem is that the setup doesn't run silently and asks me to complete the GUI setup.
Is there any way to make it run silently?
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.
Background:
I have several registry keys that are saved and used to update/configure remote PCs in my environment. I may not have deployed the device, previously, but I use these registry keys to update the PC as I fix/repair/etc...I am part of a team of 45 managing about 25,000 workstations and peripherals in our region of the enterprise.
if I use this command from my Win 10 PC to a Win 7 PC, it executes without problems.
psexec \remotecomputer -u domain\adminaccount regedit.exe /i /s "\server\share\directory1\directory2\directory3\someregistry.reg"
psexec starts regedit, imports the above registry file and closes.
If I run that exact same command from my Win 10 PC to another Win 10 PC, I get the following error, from CMD as ADMIN,
"PsExec could not start regedit.exe on REMOTEPC_HOSTNAME:
The system cannot find the file specified."
it can't find regedit??? WTF??
I'm curious why Win 10 is blocking me, as an admin, from importing a registry key?
I've tried reg import as a solution, but I keep getting syntax errors and it can't find the file/pathway.
It's almost like the remote PC, doesn't recognize admin input due to UAC settings?
In testing, I've set the group policy editor to enable remote registry tools, no change. I've enabled remote registry services and set to start the service automatically. I can access the PC registry via remote registry...but psexec just won't work on the remote device.
I can RDP to the device and run the command line equivalent:
regedit.exe /i /s "\UNC\pathway...\etc*.*reg" it executes, without issues.
this proves that regedit is working
Can anyone provide some expertise on this?
add -s flag to psexec to run regedit
The old PsExec trick of running RegEdit doesn't always work. This is because psexec depend on a hidden SMB Administrator service. (Which in any security sense should be disabled.)
PsExec allows redirects of the input and output of a remotely started
executable through the use of SMB and the hidden $ADMIN share on the
remote system. With this share, PsExec uses the Windows Service
control Manager API to start the PsExecsvc service on the remote
system which creates a named pipe that PsExec communicates with. This
named pipe is what allows for input/output redirection back to the
system that launched PsExec.
So instead, in order to remove any TrustedInstaller owned registry Keys, you can use a different tool. This worked:
ExecTI - Run as TrustedInstaller
Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe
I have a very simple command in powershell to start SSH tunnels:
ssh -N -L 28777:localhost:28778 myapp-db
What's the simplest way to make this a service, so I can run:
start-service db-tunnel
etc on Windows 10? I've read an old article on doing this and it involves using C#, which seems way too complex for such a simple task.
PowerShell is not necessary. Here's one way:
Install the Windows Server 2003 Resource Kit Tools package somewhere and get the files instsrv.exe and srvany.exe.
Use srvany.exe to create the service using the ssh.exe program and its parameters using the information in Microsoft help article 137890.
For example:
instsrv "SSH Server" "C:\Program Files (x86)\Resource Kit Tools\srvany.exe"
Of course, specify whatever service name you want and the path and filename of srvany.exe.
Next, use the registry editor to go to HKLM\SYSTEM\CurrentControlSet\Services\SSH Tunnel (or whatever you named the service) in the registry and create a Parameters subkey. In the Parameters subkey create an Application value (REG_SZ type):
C:\Program Files (x86)\ssh\ssh.exe
(or whatever - the path and filename to your ssh executable).
You can also create the values AppDirectory (REG_SZ) to specify the starting directory for the executable, and AppParameters (REG_SZ) to specify the parameters to the executable; e.g.:
-N -L 28777:localhost:28778 myapp-db
You can substitute the use of the NSSM tool mentioned by BenH in his comment if you prefer that tool and are allowed to use third-party software.
To make something into a service, you would need to compile your script into an executable. This can be done via PS2EXE.
What may work just as well for you is making a function in powershell, Start-DbTunnel, and making that import into your powershell session on start. You can do this by loading functions in the foloowing path:
$PSprofilePath\Microsoft.PowerShell_profile.ps1
or for the ISE
$PSprofilePath\Microsoft.PowerShellISE_profile.ps1
Inside those files, I have
$PSprofilePath = "C:\Users\cknutson\Documents\WindowsPowershell"
$items = Get-ChildItem "$PSprofilePath\functions"
#Set-Location "$PSprofilePath\functions"
$items | ForEach-Object {
. $_.FullName
}
Set-Location C:\
Any scripts containing functions, or otherwise will be run each time you open a powershell host.
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
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