[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

[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

The “Soft” part of SharePoint - Part 4, DTAP

What is DTAP?
DTAP is a strategy very often used in software development projects. It stands for “Development, Test, Acceptance, Production” (http://en.wikipedia.org/wiki/Development,_testing,_acceptance_and_production). Software is developed on a development environment, then technically tested on the Test environment, user acceptance tests are performed on the acceptance environment after which it is transferred to the production environment.

SharePoint is a product that can function as a platform on which companies can build custom solutions. Even though SharePoint is build on the .NET Framework, it has its own rules and boundaries. Poorly developed code can easily affect SharePoint and cause it to fail or seriously impact performance. From an administration standpoint it is very important to evaluate solutions before deploying them to the production environment (see previous article in this series). A DTAP strategy will assist you in this evaluation process.

But not only with the deployment of solutions a DTAP strategy can be useful. Also the implementation of changes or SharePoint updates/Service Packs can benefit from this strategy. They can first be tested before implementing on the production environment.

Environments: Purpose and permissions
Development
With SharePoint you can have multiple kinds of development environments. Each developer can create his own virtual local environments or you can use a centrally managed environment. Both options have their pros and cons.

Local development environment:
Purpose: Environment used for developing new SharePoint solutions. The environment is under total control of the developer.
Responsible: Developer
Server admin: Developer
Admin access: Developer
Pro : Flexible, can be used everywhere, total control over environment, developers do not impact each other
Con : Developer has to maintain environment the environment (patches, etc), host needs to have sufficient resources, environment used by one developer only

Central development environment
Purpose: Environment used for developing new SharePoint solutions. Multiple developers per environment (2 max), but they can impact each other.
Responsible: Developer
Server admin: TAM
Admin access: TAM & Developer
Pro : Centrally managed according to standards, multiple developers per environment, requires less licenses, no high end local hardware required
Con : Can only be used when connected to the network (direct or VPN), developers can impact each other

Test
Purpose: Environment used for technical testing of developed SharePoint solutions (check if conflicts are present with other solutions) and their deployment instructions. Also changes to the environment (e.g. change of settings or implementation of patch or Service Pack) can be tested on this environment.
Responsible: TAM
Server admin: TAM
Admin access: TAM
Other access: FAM and developers have admin access to SharePoint site collections and if required read access to administration pages

Acceptance
Purpose: Environment used for functional testing of developed SharePoint solutions (check if solutions complies with functional design). This environment should match your PRD as close as possible (setup and configuration wise). Just content can be out-of-date.
Responsible: FAM
Server admin: TAM
Admin access: TAM
Other access: FAM has admin access to SharePoint site collections and if required read access to administration pages

Pre-Production environment
Purpose: Environment that is a very close mirror to the production environment. Mirror on solutions, content, architecture and infrastructure. Meant for testing the implementation to a production like environment and the impact on production. Performance tests can also be done on this environment.
Responsible: TAM
Server admin: TAM
Admin access: TAM
Other access: None

Production environment
Purpose: Environment that is running the production solutions/content and is serving end-user requests.
Responsible: TAM
Server admin: TAM
Admin access: TAM
Other access: FAM has admin access to SharePoint site collections and if required read access to administration pages

Important!!
Make sure that starting with the Test environment and onwards, all environments have the same layers of the topology. The environments don’t have to be equal in number of servers, but if PRD has three layers (database, application. Web front-end), Pre-Production, Acceptation and Test should be three layers as well. Back in 2006 I learned this the hard way (http://share-point.blogspot.com/2006/02/problems-with-search-functionality.html). Our Acceptation environment consisted out of two servers and Production out of three servers……..Installation of Windows 2003 SP1 worked just fine on Acceptation, it didn’t on Production and broke search. It took me two weeks to find out the issue and another two weeks to clean up the mess I created during troubleshooting :-)

Explanation:
Purpose : Describes the purpose of the environment.
Responsible : Who is functionally responsible for the environment.
Server admin : Who is the administrating party of the environment and has to make sure that the environment is patched, secure, backed up, etc.
Admin access : Who has administrative access to the server.
Other access : Which other access is granted to which parties.
TAM : Technical Application Management
FAM : Functional Application Management

[SP2010] Site templates in SharePoint 2010

In SharePoint 2007 it was possible to create a site template (stp file) of a site and use that template to create new sites. When you downloaded that stp file and added it to the global template gallery by using the stsadm command addtemplate, you were able to create new site collections based on this template.

With SharePoint 2010, this mechanism has changed a bit. Site templates are no longer stp files, but when creating a template of a site SharePoint creates a Sandboxed solution which is placed in the sandboxed solutions gallery.

A possible solution
On his site Todd Klindt explains how to use these solutions to create new site collections based on this template.

Unfortunately this method has the downside that it requires manual actions, each time you would like to use the template.

An alternative
Another solution is to add the solution to the Farm Solutions gallery. This has the advantage that you don't have to upload the solution each time. But the downside is that when adding the solution, the template does not become available in the template selection, but is added as a feature to all site collections. During site collection creation you therefore still need to activate this feature before you can use the template.

The solution
Then how to solve this issue farm wide......simply by making a small change to the solution. The template feature in the solution is scoped to a site collection by default and therefore uploads the template to the site collection template gallery. If you change the scope of the feature to Farm and then activate that Farm feature, the template is globally deployed and available for selection during site collection creation!