My Technical Brain Extension

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 a

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 AutoCle

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!

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.

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...