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

Permission Issues Opening/Editing Office Web Apps Documents SharePoint 2013

Symptoms:

Users provided access to SharePoint through Active Directory (AD) Security Groups may  not be able to edit documents via the browser using Office Web Apps (OWA) without error.

In this scenario, the error from the Word App is: "There's a configuration problem preventing us from getting your document.  If possible, try opening this document in Microsoft Word."

We may find the following information after analyzing the ULS logs from the Office web apps Server and SharePoint Server.

From Office web apps server: (OWA folder in Logs)

w3wp.exe (0x113C) | 0x31C0 | Office Web Apps | WAC Hosting Interaction |
 ajryn | Unexpected | WOPICheckFile,WACSERVER ConfigError [error:The
 SharePoint site appears to have its UPA in an improper sync state.  Please
 contact the SharePoint administrator.  The SharePoint site's WOPI handler
 has determined that the user permissions for this file/folder do not match
 the user permissions when wopiframe.aspx was loaded. |
 WOPICheckFile,WACSERVER | Host Status Code: Unauthorized | Host Error Info:
 SyncUPA, url:https://URLofSite/_vti_bin/wopi.ashx/files/GUID...., host
 correlation:]

w3wp.exe (0x113C) | 0x31C0 | Office Web Apps | WAC Hosting Interaction |
 adhsk | Unexpected | WOPI CheckFile: Catch-All Failure
 [exception:Microsoft.Office.Web.Common.EnvironmentAdapters.ConfigErrorExcept
 ion: The SharePoint site appears to have its UPA in an improper sync state.
 Please contact the SharePoint administrator.  The SharePoint site's WOPI
 handler has determined that the user permissions for this file/folder do not
 match the user permissions when wopiframe.aspx was loaded. |
 WOPICheckFile,WACSERVER | Host Status Code: Unauthorized | Host Error Info:
 SyncUPA

Cause:

http://support.microsoft.com/kb/2908321

This issue can occur if the User Profile Application (UPA) is out of sync.
 If a user profile and the relevant group memberships for the user are not
 synchronized, SharePoint Server 2013 may incorrectly deny access to a given
 resource.

Resolution:

1. Delete the user from the User Profile database in SharePoint Central Administration
1. SharePoint Central Administration
2. Application Management
3. Manage Service Applications
4. User Profile Synchronization Service
5. Manage User Profiles
6. Search for user
2. Go to top level site collection with admin privileges
3. Open the page https://siteurl/_layouts/people.aspx?MembershipGroupId=0 (all users in the site collection)
4. Find your user, right click the name, and copy shortcut (url to the user's profile page)
5. Paste the shortcut into the browser address field and append to it (don't press Enter yet): append Force=True (http://servername/_layouts/userdisp.aspx?ID=25&Force=True), press Enter
6. Click on "Delete User from site collection" link on the toolbar
7. From Central Administration, start a Full User Profile Synchronization.  Wait until this finishes to continue.
8. Check that the user now exists in the User Profile database
9. SharePoint Central Administration
10. Application Management
11. Manage Service Applications
12. User Profile Synchronization Service
13. Manage User Profiles
14. Search for user
15. Add the same user back to the SharePoint group in the Site Collection
16. Test

Use PowerShell to Delete SharePoint List Items Based on Parameters From an External File

Below is a PS script I wrote to take parameters from a .csv file, find matching SharePoint list items based on 2 parameters, and delete that list item. I am also writing to another external .txt file the parameters of any list items that were missed so I can investigate why there was no match (internal administration).

#Import the csv file that holds the parameters we need to filter the SharePoint
$csv = Import-Csv d:\temp\importfilename.csv

#An error file - Clear this file in case anything was there from a previous run Clear-Content d:\temp\checkTheseFailedDeletes.txt

#Get the SharePoint web(site)
$web = Get-SPWeb http://sharepointsite

#Get the SharePoint list
$list = $web.Lists["Your List Name Here"]

$itemsTotal = 0
$count = 0

#Loop through each row of the input .csv file
foreach ($rox in $csv)
{
     #Assign each column's value to a variable
     $thisParam1 = $row.Param1ColumnFromCSV
     $thisParam2 = $row.Param2ColumnFromCSV

     #Build the CAML query and execute it on the list
     $query = New-Object Microsoft.SharePoint.SPQuery
     $query.ViewAttributes = "Scope='Recursive'"
     $caml = "$thisParam1$thisParam2"
     $query.Query = $caml
     $items = $list.GetItems($query)

     #Delete the item from the list if found
     if ($items.Count -gt 0)
     {
          $items | % { list.GetItemById($_.Id).Delete() }
          $caml = ""
          $count++
     }
    
     #Write records that were not found in the list to a text file to manually check if necessary
     else
     {
          $caml = ""
          $writeString = $thisParam1 + ", " + $thisParam2
          Add-Content d:\temp\checkTheseFailedDeletes.txt $writeString
     }
    
     $itemsTotal++
}

Write-Host $itemsTotal "records processed ===> " $count "records deleted"
$web.Dispose()

Farm is unavailable - Registry Error After SP1 or CU

SYMPTOMS:
1.  SharePoint front end or application server is not working (ie .net error msg)
2.  You have an application error something like parameter incorrect server
3.  Errors in Event Log about the server not being part of the farm
4.  Timer jobs in Central Administration are paused for a specific server in the farm

RESOLUTION:
Check the following registry key and change if it contains an incorrect value (Note: it's best to copy value from another server in the same farm if need be)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure\ConfigDB

Key: dsn
Type: REG_SZ

Incorrect Value:
Connect Timeout=30

Correct Value Format: (Note: You can also copy the correct value from the same registry key of another server in the same farm)
Data Source=YOUR_SQL_SERVER_MACHINE;Initial Catalog=YOUR_SHAREPOINT_CONFIG_DB_NAME;Integrated Security=True;Enlist=False;Pooling=True;Min Pool Size=0;Max Pool Size=100;Connect Timeout=15


No need to restart the server.  It will automatically become a member of the farm again.  But you can restart the server if it gives you a warm fuzzy, it was already "down" anyway.  You will notice in CA that the paused timer jobs will start processing again.

Resolving a HTTP/1.1 200 OK Server: Microsoft-IIS/7.5 Error with a SharePoint 2010 Web Application

My team ran into this error on a SharePoint site during a disaster recovery drill while testing after failover and failback:

HTTP/1.1 200 OK Server: Microsoft-IIS/7.5 Connection: close

We have load balanced WFEs so we determined the offending WFE and temporarily manually routed traffic to the good WFE.  Obviously, this is not the desired solution but it worked as a temporary solution to get through the DR drill.

To resolve this issue permanently, we tried detaching and reattaching the content database for the Web Application and, success!  Mad props go out to Mark Rhodes for his post, Resolving a HTTP/1.1 200 OK Server: Microsoft-IIS/7.5 Error with a SharePoint 2010 Web Application, on this same issue.  Thank you, sir!

SharePoint Designer 2010: You do not have permission to do this operation

We had a user who had Design permissions on a subsite trying to edit a page in SharePoint Designer 2010.  The user could connect to the site in SPD.

When the user tried to edit a page he received the following error: "You do not have permission to do this operation.  Ask your web site administrator to change your permissions and then try again, or log on with a user account that has this permission."

After clicking OK, the user received this Master Page error message: "The Master Page file 'location of master page' cannot be loaded.  Attach a different Master Page, or correct the problem in Code view."

Since the Master Page was located at the site collection level and the user was editing in a subsite I checked the user's permissions.  Even though the user had Design permissions to the subsite, the user only had Read permissions at the site collection level.  So my suspicion was that the user did not have the proper permissions at the site collection level.  Thanks to Sue Hernandez's blog post for confirming this and also posting a link to the specific Microsoft KB article to support and confirm.  Microsoft explains:

Overall, an user needs to be a member of one of the following groups at the site collection level to be able to use SharePoint Designer and modify SharePoint content:

· Site Collection Administrators

· Designers

· Owners