Showing posts with label powershell. Show all posts
Showing posts with label powershell. Show all posts

Monday, April 04, 2011

[MOSS2007/WSSv3] PowerShell Library - List where a feature is activated

[DESCRIPTION]
Microsoft recommends to deactivate a feature everywhere before you remove the feature from the environment. Unfortunately there is no way of determining where the feature is activated.

To solve this issue, I have created a PowerShell script.

How to use it:
  1. Download the PowerShell script
  2. Open the script in Notepad and edit the <featureid> text to match the id of the feature you are interested in
  3. Run the script
  4. Open the output in Microsoft Excel and use "*" as separator
  5. Based on the Scope column you can determine if the specific feature is a site or web feature

Friday, January 28, 2011

[MOSS2007/WSSv3] PowerShell Library - Check for large lists

[DESCRIPTION]
Microsoft recommends not to use lists/libraries with a huge amount of items, so called large lists. These lists can seriously impact the performance of SharePoint. Unfortunately there is no way to keep track of such large lists from an administrative side.

In order to be able to determine where large lists exist, I have created a PowerShell script.

How to use it:
  1. Download the PowerShell script
  2. Open it in a text editor like Notepad
  3. Run the script
  4. Open the output in Microsoft Excel and use "*" as separator

Tuesday, January 25, 2011

[MOSS2007/WSSv3] PowerShell Library - Overview Request Access Email Address

When creating a site collection or sub sites, it is possible to configure an e-mail address to which SharePoint will send Access Requests mails. When a mail address of a user is configured and that user leaves or changes roles, by default there is no way of checking where that address is used.

To solve this, I have created a script that generates a report with all configured mail addresses:

How to use it:
  1. Download the PowerShell script
  2. Run the script
  3. Open the output in Microsoft Excel and use "*" as separator

Monday, January 17, 2011

[MOSS2007] PowerShell Library - Start Incremental crawl

[DESCRIPTION]
SharePoint 2007 does not support crawl schedules larger than 24 hours. So if you want to schedule a crawl to run every 36 hours, by default there is no way to do this.

At a customer we had a very large environment, which had a huge amount of changes on a daily bases. A crawl during the weekend took just a few minutes, but during the week this increased to 32 hours. Because Microsoft also recommends not to start a crawl when the previous crawl is still running (even though it cannot run two instances of the same crawl, SharePoint does something that can break the index before it detects the crawl is already running), I have created a script that does this for me.

The script checks if a crawl is running and if so quits. If a crawl is not running, it starts another incremental crawl. By scheduling this script every 15 minutes, I can make sure the crawl is never stopped for more than 15 minutes.

How to use the script:
  1. Download the PowerShell script
  2. (If necessary) Change the Content Source name
  3. Run or schedule the script

Tuesday, January 11, 2011

[MOSS2007/WSSv3] PowerShell Library - Site definition inventory

For a project we were wondering which site definitions were used in our environment. I created the following script in order to create this inventory. It loops through all web applications, site collections and sub sites and logs the use definition for each site in a log file:

How to use it:

  1. Download the PowerShell script
  2. Run the script
  3. Open the output in Microsoft Excel and use "*" as separator

Monday, January 10, 2011

[MOSS2007] PowerShell Library - Delete MOSS User Profiles

[Description]
At a customer we had some disabled accounts which were not imported in the profile database but did have an MOSS profile. For whatever reason SharePoint did not deleted these profiles. The customer wanted to delete these profiles without removing all profiles.

To achieve this goal, I have created a PowerShell script.
How to use it:

  1. Download the PowerShell script
  2. Open it in a text editor like Notepad
  3. Change the <url> into the URL of the web application you would like to check
  4. Run the script

Monday, December 20, 2010

[MOSS2007/WSSv3] PowerShell Library - Dump all solutions

Today I am sharing a PowerShell script I have created to export all solutions that have been added to SharePoint Solution Deployment.

A while ago I visited a customer to troubleshoot an issue, however they did very little about any form of documentation. This meant that I had no way of determining exactly which version of solutions they had installed. Using this PowerShell script I was able to export all installed solutions and start testing using the actually installed solutions.

How to use the script:
  1. Download the PowerShell script
  2. Create a folder called "Solutions" in the same directory
  3. Run the script
  4. All solutions (wsp files) are downloaded to the Solutions directory

Friday, December 17, 2010

[MOSS2007/WSSv3] PowerShell Library - Check for large Nintex workflow lists

Over the past months, I have been creating several PowerShell scripts in order to make my life a little easier. This week I thought, why not sharing these scripts with the world and make everybodies life a little easier :-)

Therefore here script number 1: Check for large Nintex workflow lists!

[DESCRIPTION]
When using Nintex Workflow 2007 and activating the site feature, a hidden list is created in that site called NintexWorkflowHistory. Even time a workflow starts, a Log History action is used, etc an entry is written in this log. Unfortunately this list is not cleaned automatically, potentially becoming a feared "Large List". On one occasion a user had created a workflow that added 200.000 items in just five days to that list. Because it is a hidden list, it does not appear in the GUI and you cannot easily see the size of these lists.

In order to be able to determine where large Nintex lists exist, I have created a PowerShell script.

How to use it:
  1. Download the PowerShell script
  2. Open it in a text editor like Notepad
  3. Change the <url> into the URL of the web application you would like to check
  4. Run the script
  5. Open the output in Microsoft Excel and use "*" as separator
The script generates an output file in the following format:
http://examples.sharepoint.com/sites/NintexSite * 8927
http://examples.sharepoint.com/sites/NintexSite/SubSite * 5304
http://examples.sharepoint.com/sites/NintexSite2 * 3840
http://examples.sharepoint.com/sites/NintexSite2/SubSite * 10239

Thursday, January 28, 2010

[MOSS/WSSv3] Change the application pool of a web application

[ISSUE]
How should I change the application pool of a web application

[BACKGROUND]
Recently I ran into a situation where Microsoft had performed a MOSS Risk Assessment Program (MOSSRAP). One of the recommendations of Microsoft was to limit the amount of application pools used on one environment. Depending on your hardware specs, this number will be around eight. However the administrators had created about 50 web applications and configured an application pool for each one of them.

In order to adopt the Microsoft recommendation, the administrator went into IIS and changed the application pools manually. When they tried to add a new server to the farm, this triggered a reset of the configuration on all servers, basically resetting the application pools to the configuration known by SharePoint (each of the web application in its own application pool. This brought down the entire environment for several hours.

[TECHNICAL DETAILS]
During installation/configuration of SharePoint, SharePoint stores all configuration on web applications and application pools. It does that so it is able to deploy everything to a server which is joined to the farm with the correct settings. When you make manual changes to IIS, the settings in IIS do not match the configuration known to SharePoint and you might end up in deep shit.

[SOLUTION]
Unfortunately it is not possible to change the web application/application pool configuration via Central Admin. The only way is by using the SharePoint object model. On the Internet I found an article which described how you could use a PowerShell script to accomplish this configuration change:
Change application pools via PowerShell

This script did have one downside: It changed the configuration in SharePoint, however it did not change the configuration in IIS. To solve this, I found a method added to the SPWebApplication class in one of the Cumulative Updates called ProvisionGlobally. By using this method, you provision that specific web application on all servers running the web front end role. You can download the revised PowerShell script here.

After running this script the old application pools are still present in SharePoint AND IIS. In order to delete them from IIS, you need to write a script to Unprovision them. However the SPApplicationPool class does not have an UnprovisionGlobally method, so you need to run this script on each of the WFE servers.

Tuesday, January 05, 2010

[MOSS2007] Crawling schedule alternative

[ISSUE]
On a customer environment, we were having some issues with the default search scheduler. On this environment we currently have more than 4.8 million items in the index and migrations are still happening. This means that incremental crawls run for several hours and sometimes even more than 24 hours.

By default it is only possible to schedule it once a day maximum (so not once every two days) and according to a Microsoft engineer, it is not advised to run a crawl when a previous crawl is still running. Somehow that can result in a corrupt SSP. Configuring a schedule to run each 15 minutes is therefore not an option.

[SOLUTION]
To solve this issue, I have created a PowerShell script. This script checks if a crawl is running and if not, starts a new incremental crawl. I have scheduled this script to run every 15 minutes.
[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c") | out-null
[System.Reflection.Assembly]::Load("Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c") | out-null
[System.Reflection.Assembly]::Load("Microsoft.Office.Server.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c") | out-null

$serverContext = [Microsoft.Office.Server.ServerContext]::Default
$context = [Microsoft.Office.Server.Search.Administration.SearchContext]::GetContext($serverContext)

$sspcontent = new-object Microsoft.Office.Server.Search.Administration.Content($context)
$sspContentSources = $sspcontent.ContentSources

foreach ($cs in $sspContentSources)
{
  if ($cs.Name -eq "Local Office SharePoint Server sites")
  {
    Write-Host "NAME: ", $cs.Name, " - ", $cs.CrawlStatus
    if ($cs.CrawlStatus -eq [Microsoft.Office.Server.Search.Administration.CrawlStatus]::Idle)
    {
      Write-Host "Starting Incremental crawl"
      $cs.StartIncrementalCrawl();
    }
    else
    {
        Write-Host "Crawl running"
    }
  }
}