I am writing a script to deploy my solution which has some "Site" scoped features. In my script I am trying to get hold of Site Collection first like
$SiteCollection=Get-SPSite http://<server>/mysite
When I check SiteCollection -ne $null it always returns null but the same cmdlet works fine at command prompt.
Do not know whats wrong with my script.
This could be a permissions issue. When run from the command prompt, you have permission to get the Sharepoint site. Investigate how you're running your script when it doesn't work. Make sure the user has permission.
Related
I have a Powershell script assigned to the context menu and it has been running fine. Recently, after I've reset my win10 system and then manually reconfigured my whole system Powershell begins to behave weirdly. The script won't be run correctly anymore, after a lot of researches I find that the problem is caused by the Set-Clipboard cmdlet which being the PCSX version when launching through the context menu where it being the original version if I launch powershell manually. How comes it happen? My script has Set-Clipboard with -value parameter which is not present in PCSX version and it causes an error.
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.
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
I just typed the follow to try and get my SharePoint site:
$spWeb = Get-SPWeb -Identity "http://nycs00058260/sites/usitp"
It gave me the following error
The term 'Get-SPWeb' is not recognized as the name of a cmdlet,
function, script...
The url is correct so why am I getting this error?
I think this need to be run from the Management Shell rather than the console, it sounds like the module isn't being imported into the Powershell console. You can add the module by running:
Add-PSSnapin Microsoft.Sharepoint.Powershell
in the Powershell console.
Run this script from SharePoint 2010 Management Shell as Administrator.
Instead of Windows PowerShell, find the item in the Start Menu called SharePoint 2013 Management Shell:
I have two web applications in SharePoint 2010 that are both empty (and were created the same way through Central Admin). I have a PowerShell script that creates a new site collection and then automates various other tasks after the site collection is created. I can execute my script successfully in the first web application. Then, when executing the same script on the second web application, the following error is rendered:
"The system cannot find the file specified."
After some investigation, I have found that this command was breaking:
New-SPSite -url $newsite -name $newname -template "STS#0"
The specific error is happening because the site template (STS#0) cannot be found. I have also tried creating the site with different templates, but I get the same error. It is acting as if the second web application cannot find any of the site templates.
Thoughts?
Must have been an IIS issue. Rebooted the box and all is well.