New to Powershell and scripting. I have the following script that intermittently returns the System error 1312 A specified logon does not exist. It may have already been terminated.
Get-Content D:\Logbooks.txt | ForEach-Object {Invoke-Command -computername $_ -FilePath "D:\Folder\Script.ps1"
if (-not$?){Write-Warning "$_ - SQL SCRIPT FAILED"} else {Write-Host "$_ - SQL SCRIPT SUCCESSFUL"-ForegroundColor "Green"}}
I wrote that script to execute this one.
net use \computername\D$ password /User:username
sqlcmd -S .\SQLEXPRESS -o C:\test.txt -d database -i "\computername\D$\Folder\SQL Script.sql"
I am using these to execute a SQL script on remote machines running SQL Express. All computers are running Windows 7. I also created a second admin account on the computer I am running the scripts from and using that login after the net use command. It works fine sometimes but other times I get the error from only a couple of remote computers.
It was a network issue. I was continually running the script to test every little change. Attempting to reconnect to all the remote computers constantly was too much for our small slow network.
Related
I wrote a file.sh to execute psql query from remote sever. I'm stuck on the first step:
ssh user#myserver.com "psql database"
=> Nothing happens
I tried several different syntaxes that I found on google, but nothing works for me.
Manualy I process like this without problem:
$ ssh myserver
$ psql database
database=> select foo from table;
I don't know what I missed (it's my first bash script)
I use SSH every day to connect to my work server and use ssh user#server. From there, I am able to run files, connect to my database, etc.
I have the following code which sucessfully stops a service on remote computer when run from the powershell console.
$Computer = "192.168.24.23"
$service = "Credential Checking LIVE"
Get-Service -ComputerName $Computer -name $service | Stop-Service
When i run this through a SQL Agent job the -ComputerName parameter is ignored.
Any ideas on why this would be and what i can do to rectify the problem?
I'd check the following
1) Does the SQL agent have rights to execute? (like briantist said)
2) Have you tried putting the logic in a script and executing the script from SQL?
3) Did you forget that you had to enter Set-Execution policy while testing?
I have a Powershell script that loops through a list of SQL Servers and creates server logins and database users.
The script runs on a separate server, under the administrator credentials on that server, and connects to the other SQL Servers via linked servers.
#Get administrator credentials
$password = get-content C:\Powershell\General\password.txt | convertto-securestring;
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist "DOMAIN\administrator",$password;
When this script is run manually (either directly through a Powershell window or using a batch file through a command prompt) it works perfectly well. I am logged onto the executing server as administrator when running the script manually.
I then tried to run this Powershell script using an SSIS package on the executing server, using the Execute Process Task to run a batch file. The package was executed from a SQL Agent Job. Although both the job and the package seemed to execute successfully, the DDL statements were not executed against the linked servers.
SQL Agent on the executing server is run under a designated Service Account. SSIS runs under the Network Service account.
Does anybody have any thoughts on what I might be doing wrong? I am happy to provide details of the script or anything else that is required.
Thanks
Ash
UPDATE: ok we have a little more information.
I took out the lines I posted above as I have discovered I don't actually need the administrator credentials I was retrieving.
I logged onto the server with the script on it using the service account. As per #ElecticLlama's suggestion I set a Profiler trace on the destination server. When running the script manually (or running a batch file manually that runs the Powershell script) everything works well and the Profiler shows the DDL actions, under the service account login.
When running a job through SQL Agent (either a CmdExec job or an SSIS package) that runs the same batch file, I get the following error:
'Login failed for user 'DOMAIN\ServiceAccount'. Reason: Token-based server access validation failed with an infrastructure error.'
Anybody have any further thoughts?
Thnaks to everyone for their help. Once I got that last error a quick search revealed I just had to restart SQL Agent and now everything works as it should. Thanks in particular to #ElecticLlama for pointing me in the right direction.
Ash
SQL hangs on this command:
EXEC master..xp_cmdshell 'ftp -s:C:\FTP\connect'
But doesn't hang on any other command I've tried using xp_cmdshell like echo open get and it works just fine, so I know the permissions for SQL Server to the Folder (and Download folder) are set properly.
...And when ftp -s:C:\FTP\connect is executed on the command line, the FTP transfer begins, and completes successfully.
The SQL command that is giving issues on this particular server, worked completely fine on my other server. I'm really not sure what else needs to be done. Does anyone know why SQL hangs when I execute an FTP command besides anything else I've been through?
Most probably Server firewall is blocking the command for the port you are running in the first instance (which might get byspassed using the commandline)
I've written a script to search/download/install Windows Updates on a machine using the Microsoft.Update.Session COM Object. When run locally it works just fine, however when running through a remote session or through Invoke-Command I receive an access denied (0x80070005) error on Microsoft.Update.Session.CreateUpdateDownloader()
I receive the same error if I attempt to create a Downloader object directly, code to reproduce the issue:
$oUpdateDownloader = new-object -com "Microsoft.Update.Downloader"
I am an administrator on the remote machine, and passing credentials (for myself explicitly or any other admin account) to the machine does not seem to change anything.
I've seen this error posted a number of times but there does not seem to be any information on solving the problem...
Any ideas?
When you are in a remote PowerShell session your logon session on this remote computer is flagged as a "network" logon (Logon Type: 3).
For some obscure (security? sell SCCM?) reason, part of the Windows Update Agent COM APIs are restricted to only be usable by locally logged on Administrators.
Using PsExec and Scheduled Tasks have been suggested as workarounds.
IMO, the most seamless (and still secureable) solution is to facilitate the RunAs-style "Local Virtual Account" feature of PowerShell Session Configurations / JEA.
Usually, JEA is used to "restrict" what a user can do on a remote computer PowerShell-wise, but we are (ab-)using it here to gain full access as if we were a locally logged on Administrator.
(1.) Create a new unrestricted (and persistent!) session configuration on ComputerB (remote server):
New-PSSessionConfigurationFile -RunAsVirtualAccount -Path .\VirtualAccount.pssc
# Note this will restart the WinRM service:
Register-PSSessionConfiguration -Name 'VirtualAccount' [-ShowSecurityDescriptorUI] -Path .\VirtualAccount.pssc -Force
# Check the Permission property:
Get-PSSessionConfiguration -Name 'VirtualAccount'
# Those users will have full unrestricted access to the system!
(2.) From ComputerA (local client) connect to our unrestricted session configuration on ComputerB:
New-PSSession -ComputerName 'ComputerB' -ConfigurationName 'VirtualAccount' | Enter-PSSession
[ComputerB]: new-object -com "Microsoft.Update.Downloader" # Yay!
This is a known issue. It appears that there is a bug with the actual COM object itself, as this issue occurs when using VBScript, PowerShell, and even C#. There is a good article that discusses managing Windows Update with PowerShell that can be found here.
The workaround is to set up a scheduled task on the computer and you can invoke that task however you see fit.
Use PsExec (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) to remotely execute PowerShell with a script file:
psexec -s \\remote-server-name C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe \\server\script.ps1
I used the script detailed at http://www.ehow.com/how_8724332_use-powershell-run-windows-updates.html, and I can remotely execute it using psexec to download and install updates.
the windows update code isn't callable form a remote machine. there are a few workarounds out on the web, including using psexec and a script (powershell or vbscript).
I used WUInstall myself and BoeProx has documented a few alternatives and has started a project PoshPAIG. I moved jobs before using this so don't know if it works.
The other solution is to change Windows registry setting using PowerShell and optionally restart wuauserv for the changes to take effect.
For example in Windows Server 2008R2 AutoUpdate settings can be found at:
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update