Tuesday, May 31, 2016

How to Run a SharePoint PowerShell Script From Task Scheduler

Prerequisites:

Go ahead and add this line to your SharePoint PowerShell script.  It is absolutely necessary because we have to run this script in the context of Windows PowerShell and not the SharePoint Manangement PowerShell.

Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue

Make certain the user account running the task has the following permissions:

  • Log on as a batch job rights in the User Rights Assignment section of the server Local Security Policy. These rights could be set on the server itself or by Group Policy if managed from Active Directory – see http://technet.microsoft.com/en-us/library/dd277404.aspx for details
  • Permissions to use PowerShell on the SharePoint farm. You can add these for a new user by running Add-SPShellAdmin –UserName domain\username in the SharePoint 2010 Management Shell console as a current administrator – see http://technet.microsoft.com/en-us/library/ff607596.aspx for details
  • SharePoint permissions to be able to perform the script operation in SharePoint.


1. Open Task Scheduler

Open Task Scheduler and Create a new task. Name it and set your security options.  Check "Run with highest privileges" as most scripts need to run as an admin.





2. Set Triggers

Click on the Triggers tab and set your schedule or event that will trigger the running of your PowerShell script.        





3. Create your Action

Click on the Actions tab and click on New.

Action: Start a program

In the Program/Script text box browse to and select PowerShell.exe


4. Set Argument - this is the important part!

Copy this and paste into the Argument text box.  Be sure to change the path and script filename accordingly but make sure you leave the quotes as they are.  Each parameter is explained below in case you are interested.

-version 2 -PSConsoleFile "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\psconsole.psc1" -executionpolicy bypass -command ".'D:\Scripts\MyPSSript.ps1'"




  • -version 2: Uses the PowerShell Engine 2.0
  • -PSConsoleFile: Specifies the SharePoint Management PowerShell environment to allow SharePoint commands to run within the context of Windows PowerShell
  • -executionpolicy bypass: Opens security to run the script. This security policy will only be in effect for the script running.
  • -noexit: Add this to keep the PowerShell window open while testing.


5. Save and Test

HTTP 403 Error After Applying Microsoft Server Patches to SharePoint 2010 Farm

Symptoms:

After applying KB3045999, or any patch that supersedes KB3045999, users see HTTP 403 error browsing to SharePoint sites.  Nothing specific appeared in the ULS logs.  However, a specific error did appear in the Event Viewer:

Event ID: 8305
Task Category: Claims Authentication
An exception occurred when trying to establish endpoint for context: An error occurred creating the configuration section handler for system.serviceModel/extensions: Could not load file or assembly

'System.WorkflowServices, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. Access is denied. (C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Config\machine.config line 167).

With this information I opened a MS support case.

Below is a summary of this case:

Issue:

After installing the KB3045999 or any KB patch that superseded it, sites are inaccessible with errors referencing permissions on local machine files.


Scope:

This case will be considered resolved and ready for archive when the sites remain accessible after installing KB3045999 and the superseding updates.


Environment:

  • SharePoint 2010: 14.0.7162.5000


Actions Taken:

Gathered initial details on the case and related service requests that were worked in the past.

  • Gathered ULS logs.
  • Reviewed local security policy and groups.
  • Attempted some steps to correct the behavior following the install of the KB3045999, found these to be affective only for KB3045999 and not the superseding updates.
  • Identified a known issu3 related to these updates and found that a registry key can be used to resolve this behavior.  Cause of the behavior detailed below:
    • From security fix 3045999, the updated windows DLL ntdll in passes a new object attribute flag in calls to NtOpenFile/NtQueryAttributesFile made by LoadLibrary.   The registry key UseImpersonatedDeviceMap is set if an application is allowed to call Kernel services with Impersonation. If the key doesn't exist (by default), then it is forbidden.
    • In a normal situation, because SharePoint service account has the permission to load dlls, it should be fine even if impersonation is disabled for kernel calls. But it seems when some 3rd party AV exists, the behavior is changed and the impersonation must be enabled for it to work. Perhaps the AV cleared the original security context of the service account. This can explain why the issue only happens in very few environments. (We received few cases worldwide about the same issue and the environment are all installed with Anti-virus.)


Resolution:

Before or after applying the problem update, create the following item in the registry.
  1. Find: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\w3wp.exe
  2. If the key for "w3wp.exe" does not already exist under Image File Execution Options, then create it.
  3. Inside "w3wp.exe" key, create the DWORD: UseImpersonatedDeviceMap
  4. Set the DWORD value to 1
  5. Perform an IISreset