Migrate Sharepoint to another server

 copied a production site this way: 

stsadm -o backup -url http://myproductionserver -filename myproductionsite.cab

create a new empty website with the administrator web on the same server using another IP port number or another server like http://testserver or http://productionserver:12345

 (I’m sure you can do that with stsadm too) 

then i restore the backup file 

ststadm -o restore -url http://testserver -filename myproductionsite.cab -overwrite 

Maybe a iisreset may be needed in between the creation or the restore. 

Works great.

SharePoint 2007 Top Developer Utilities

Great Post from Joe

-Return of SmartPart – http://CodePlex.com/SmartPart.  The old classic from V2 days still really improves developer web part productivity.  It’s a SharePoint web part which can host any ASP.NET web user control.

 

-BDC Meta Man – http://www.lightningtools.com  If you are working with Business Data Catalogs, this tool is indispensible.  Yeah, I know there is definition editor that is part of the SDK, however, the free version of Meta Man blows that one away.  Even creates web parts you can customize for Create and Update operations.

 

-WSPBuilder http://www.codeplex.com/wspbuilder  A SharePoint Solution Package (WSP) creation tool for WSS 3.0 & MOSS 2007.  Just break out your features files into a pre-defined directory system run to gen WSPs.  No more coding manifests and DDF files.

 

-SharePoint Solution Installer http://www.codeplex.com/sharepointinstaller Distribute your SharePoint WSP solution files with this installation program instead of a raw script using STSADM.EXE to install and deploy the solution

 

-Useful SharePoint Designer Custom Workflow Activities   http://www.codeplex.com/SPDActivities – This project takes aim at making it easier to create advanced workflows using SharePoint Designer by providing a set of custom workflow actions.  Actions like Lookup User Info (eg. Lookup who a contributor works for) and Copy List Item (eg. Move doc into Records Center repository) really super-charge SPDesigner workflows.  Additionally, the code is available so if you want to create a Workflow in VS, have at it.

 

-SharePoint Content Deployment Wizard – http://www.codeplex.com/SPDeploymentWizard – Content is exported using the Content Migration API (PRIME) as a .cmp file (Content Migration Package) which can be copied to other servers for import. Unlike the out-of-the-box tools, the Wizard allows *granular* selection of content via a treeview.  Great way to create and import CMP files and move your content from production to test to q/a to production.

This form template is browser-compatible, but it cannot be browser-enabled on the selected site

If you do not configure Forms Services before you try to browser-enable a form template, you will be presented with the following message in the Publishing Wizard:

“This form template is browser-compatible, but it cannot be browser-enabled on the selected site.“

1. Install Microsoft Office Forms Server 2007 (independent product) on the SharePoint box if the Office server suite you use is lower than Enterprise (or if you are using Windows SharePoint Services 3.0). The Forms Services support is included in the Enterprise Office Server suite.
2. After installed Forms Server, you’ll have a InfoPath Forms Services section at the Application Management page. To go here, click on Start -> Administrative Tools -> SharePoint 3.0 Central Administration and choose the Application Management tab on the top of the page. Click on Configure InfoPath Forms Services in the InfoPath Forms Services section and check both “Allow users to browser-enable form templates” and “Render form templates that are browser-enabled by users” checkboxes, then OK this page
3. Open your SharePoint site, click on Site Actions -> Site Settings, select Site collection features under Site Collection Administration and activate InfoPath Forms Services support or Office SharePoint Server Enterprise Site Collection feature
4. Start designing your form with the InfoPath 2007 client. In InfoPath, click on Tools/Form Options, select the Compatibility category and check the “Design a form template that can be opened in a browser or InfoPath“, then click OK. In the case if you miss this one and your form is browser-compatible, you get a warning message while publishing your form saying that “The server is running InfoPath Forms Services, but the compatibility settings for this form template is InfoPath only“.
5. Make sure that your form is browser-compatible. You can use the design checker task pane in the InfoPath 2007 client to perform this task.
6. Publish your form onto a SharePoint 2007 library. In the wizard, at step 3, check the “Enable this form to be filled out by using a browser” checkbox and finish publishing.
7. At the end of the publishing wizard, select “Open this document library” and click on Close. This will open the document library in the browser. Click on Settings/Form Library Settings, then click on Advanced Settings and select the “Display as a Web page” option in the Browser-enabled Documents category. If you don’t choose this option, the form will be opened in InfoPath if it’s installed on the client. Otherwise, it’s going to be opened in the browser.

or

Run the following commands to force deactivating and activating the Forms Services feature:

stsadm -o deactivatefeature -filename IPFSSiteFeatures\feature.xml -force -url %SITE_COLLECTION_URL%

stsadm -o deactivatefeature -filename IPFSWebFeatures\feature.xml -force -url %SITE_COLLECTION_URL%

STSADM.EXE -o activatefeature -filename IPFSSiteFeatures\feature.xml -url %Sitecollection_URL% -force

STSADM.EXE -o activatefeature -filename IPFSWebFeatures\feature.xml -url %sitecollection_URL% -force

** NOTE: The “%Sitecollection_URL%” is a place holder that would be replaced with your site collection URL, such as: http://sharepoint/sites/YourSiteCollection

 

This form cannot be opened. It is not workflow enabled

 This is a common thing when beginning to develop InfoPath forms for SharePoint.  What you can do is go to forms management in central administration under applications administration.  From here you will see a list of forms that have been deployed.  Most of the time when you get the error you will see that the form you are talking about still says installing.  This will not change.  What you need to do is verify the forms that you are deploying with your workflow.  You can check this by going to upload and then it will give you a verify button.  This should tell you what you need to fix. 

The problems that I ran into the most are:

1. appropriate security.

2. browser enabled.

3. the form has been published to a network location.

4. when publishing the form do not set an alternative location, leave it blank. (This one was a pain to figure out)

Get namespace and XPath values of your infopath form and fields

You can get the XPath for any field in data source by right-clicking it in the task pane in InfoPath and selecting Copy XPath from the context menu. In order to get the namespace for the form, select Properties from the same menu and click the Details tab on the Properties dialog

On the Data Source task pane, right-click field1 and select Copy XPath from the context menu.
 

Publishing Infopath To SharePoint: “the following url is not valid” Error

A good tip from http://www.sharepoint-tips.com/2007/02/publishing-infopath-to-sharepoint.html

1. Make sure the sharepoint application that contains the site you are publishing to has a site in the root.
   That was my mistake (mistake?). If you create all the sites under a virtual path such as “/sites/”, infopath cannot publish.
   So make sure there is a sharepoint site on the “/” path.
2. Create a new SSP.
   I have no idea why, but people on the internet claimed this solved the problem they had.
3. If the sharepoint in question is of version 2003, uninstall .NET2 from the server. Again, no explanation was given, but one post in the news groups claim it solved their problem (and probably started a lot of others…)

Create a top level site sovled my problem: http://app01:17768/

How to Enable Incoming Email to a SharePoint List or Library

SharePoint users can add content to discussion boards, announcements, calendars, libraries (document, picture and form) and blogs via email. By setting your list or library up to receive email, you can efficiently update the content of your site without having to navigate the SharePoint frontend.

1. Login to your SharePoint site.
2. Navigate to the list or document library you want to email to.
3. Click Settings.
4. Choose List Settings or Document Library Settings respectively.
5. In the far right column, select Incoming Email Settings.
6. Click Yes to allow items to be added through email and create an email address to which you will send the items.
7. OPTIONAL: You can modify other Incoming Email Settings regarding attachments, messages, meeting invitations and security on this page, as well.
8. When finished, click OK to complete the setup. Incoming email has now been enabled for your SharePoint list or library.

Before you begin emailing content to your SharePoint site, there are a few things you need to know. First, if your security settings are set to only accept email messages based on list permission, you must have user permission to write content to the list. In addition, it is required that you email from the email address specified in your SharePoint user profile. Content coming from unknown email addresses or users without “contribute” permissions will not be added to the list or library.

Once you have covered these basic rules, you can add content to document, picture and form libraries by simply sending emails to the specified address with the item attached. It will appear in the appropriate library within minutes. Please note, there is a small bug that requires you include text in the email message or the item will not get added. This can be dummy text, as it will not appear in the library.

In order to email to a SharePoint calendar, the process is slightly different. You have to create and send a meeting invitation from your Microsoft Outlook calendar to the address specified. It will automatically appear on the calendar. To add content to all other lists, send a standard email with the entry title in the subject field and the entry body in the message of the email. The entry will populate the list appropriately.

Engine RunWorkflow: System.IO.FileNotFoundException:

Exceptions in workflow are not logged to the event log as you might hope but to a huge stack of text file logs in %Program Files%\Common Files\Microsoft Shared\web server extensions\12\LOGS.   These files contain all sorts of @#** an dto find the workflow exceptions you will need to search for  “workflow infrastructure” and “unexpected”

Workflow.  Here is a terrifying error I saw in my SharePoint logs: Engine RunWorkflow: System.IO.FileNotFoundException: Could not load file or assembly ‘System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35′ or one of its dependencies. The system cannot find the file specified. Why the hell WF was looking for AJAX I don’t know and I don’t want to know. 

i just installed  “Microsoft ASP.NET 2.0 AJAX Extensions 1.0″ now works

Workflow History

 The workflow data is purged from the MOSS Workflow database table after 60 days.  Based on calls to Microsoft about this, it was by design and for performance reasons.  However, what good it the workflow functionality if proof of the workflows are deleted?  How can companies meet various industry auditing requirements for SOX, ISO, TS, etc?  Microsoft gave us only one option: changing the 60 days to something higher by writing a script modifying the SPWorkflowTemplate.AutoCleanupDays property of the workflow associations.  But this does not bring the deleted data back?  I wrote a comprehensive script for this…let me know if you need it.

 

For anyone seriously considering using the MOSS workflows, I would advise you disable the “Workflow Auto Cleanup” timer service in Central Admin (central –> Operations –>Timer Job Definitions) to prevent any further deletions of your workflow data. 

the workflow will use a hidden list “Workflow History”.  Using .Net code running on one of your servers, get a handle to the list “Workflow History”, set Hidden = false on the list, and update() the list to save the change.  Once the Workflow History list is visible, you can view it on the web like http://server.domain.tld/lists/Workflow%20History/AllItems.aspx.  You can then browse through the history by date to find the workflow you’re interested in.

 

Here is the script.  Compile in VS and run on MOSS box with account that has MOSS admins rights (MOSS service account, maybe).

 

 

Code Snippet

/*

* Date: September 17, 2007

*

* Program Description:

* ====================

* This program is a workaround for Microsoft Office SharePoint Server 2007

* bug #19849, where the AutoCleanupDays is set to 60 by default and by design

* in MOSS installations. This program gives the customer the oppotunity to

* change this number.

* Workflow histories would not show after 60 days by default.

*/

using

System;

using

System.Collections.Generic;

using

System.Text;

using

Microsoft.SharePoint;

using

Microsoft.SharePoint.Workflow;

 

namespace

ShowWFs

{

 

class Program

{

 

static string siteName;

 

static int newCleanupDays, assoCounter;

 

static string libraryName, wfAssoName;

 

static SPSite wfSite;

 

static SPWeb wfWeb;

 

static SPList wfList;

 

static void Main(string[] args)

{

 

 

try

{

 

switch (args.Length)

{

 

case 0: //no parameters entered by user

{

System.

Console.WriteLine(“Error: No arguments entered (site, library, workflow and days)”);

showHelpUsage();

 

break;

}

 

case 4: //correct number of parameters

{

siteName = args[0];

libraryName = args[1];

wfAssoName = args[2];

newCleanupDays =

Convert.ToInt32(args[3]);

assoCounter = 0;

wfSite =

new SPSite(siteName);

wfWeb = wfSite.OpenWeb();

wfList = wfWeb.Lists[libraryName];

 

SPWorkflowAssociation _wfAssociation = null;

 

foreach (SPWorkflowAssociation a in wfList.WorkflowAssociations)

{

 

if (a.Name == wfAssoName)

{

a.AutoCleanupDays = newCleanupDays;

_wfAssociation = a;

assoCounter++;

}

 

else

{

_wfAssociation = a;

}

}

wfList.UpdateWorkflowAssociation(_wfAssociation);

System.

Console.WriteLine(“\n” + wfAssoName + “: “ + assoCounter.ToString() + ” workflow association(s) changed successfuly!\n”);

 

break;

 

}

 

default: //default number of parameters

{

System.

Console.WriteLine(“Incorrect number of arguments entered (“ + args.Length.ToString() + ” arguments)”);

showHelpUsage();

 

break;

}

}

 

}

 

catch (Exception e)

{

System.

Console.WriteLine(“An error has occurred. Details:\n” + e.ToString());

}

 

finally

{

 

if (wfSite != null)

wfSite.Dispose();

 

if (wfWeb != null)

wfWeb.Dispose();

System.

Console.WriteLine(“\nFinished setting AutoCleanupDays!”);

}

}

 

static void showHelpUsage() //help screen

{

System.

Console.WriteLine(“\n\nMOSS Workflow Set AutoCleanup Usage:”);

System.

Console.WriteLine(“====================================”);

System.

Console.WriteLine(“ShowWFs siteURL library workflow days”);

System.

Console.WriteLine(” – siteURL (e.g. http://serverURL/site)”);

System.

Console.WriteLine(” – library (e.g. \”Shared Documents\”)”);

System.

Console.WriteLine(” – workflow (e.g. \”Approval\”)”);

System.

Console.WriteLine(” – days for auto clean up (e.g. 120)”);

}

}

}

Check here for more details

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2041818&SiteID=1

 

Sharepoint Fault Handler in vs 2008

Fault Handler

To get more detailed information about this error, it is necessary to add a Fault Activity (equivalent of a catch block) and to log it.

Select the workflow in the (Visual Studio) Workflow Designer, click on the lower left side of the Designer and click on the Fault Handler:

Another view of the Workflow Designer will show up:

Drag and drop a FaultHandler activity from the Workflow Foundation toolbox into  fautlHandlersActivity1 :

In the property page of this last activity select the FaultType property by browsing the mscrolib assembly:

Select System.Exception:

Now we will log the StackTrace into the workflow history log: drag and drop a LogHistoryList activity into the handler (if you don’t find this activity drag and drop the microsoft.Sharepoint.WorkflowAction.dll assembly to a new Visual Studio toolbox tab) :

Select the logToHistoryListActivity1 and set its HistoryOutcome property to the stack trace value of faultHandlerActivity1:

Rebuild the solution , redeploy (install.bat) and test the workflow.

The trace will show up in the workflow status :