Modify your SharePoint application pools using PowerShell

Sometimes your application pools need some maintenance. For instance changing their identity or if you wish to bundle some IIS sites to run under the same application pool so you won’t lose memory to overhead.

Changing the identity of the application pool is rather easy. You can use central admin or the Set-SPServiceApplicationPool cmdlet. Modifying an already running web application’s pool is a little bit different. There’s no cmdlet out of the box, so you’ll have to use the object model. There are 2 great scripts already available on technet. There’s one for changing the application pool, and another one for deleting the unused application pool.

If you wish to just copy paste directly into PowerShell, you can use the scripts below:

Note: the target applicationpool has to be created using SharePoint or else it won’t be recognized!

# Changing an application pool
$apppool = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools | where {$_.Name -eq "Applicationpoolname found in IIS"}
$webapp = get-spwebapplication -Identity http://sharepoint
$webapp.Applicationpool = $apppool
$webApp.Update()
$webApp.ProvisionGlobally()
# Deleting an application pool
$apppool = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools | where {$_.Name -eq "Applicationpoolname found in IIS"}
$apppool.UnProvisionGlobally()

Copy site collection from source farm to target farm

Copying content allows the replication of production data in another environment. The result will be identical environments, which provides the ideal testing environment.

Prerequisites

In order to successfully restore your data, make sure you fulfil the following requirements:

  1. Your account is in the local admin group of the production environment
  2. Your account is in the local admin group of the target environment
  3. The production environment should have the same or a lesser patch version than the target environment.
  4. Both environments should have the same solutions deployed for the source and target web applications.
  5. Your target site collection should not exist to avoid conflicts.

Database restore

Ask the SQL team nicely to restore a copy of the production content database of your source web application where the site collection resides, to the target SQL instance.

Note: Make sure the dbo of the target database is the web application service account of your target farm.

When the target database is restored, it’s time to bring it into SharePoint. Here a first decision has to be made:

Scenario 1: Different managed paths

In the case of different source and target managed paths, it’s impossible to directly attach the content database to the target web application.

  1. In order to successfully attach the content database, create a new –empty- web application. Empty means that there are no site collections created in the attached content databases of the web application.
  2. Attach the restored contentdatabase using the following command:
    Mount-SPContentDatabase -Name "RestoredDatabase" –WebApplication http://emptywebapp/
    

    When the command is finished you get info about your new database:

  3. If your source farm has a different version than the target farm, you have to run an extra command to upgrade your contentdatabase to the right version:
    $db = Get-SPContentDatabase | ?{$_.Name –eq "RestoredDatabase"}
    Upgrade-SPContentDatabase $db
    

    The upgrade process might generate errors. The most common cause is that the source web application’s solutions aren’t deployed on the empty web application. You may safely ignore this error.

  4. Now that your content database is attached it’s time to move the site to the correct web application and managed path.
    Backup-SPSite http://emptywebapp/ -Path C:\TEMP\backup.bak
    Restore-SPSite http://sharepoint/site -Path C:\TEMP\backup.bak

    Make sure that when you restore your site, you target the right contentdatabase. You can use the –DatabaseName switch to specify where to restore the site collection on the target web application’s content databases.

  5. Make sure that you clean up after your restore was successful.
    • Delete the temporary bak file
    • Delete the restored content database
    • Delete the temporary web application
    • Delete the temporary web application’s content database

backuprestoremanagedpath

Scenario 2: Same managed paths

When the source and target web application’s site collection have the same managed path, it’s possible to directly attach the restored database to the target web application. You do this with the following steps:

  1. Attach the restored contentdatabase using the following command:
    Mount-SPContentDatabase -Name "RestoredDatabase" –WebApplication http://emptywebapp/
    
  2. If your source farm has a different version than the target farm, you have to run an extra command to upgrade your contentdatabase to the right version:
    $db = Get-SPContentDatabase | ?{$_.Name –eq "RestoredDatabase"}
    Upgrade-SPContentDatabase $db
    

Result

When a site is moved from production to another environment, all it’s content is moved. Take into account that data might also reside in other places like the managed metadata term store.

Use PowerShell on a Forms Based Authentication enabled Web Application

Sometimes your web application requires a forms based authentication provider. After you implement the new provider and disable Windows Authentication, some of your PowerShell functionality will stop working when you use for instance the farm account. This is normal, because your web application is unaware of any Windows Authentication provider.

A “solution” is to add the account, which you wish to use with PowerShell, as a “Full Control” user to the Web Application User Policy:

web application user policy

After adding the account, PowerShell will get its full functionality again because your credentials are recognized.

When you check on your IIS level, you’ll notice that Windows Authentication will be enabled:

windows authentication enabled

But, because there’s no Windows Authentication Provider configured on SharePoint, you won’t be able to login directly to your sites using a windows account.

This way of working is an alternative to the web application extend method; Which provides a lot of other usages for authentication mechanisms, but aren’t always needed, like in this example.

Allowing PDF files to open in the browser

By default, most standard file types are allowed to be opened in the browser by SharePoint. However, if you wish to open a PDF, hosted in a document library, you get the dialog if you wish to either save the file or cancel. From a user experience point of view this is bad. Your end-user expects that when he/she clicks a file, he/she can work with it.

This behaviour is configured on the web application level at general settings:

browser file handling

Quoting SharePoint’s description:

Permissive Specifies no headers are added, which provides a more compatible user experience.
Strict Adds headers that force the browser to download certain types of files. The forced download improves security for the server by disallowing the automatic execution of Web content that contributors upload.

So changing the setting to permissive would fix things, right? Considering the fact that you disable all the headers for every file type, this is probably a bad idea.

A more secure approach would be to specifically add the PDF file extension as “allowed”. This can be done by using PowerShell. The following code snippet will allow PDF files to be opened on the web application http://sharepoint:

$webapp = Get-SPWebApplication -Identity http://sharepoint
$webapp.AllowedInlineDownloadedMimeTypes.Add("application/pdf")
$webapp.Update()

This method can also be used for other file types.