At both venues I will be presenting 2 sessions, one SharePoint 2010 and PowerShell together with Niklas Goude and one more business focused session talking about lessons learned from successful enterprise implementations.

The conferences are held in Wellington and Sydney the week after. It’s a two day conference with both national and international speakers. If you are in the neighbourhood I can definitely recommend these conferences arranged by a group MVPs and community supporters.

New Zealand SharePoint Conference
June 9-10, Wellington
http://www.sharepointconference.co.nz/

Australian SharePoint Conference
June 16-17, Sydney
http://www.sharepointconference.com.au/

To register, click on the images below and you will find the registration right there. Will I see you there?

The title will be PowerShell for Microsoft SharePoint 2010 Administrators and will be a book in three parts where the majority of the book is hands on examples on how you use PowerShell to administrate SharePoint 2010. As you probably have heard, SharePoint 2010 is shipped with 500+ PowerShell cmdlets for you as an administrator. And even if STSADM is still available PowerShell is what you need to manage to make life easy further on. Those of you who had the chance to attend the Microsoft SharePoint Conference in Las Vegas last year might remember that one of the key things from Microsoft to administrators was -”learn PowerShell!”.

So what we want to do is to go through the fundamentals of SharePoint, PowerShell and then how you combine them to master your SharePoint 2010 environment.

The coming 5 months will be a big adventure for us, it will be fun but mostly it will be many many hours of writing and hard work. Both Niklas and I will blog about the book and how it take shape, but if you are interested in getting the latest updates, sneak peeks of the content and special offers you should sign up for our newsletter. You can register for the newsletter on our web site created specially for the book: www.sharepointandpowershell.com.

So let’s move on and discuss the latest poll results and the next question.

Last time the questions was: Are you comfortable with you Disaster and Recovery plan?

The results are unfortunately what I expected. Almost one third don’t have one, 38 % says it contain gaps! It’s horrifying that only 23% answers yes to this question. Especially since SharePoint environments now days very often contain business critical information. To bad it’s to often that these Disaster and Recovery questions are first brought up and put on the table first when something bad happens to the environment. Don’t you agree? As long as things works no one complaints. If the farm goes down, well, you will probably hear about it…

So this made me think about how often sensitive or business critical information is actually stored in SharePoint and if any extra precautions are taken or considered when putting that kind of information in there. So, Do you store Business Critical information in SharePoint? And with Isolation I mean in a like separate Site Collection, separate Web application, Web application different application pools etc. to be able to easier restore the information.

What the script does is that you specify a site, list and workflow name and then all workflows will be terminated so that you can run them again. I also included the option to include already running Workflows and also a Restart parameter that could actually be used to start multiple Workflows only.

This is how it looks:

DESCRIPTION:
NAME: Cancel-SPWorkflow
Cancel SharePoint Workflows and restart them if wanted

SYNTAX:
Cancel-SPWorkflow -help
Displays the help topic for the script

Cancel-SPWorkflow -site http://yourSPSite -list Listname -Workflowname YourWorkflow
Terminates all workflows with the specific workflow name

Cancel-SPWorkflow -site http://yourSPSite -list Listname -Workflowname YourWorkflow -Includerunning
Terminates all workflows with the specific workflow name and include running workflows

Cancel-SPWorkflow -site http://yourSPSite -list Listname -Workflowname YourWorkflow -restart
Terminates all workflows with the specific workflow name and then restart the workflow for all items

The key in the script is how we cancel the workflow. That is done through the SPWorkflowManager and done like.

[Microsoft.SharePoint.Workflow.SPWorkflowManager]::CancelWorkflow($Workflow)

And when we want to start a workflow we first need the workflow association and association data together with the SharePoint item to start it for.

$SPList.Parentweb.site.workflowmanager.startworkflow($item, $WFAssociation, $WFAssociation.AssociationData)

You find the whole script here or from the Downloads section

Hope you find it useful

The reason for that is that the rebuild of the index is quite aggressive in it’s nature and does not have any logic built in to it. It simply rebuilds the whole index daily.

If you look at the information from Microsoft at technet (http://technet.microsoft.com/en-us/library/cc678870.aspx) about the job it says:

If you have installed Office SharePoint Server 2007 with SP2:

• The job updates the query optimization statistics by sampling key tables every time that it runs, instead of performing a full scan.
• If you are running SQL Server 2005 or SQL Server 2008, the job rebuilds all indexes in the content databases every time that it runs.
• If you are running an Enterprise edition of SQL Server 2005 or SQL Server 2008, the job rebuilds most indexes online.
• If you are running a Standard edition of SQL Server 2005 or SQL Server 2008, the job rebuilds the indexes offline.
• If you are running SQL Server 2000, the job does not rebuild any indexes.

It actually also specifies that the job should only run weekly if you are running MOSS and daily if your using WSS. I assume that this is just a mistake in the documentation because in all environments I looked in it’s set to daily no matter if you are using Moss or WSS with SP2.

So what happens if you have a large environment where your have backups, or maybe a crawl running at the same time. Or maybe your SQL DBA’s have done their job and have their own reindex and update statistics job put directly in SQL? Well, you could run in to performance problems and extreme slow environments together with backups taking longer time then they should, error messages and maybe even corrupt databases. The later I have not seen but potentially it’s possible.

I’m not saying that bad things will happen to your environment with this job, but more of be aware and have a look at how this is configured in your environment. Maybe you should reschedule it if it’s in conflict with any other SQL job. And if you are not the SQL DBA talk to the DBAs and make sure that they don’t have any similar already in place. If they have, is it better with built in logic where they look at the fragmentation level? Then maybe you should disable the SharePoint Timer Job and only run the job put on the SQL server.

If you want to find out what settings you have you could first look in Central Administration. You have one Database Statistics job for each Web Application and you can see that under Operations and Timer Job Status. In the Timer Job Definition, found at the same place in Central administration, you can see if the job is run weekly or daily.
The best  way is however to use STSADM or SPDiag to get the information on when it’s scheduled. To reschedule jobs you need to use STSADM.

This is how you get the settings you have using STSADM:

stsadm -o getproperty -pn job-database-statistics -url http://YourSPSite

And to set a new value you do like this:

stsadm -o setproperty -pn job-database-statistics -pv “Weekly between Fri 22:00:00 and Sun 06:00:00″ -url http://YourSPSite

Here you have the STSADM reference for this particular task: http://technet.microsoft.com/en-us/library/cc424963.aspx

After some troubleshooting and discussions with Microsoft I finally got confirmed that this is a known issue, not very frequent but still. This is caused when the worker process updates or deletes a cached file and a request comes simultaneously to the WFE server for a MOSS page that contains the cached item.

This is corrected in August Cumulative update even if it’s not specifically mentioned in the kb. http://support.microsoft.com/kb/973400/
Below you see how it was showned in my case.

Event Type: Error
Event Source: Office SharePoint Server
Event Category: Publishing Cache
Event ID: 5538
User: N/A
Description:
An error occured in the blob cache. The exception message was ‘The process cannot
access the file
‘D:\BlobCachefolder’ because it is being used by another process.’

They ran the binaries without any problem but when running the SharePoint Products and Technologies Configuration Wizard the installation quickly failed with the error “Failed to connect to the database server”.

We did all testing and troubleshooting with local Firewalls, loop back checks, accounts etc, and when accessing the internal database with SQL Management Studio it worked fine. In the log files the following was found that did not gave us that much.

The timeout period elapsed prior to completion of the operation or the server is not responding.

After some testing we started to notice that the server was behaving strange when doing other things. It turned out that Firewall ports between the server where we should install WSS 3.0 and AD had been blocked causing problems to authenticate the user that ran the wizard.

But today I wanted to use the script to copy items to a specific folder in that list and it was a bit tricky at the first to understand how this could be done. But after some testing I figured it out and this is how you do.

# First open the list to create the new item in.
$TargetWeb = New-Object Microsoft.SharePoint.SPSite(http://yoursite)
$OpenTargetWeb = $TargetWeb.OpenWeb()
$OpenTargetList = $OpenTargetWeb.Lists[$TargetList]

# Then we need to get the folder name and set the objecttype
$FSObjectytype = [microsoft.sharepoint.SPFilesystemobjecttype]::File
$Folder = $targetweb.GetFolder(http://urlToFolder)

# Now we can create the new Item
$NewItem = $OpenTargetList.items.Add($Folder.Folder.ServerRelativeUrl, $FSObjectytype, $null)

# Add values
$NewItem["Title"] = “Yada Yada”

# Finally use update to create the new item
$NewItem.update()

My intention is to add this to my copy items script later on.

This time we have invited Mattias Hogland from Volvo IT that will share his experiences from managing SharePoint enterprise environments.

The other session will be held by myself together with my colleague Niklas Goude (www.powershell.nu) about SharePoint 2010 and PowerShell.

I know that the majority of you are not from Sweden and Gothenburg, but for you who are, feel free stop by the 23rd of February at Enfo Zipper office. Just register on the community site or send me a message.

Here you find the link to the event on the swedish usergroup web site.

http://www.sharepointcommunity.se/events/sharepoint-usergroup-moete

Hope to see you there!

What it does basically is that it connects to the SPWebService and for each web application it finds it lists all SharePoint Content Databases and writes it to a text file.

This is how you use it:

.\SP-EnumContentDBs -path e:\contentdb.txt

And now in the first version you will get the following information:
Web Application name
Content Database Name
Content Database ID(GUID)
Current amount of sites in DB
Maximum site count allowed in DB
Read only state

But it’s easy to add more attributes by just adding more properties to the code. You can find all available properties at msdn: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spcontentdatabase_properties.

If you want to make a comparison to what you have on the SQL server you can easily run the script, import it to e.g. Excel and then run the following on the SQL server to get the list of databases:

select name from master..sysdatabases where dbid>4 order by name

You can download the script by clicking here, or it’s available at the download section.

Finally thanks to Travis Lingenfelder who with his blog post helped me with some strugeling getting the names out since it differs some from c#.

http://blogs.catapultsystems.com/tlingenfelder/archive/2009/06/26/using-non-cls-compliant-types-in-powershell.aspx