Running unverified publisher batch files with powershell - security

In my powershell script I call a handful of batch files. For each batch file I get the "publisher could not be verified warning" and I have to click run for it to work. This poses some problems for automating this script
Without changing settings on the machine itself, can I make this issue go away?

When you right clic on these script files in explorer do you see in the general tab :
Security : this file come from ...
you can remove it using :
echo "">file.ps1:Zone.Identifier
You'll find more explanation here :

Related

Powershell scripts going to sleep

I have a powershell script which loops over each file in a folder and does a lot of "high-computation" tasks on each of these files. I have multiple instances of this script running on my system.
I do use a write-host before starting each of these tasks to see when these tasks start and end.
I started these instances of the script last night and when I came today morning I noticed that some of my powershell terminal were stuck at a write-host command and when I pressed ENTER they wrote that content to terminal and continued the preocessing.
It looks like some of these terminals go to sleep. Why am i seeing this and how can i prevent this?
Disable the "QuickEdit" option in the "Windows PowerShell" Properties window.
Right click the PowerShell window to get the to the Properties window.

Scheduled task not run using x86 version of Powershell

I have written a Powershell script and it is saved in a .ps1 file. It only works with the 32-bit version of the Powershell that is located in
%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe
The script works when I run it manually but it is not run via Windows Task Scheduler. I am running the task as the same user that runs the script. In the Action part of my task I put the above address as Program/script and I write the full path of my .ps1 file as Add Arguments (optional). But it does not seem to work. I have also tried with putting the parent folder of my .ps1 file as Start in value to no avail.
How can I tell Task Scheduler to run my Powershell script using the 32-bit version?
UPDATE: I have to add here that my script actually opens an Excel file, refreshes it and then closes it. I know that using Excel in a non-interactive environment is a bad idea. But I still don't know if this is the reason my script is not run.
Highly suspect Excel is the reason this appears not to work. Have your script do something non-Excel (e.g. create file) and check if this part was executed fine
Two major gotchas I've come across when automating Excel:
Create empty folders if they don't exist (excel automation bug)
Ensure DCOM security settings are configured to allow Excel to run. This is still required if you are running task as same user who manually runs script.
When DCOM permissions are not set correctly and running the script as an automated task, you will get the below error. Saw this as session was transcribed, and transcription output to text file.
New-Object : Retrieving the COM class factory for component with CLSID
{00024500-0000-0000-C000-000000000046} failed due to the following
error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005
(E_ACCESSDENIED)).
You could adopt your script to determine the current powershell version and invoke the same script with the 32bit version if necessary. Put these lines on the top of your script:
# ensure the script is running with the 32bit powershell
if ($env:Processor_Architecture -ne "x86")
{
$psx86 = Join-Path $env:SystemRoot '\syswow64\WindowsPowerShell\v1.0\powershell.exe'
& $psx86 -noprofile -file $myinvocation.Mycommand.path -executionpolicy bypass
exit
}
Note: You can append parameter to the powershell invoke in case your script requires them.

Notepad++ save adds weird characters

I'm trying to run a task on the Worker Role. I added a file named Startup.cmd with the following content:
icacls "PDFs" /grant Users:(OI)(CI)F
EXIT /B 0
All this does is give the Users group full control to the PDFs folder. The task does run because the Microsoft Azure Activity Log window shows the message Details: Starting role... Application startup tasks are running. [2015-02-04T23:39:28Z] when the Worker Role is deployed. I then log into the machine using Remote Desktop and the security on the folder is not as expected. I then try to run the command manually and I see this:
The file has some weird characters which is making the command fail: icacls.
Can Azure Publishing be causing this?
It looks like your script is being saved with a byte order marker. Try saving the script as ascii or as UTF-8 without a BOM. That might work out better for you.

powershell IQY dump script fails

I'm currently working on automating a powershell script to make a dump of a small DB.
The database is accessible through a company Sharepoint and I am leveraging an IQY file exported from said Sharepoint to read the database contents.
When I run the script manually (i.e. calling it from the command line), it works with no issues, but when I try and start the script from Task Scheduler, the following exception is raised:
System.Reflection.TargetInvocationException
the line that is generating the exception is:
$iqy = $xl.Workbooks.Open($query, 2, $true)
Where $xl is a new Excel.Application ComObject, created correctly and $query is a string containing the full file path of the iqy file.
As for my configuration, I'm trying to run my script on a Windows Server 2008R2, using a local administrator user (same user that is supposed to launch the scheduled script), which is also authorized to access the Sharepoint. I'm running Powershell 3.0. I'm not loading any Sharepoint-related snapins.
The only answers I found poking around hinted at granting "Trust" to the IQY file location and the Sharepoint itself in Excel. That did not help.
The Exception also seems to point at a sharepoint issue, but since the script runs fine when started manually, I cannot understand how it could be anything to do with Sharepoint.
Am I missing some intricacy of the Task Scheduler?
Any help would be greatly appreciated.
Never mind, I seem to have found an answer.
If anyone is encountering the same issue, it appear the Excel Com Object has a bug that does not allow it to run from the Task Scheduler if you set it to run regardless of whether the user is logged in.
To circumvent that create the following 2 folders on the machine where the script is supposed to run:
(32Bit, always)
C:\Windows\System32\config\systemprofile\Dektop
(64Bit)
C:\Windows\SysWOW64\config\systemprofile\Desktop
After creating the folders, it worked as expected.
Source: http://social.technet.microsoft.com/Forums/windowsserver/en-US/aede572b-4c1f-4729-bc9d-899fed5fad02/run-powershell-script-as-scheduled-task-that-uses-excel-com-object?forum=winserverpowershell

Application Azure will be Aborted when upload publish file with Startup task

I have created web application and one agent (EXE) with it fetch performance counter using WMI Query (compatible with 32 bit) so i have created one Enable32BitAppPool1.cmd file and add it in startup task, content of that file as per below
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.enable32BitAppOnWin64:true
and set property of that file "Copy Always" as per following this link.
Now when i am going to upload that package to Azure then it will be Aborted or in Buzy mode
Can anyone please tell me the reason of this?
It seems your cmd file not working in startup task.
Two possible solution
1> Create .bat file and try in as a start up task for your webrole.
2> other solution is that, try to run the file (.cmd) using system.Diagostic.process.start(...) from some other exe file and set that exe file as a startup task.
There is absolutely no way to know, based on what you've posted, what's going on.
I'd enable remote desktop on that instance and check out the event logs to try and get a handle on what's happening.
If you can't remote desktop in because your startup task is killing it - then disable the startup task, remote desktop in, and try to run what you think the startup task is doing - but manually - so you can see what's actually going on.

Resources