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 24, 2011

The “Soft” part of SharePoint - Part 5, Change Management

This time something that is not really SharePoint related, but this doesn’t make it less important!

Way too many times I have seen “Administrators from the Wild West”, in other words true cowboys. Clicking links and buttons like their lives depended on it. Reading error messages is so 2010 :-)

When troubleshooting an issue, Google is my friend. However not all answers given on the Internet always work or are safe to the environment. What if something goes wrong and I bring down the environment……..in a lot of cases all hell will break loose and I have to test my running skills :-p

How to prevent this?
Every change you are about to implement to a production environment is supposed to be tested before implementation. If you are working as an administrator (server or application), I hope you are familiar with ITIL* and its procedures, especially change management. If not, see the “More info” section and read up real quick!!

In a lot of cases Change Management is seen as a pain in the butt. But when implemented correctly it can save you a lot of work or better yet save you from having to do some overtime. The goal of change management is to make you think well about the change you are going to implement and put those steps on paper:
  • What are you trying to fix/resolve/accomplish?
  • What changes are you going to make?
  • What are the steps to implement the change?
  • What are the components that are affected?
  • What is the impact of the change for users and administrators?
  • Who needs to be notified about the change?
  • What to do if something goes wrong?
  • What to document afterwards?
  • Etc, etc
But that is not all: Two know more than one. Change management is also about having the thought process reviewed by others. These persons can have the same type of skills, but it is also important to have it reviewed by persons with different skills. Maybe your change has impact on their area of expertise you didn’t think of.

Change Management and DTAP
In combination with a DTAP strategy, Change Management can become even more powerful. All changes are tested on the Test environment, the implementation procedure tested on the Acceptance environment, after which the change is implemented on the Production environment.

More info:
ITIL: http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
Change Management: http://en.wikipedia.org/wiki/Change_Management_(ITSM)

Tuesday, January 18, 2011

[MOSS2007/WSSv3] SharePoint 2007 Build numbers (Updated)

Here a list of build numbers for SharePoint 2007. This list is updated until the December '10 Cumulative Update:

12.0.0.6550 - MOSS2007/WSSv3 December '10 Cumulative Update
12.0.0.6548 - MOSS2007/WSSv3 October '10 Cumulative Update
12.0.0.6545 - MOSS2007/WSSv3 August '10 Cumulative Update
12.0.0.6539 - MOSS2007/WSSv3 June '10 Cumulative Update
12.0.0.6535 - MOSS2007/WSSv3 April '10 Cumulative Update
12.0.0.6529 - MOSS2007/WSSv3 February '10 Cumulative Update
12.0.0.6524 - MOSS2007/WSSv3 December '09 Cumulative Update
12.0.0.6520 - MOSS2007/WSSv3 October '09 Cumulative Update
12.0.0.6514.5004 - (Corrected) MOSS2007/WSSv3 August '09 Cumulative Update
12.0.0.6514.5000 - MOSS2007/WSSv3 August '09 Cumulative Update
12.0.0.6510 - MOSS2007/WSSv3 June '09 Cumulative update
12.0.0.6504 - MOSS2007/WSSv3 April '09 Cumulative update
12.0.0.6421 - MOSS2007/WSSv3 SP2
12.0.0.6341 - MOSS2007/WSSv3 February '09 Cumulative update
12.0.0.6335 - MOSS2007/WSSv3 December '08 Cumulative update
12.0.0.6327 - MOSS2007/WSSv3 August '08 Cumulative update
12.0.0.6318 - MOSS2007/WSSv3 Infrastructure Update
12.0.0.6300 - MOSS2007/WSSv3 post-SP1 hotfix
12.0.0.6219 - MOSS2007/WSSv3 SP1
12.0.0.6039 - MOSS2007/WSSv3 October '07 public update
12.0.0.6036 - MOSS2007/WSSv3 August 24 '07 hotfix package
12.0.0.4518 - MOSS2007/WSSv3 RTM


You can find the build number of your environment via:
Central Admin > Operations > Servers in Farm

[SP2010/SPF] SharePoint 2010 Build numbers

Here a list of build numbers for SharePoint 2010. Based on the build number you can determine which patchlevel your SharePoint environment is on:

14.0.5130.5002 - December 10 CU
14.0.5128.5003 - October 10 CU
14.0.5128.5000 - October 10 CU (Incorrect package)
14.0.5123.5000 - August 10 CU
14.0.5114.5003 - June 10 CU
14.0.4763.1000 - RTM

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