My Technical Brain Extension

SharePoint 2007 Disaster Recover Disaster

2008-08-21T17:37:00.000-07:00

I am just getting my feet wet in the waters of SharePoint 2007 disaster recovery. I have been checking out blogs that speak of mirroring databases, etc. What I tried to do, in my ignorance, was to move the content and config databases to our DR servers. I attempted to attach to the config database, but this failed due to permissions issues I had with our admin account. After resolving this, I was able to attach and tried moving the central administration site to our DR web server. This would not work, and, in the process of troubleshooting, I applied a hotfix, office2007-kb939077-fullfile-x64-glb.exe. This still didn’t resolve my issue, and so I decided to go back to our test servers to restore that site. However, I ran into problems when I ran the configuration wizard:

An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown.

I ended up running the following command:

stsadm -o upgrade -inplace

and now the website is available, but the central administration site is still unavailable. I now see this error in the event log:

The schema version (3.1.3.0) of the database SharePoint_AdminContent_ on is not consistent with the expected database schema version (3.0.149.0) on . Connections to this database from this server have been blocked to avoid data loss. Upgrade the web front end or the content database to ensure that these versions match.

At this point I notice that WSS SP1 is installed in DR, but not test. After installing SP1 on test I am able to access Central Administration.

Our current DR solution is going to be automated stsadm full backups:

stsadm -o backup -directory \\drserver\backup_dir -backupmethod incremental (only after first running a full backup)

Then on the DR server:

stsadm -o restore -directory \\drserver\backup_dir -restoremethod new -newdatabaseserver

We did this because the site will be moving to entirely different set of servers. During the restore we can specify new db server names, new database names and new administrator accounts. This isn't everything we want, but it will work.

SharePoint 2007 Lacks Workflow Auditing

2008-08-18T18:27:00.001-07:00

I have been working on an interface to our workflows. One of our system requirements is to facilitate viewing workflow history on a per user basis. Specifically, I need to be able to generate a list of all current and past workflows a user, or their team members, has initiated. Then they need to be able to view a detailed history of the workflow. This has lead me to find some frustrating things about MOSS workflow auditing. I have discovered there really no reliable way out of the box to audit workflows within MOSS.

Workflow History

When we associate a workflow with a list, we specify a workflow history list for instances of that workflow. There are some problems with the implementation of this feature. By default, history items are made unavailable after 60 days. This is done by a timer job that deletes the association between the history item and the workflow, and you can work around this in a number of ways. The job can be disabled or you can programmatically set the AutoCleanUpDays setting on the SPWorkflowAssociation to 9999 days, among others. However, If anything happens to the workflow template, such as redeployment or item deletion then the history is lost as well.

There are other issues with workflow history such as the possibility of users with sufficient permissions to alter history. I have read in other blogs, but have not direct documentation, that Microsoft has not intended this to be a permanent record and is more like a log file that gets purged periodically.

WSS Audit Log

MOSS can make use of the WSS auditing features. There is plenty documentation on how to turn this on at the site, list or item levels. We can turn this on, and we can even write custom entries into the Audit Log. However, a log entry is only associated with a site collection, list or item. This means we can not specifically search for a workflow instance without extra lifting. It is possible to store XML data in the EventData property of the SPAuditEntry class, but this is not an efficient way to search if we just want a list of all workflows a user has initiated.

Custom Solution

At this point I have come to the conclusion that a custom solution is in order. I plan to create an audit database outside of MOSS that my workflows will write to and my workflow interface will read. This is not the solution I would like to have, but this is what I believe will be the most efficient and straight-forward way of meeting my requirements.

This post is lacking in lots of specifics and details. I suggest you read through the following blog entries for the full story:

Mattias talks about SharePoint, BizTalk, .NET, TFS, etc. : Tracking/Auditing Events in a SharePoint Workflows

Huge MOSS Workflow Issue... What is Microsoft Thinking!!!! - Dave ...

Huge MOSS Workflow Issue... What is Microsoft Thinking!!!! - Part ...

SPWorkflowAssociation.AutoCleanupDays

What is not a Huge MOSS Workflow Issue (Take 2)

Debugging MOSS Workflows

2008-08-17T18:24:00.001-07:00

An initial issue I had when I first started building workflows was how to debug the workflows. Normally, I would do an attach to process to w3wp and let the debugging process take over. However, if your dll is in the GAC, then this may not work. You'll need to do the following steps to get it to recognize your code

Make sure you are generating a pdb file for your assembly
In Visual Studio click Tools -> Options
Under the Debugging section and uncheck Enable Just My Code (Managed)
Attach to process and start debugging.

This post is a very crude run down on how to do this. I found this information, which is explained much better and with screenshots at:

You Don't Need to Copy PDB Files to Debug in the GAC!

SharePoint 2007

2008-08-17T18:21:00.001-07:00

I am currently programming MOSS (Microsoft Office SharePoint Server 2007) workflows. It has turned out to be quite a learning process. I imagine most of these posts will revolve around MOSS.

First Entry

2008-08-17T18:19:00.000-07:00

This blog is meant to be my diary of technical lessons that I come across, yet do not need often enough to remember. I've tried blogging in the past with minimal success. So, here I go again...