Creative SharePoint

A Link-less Lookup Field

Fri, 08 Jul 2011 14:55:19 -0700

This week I’ve been scouring the web to figure out how to display a lookup field on a page layout as text, without the automatic link to the lookup item.

First, you have to add the field you want as an additional field on the lookup. Click on into the list settings, then the lookup field settings, and add the field you want to display sans link. (for me it was the same field I was looking up: the Title)

[image: blog1.jpg]

To make sure this works like you want it to, check the list settings. You should now see a new column in your list titled something like “LookupFieldName:Title”.

Next, you need to do a little URL encode magic to pull it into your page layout. I would have never figured this out had it not been for Emerson Bruce’s helpful post on a feature that doesn’t seem to be documented anywhere. So you just add this bit to your page layout.

1	<SharePointWebControls:ListItemProperty ID="CustomListItemProperty1" Property="LookupFieldName_x003a_Title" runat="server" />

Notice the “x003a” in the Property attribute? That’s html speak for a colon. So with that, you should have the title text without the link.

Permalink | Leave a comment »

Troubleshooting Delay Problems in a SharePoint Workflow

Thu, 03 Jun 2010 07:42:12 -0700

A workflow does not resume automatically when a delay activity is triggered in Windows SharePoint Services 3.0

via support.microsoft.com

A very helpful KB article by Microsoft for getting workflows up and running again if they seem to freeze for too long after a delay activity.

Permalink | Leave a comment »

Adding Web Parts to a Page Through a Feature

Mon, 24 May 2010 10:03:00 -0700

A couple weeks ago I needed to create a custom site definition to be reused by international offices at my company. After doing a bit of research, and consulting with the SharePoint admin guru J.D. Wade, I decided to create a minimal site definition and do all of the heavy lifting through custom features that would be stapled to the site definition.

When I go, I go all out. So when I decided to go minimal on the site definition, it was going to be all or nothing. In general, this wasn't a problem. I only needed to create a few lists and apply some custom content types to them. The trick came when I found I needed to add web parts to the default page, and also to a couple of sub pages. You can do this without too much trouble in the onet.xml of a site definition. But like I said, I'm no cheater. After a lot of searching, I found these two posts which gave me the basics.

However, this solution limited me to only adding web parts that have .webpart or .dwp definitions. I also needed to add a few list view web parts, so I added this functionality to the code.

Enough of me rambling on, I'm sure you're just dying to see how this beauty works. Well...by all means, allow me.

The Config File

Here's where it all starts. In here you specify the relative path to the page, and inside each page element, there are web part elements. In this example you'll see examples of web parts deployed by a definition file, and also a list view web part.

<?xml version="1.0" encoding="utf-8" ?>
<Configuration>
  <Page FileName="pages/default.aspx">
    <WebPart Id="00000000-0000-0000-0000-000000000000" ZoneId="Left" Index="1" FileName="Example.webpart" Type="Definition" />
    <WebPart Id="00000000-0000-0000-0000-000000000000" ZoneId="Right" Index="1" FileName="" Type="ListView" ListName="Announcements" />
  </Page>
  <Page FileName="pages/AnotherPage.aspx">
    <WebPart Id="00000000-0000-0000-0000-000000000000" ZoneId="Main" Index="1" FileName="Example.webpart" Type="Definition" />
  </Page>
</Configuration>

The Code

Here's the fun part. As I said, most of the code I pulled from these posts. I did clean up a few things (although I am finding it hard to remember what) and I added the option to add a list view web part. Actually, it's not too bad. We are basically looping through some xpath to pull out all the necessary values from the configuration.xml file, then creating the appropriate web part. As you'll notice near the end, I am still planning on adding the ability to add a site members web part if I can ever figure it out. Creating one of those guys in the object model isn't documented very well from what I've seen.

try
{
    // Get the limitedWebPartManager of the page layout file.
    using (SPLimitedWebPartManager wpManager = page.File.GetLimitedWebPartManager(PersonalizationScope.Shared))
    {
        // cycle through each web part and get the different attributes
        foreach (XPathNavigator webPartConfiguration in pageLayoutConfiguration.Select("WebPart"))
        {
            string errorMsg = null;
            string webPartFilename = webPartConfiguration.GetAttribute("FileName", "");
            string webPartType = webPartConfiguration.GetAttribute("Type", "");
            string webPartFilepath = properties.Definition.RootDirectory + "\\" + webPartConfiguration.GetAttribute("FileName", "");
            string webPartUniqueID = webPartConfiguration.GetAttribute("Id", "").ToLower();
            string webPartZoneID = webPartConfiguration.GetAttribute("ZoneId", "");
            int webPartZoneIndex = Convert.ToInt32(webPartConfiguration.GetAttribute("Index", ""));
             // if the web part comes from a definition, open the .webpart or .dwp definition file
            if (webPartType == "Definition")
            {
                // Import the webpart into memory by loading the webpart definition file
                FileStream wpFileStream = new FileStream(webPartFilepath, FileMode.Open,
                                                         FileAccess.Read);
                XmlTextReader wpXmlReader = new XmlTextReader(wpFileStream);
                System.Web.UI.WebControls.WebParts.WebPart webPart = wpManager.ImportWebPart(wpXmlReader, out errorMsg);
                if (!string.IsNullOrEmpty(errorMsg))
                {
                    throw new ApplicationException(
                        string.Format("Error importing webPart '{0}': {1}", webPartFilename,
                                      errorMsg));
                }
                 // set the web part ID
                webPart.ID = webPartUniqueID;
                 // add the web part to the web part manager
                wpManager.AddWebPart(webPart, webPartZoneID, webPartZoneIndex);
            }
            // if the web part is a list view part, add it
            else if (webPartType == "ListView")
            {
                ListViewWebPart webPart = new ListViewWebPart();
                string listName = webPartConfiguration.GetAttribute("ListName", "");
                SPList list = web.Lists[listName];
                webPart.ListName = list.ID.ToString("B").ToUpper();
                webPart.ZoneID = webPartZoneID;
                 wpManager.AddWebPart(webPart, webPartZoneID, webPartZoneIndex);
            }
            else if (webPartType == "Members")
            {
                // TODO: add code to create a site members web part and add it to the page
            }
        }
    }
     // Update the list item.
    page.Update();
     // Check in and publish the page layout.
    string fileOperationMessage = properties.Definition.GetTitle(System.Threading.Thread.CurrentThread.
        CurrentCulture) + ": WebPart configuration.";
    page.File.CheckIn(fileOperationMessage);
    page.File.Publish(fileOperationMessage);
}

Final Thoughts

Make sure you add references to the web part definitions and the configuration.xml file in your feature file like so:

<ElementManifests>
  <!-- Configurations -->
  <ElementFile Location="configuration.xml"/>
  <!-- WebParts -->
  <ElementFile Location="Example.webpart" />
</ElementManifests>

You can also grab the full source of my .cs file referenced above if you'd like to use it on your own SharePoint site. Also if you are looking for example code of the minimal site definition from Andrew Connell's book, look no further (it's in chapter 5 by the way).

Am I Crazy?

I do wonder if I'm taking this whole minimalist thing to an extreme. So I'll put the question to you, oh most intelligent of readers. Do you see any benefits to adding web parts to pages through features, or would it just be easier to add them in the onet.xml file of a site definition? Give me a shout out in the comments.

Permalink | Leave a comment »

~masterurl not working

Thu, 06 May 2010 09:05:00 -0700

You cannot use that syntax; if you use "~masterurl" in your MasterPageFile property, the value must be "~masterurl/default.master" or "~masterurl/custom.master". Anything else will give you an error.

via social.msdn.microsoft.com

Good to know, I was trying to use ~masterurl/myCustomMaster.master in my theming feature. Of course, ~masterurl/default.master probably won't work through the object model anyway!

Permalink | Leave a comment »

SharePoint WTF Moments

Mon, 26 Apr 2010 14:49:42 -0700

The “Microsoft.Build.Tasks.Delete” task could not be loaded from the assembly C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.dll. Could not load file or assembly ‘file:///C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Build.Tasks.dll’ or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, and that the assembly and all its dependencies are available. Platform.StagingAnalysis.Workflow.Services

via sharepointwtfmoments.wordpress.com

Ran into this one today. Good thing the SharePoint WTF Moments blog was there to bail me out!

Permalink | Leave a comment »

Fixing SharePoint 2007's Feature File Deployment

Fri, 19 Feb 2010 13:26:00 -0800

Feature deploying files into SharePoint such as web parts or master pages is something that most developers and admins of any caliber should be familiar with. Also called "provisioning", it's the bread and butter of customizing SharePoint, if you will. Part of the basics. However, there are some serious issues with how SharePoint accomplishes this out of the box.

The first issue I found a year or so ago. I was deploying some web parts through a feature, and went to deactivate the feature. After deactivation, much to my dismay, I found the web parts still deployed in the web part gallery. Not a huge deal, but an annoyance to be sure. So I rolled up my sleeves, dove into the SharePoint object model, and developed a custom event receiver that removed the web parts previously deployed when deactivated.

I found the second issue I found a few weeks ago. I was working on deploying a custom master page and I started hitting problems. Aside from hitting the first problem again, I found that overwriting a master page (or page layout) was impossible using the out of the box SharePoint file provisioning. At first I was trying to override default.master, but then realized the errors of my ways (may the SharePoint gods forgive me). Never overwrite a default master page. Just copy it, rename it, and build your new one from there. You will save yourself future headaches and pain. But I digress, this did get me thinking of the problems with upgrading the master page in the future. If I can't overwrite a page that's already deployed, if I make a change to the master page and upgrade my solution, that means the upgraded master page won't get deployed. Seems rediculous, but it's true. I tested it thoroghly to make sure. I even tried using the IgnoreIfAlreadyExists flag, but found later that that flag doesn't do what I thought it did anyway. So what to do...

Once again I had to roll up my sleeves and dive into the SharePoint object model and create a feature receiver to solve my woes. And with the trusty Google at my side, I was able to pound out a good solution. Thanks to Johan Leino's post on handling the IgnoreIfAlreadyExists attribute, I found most of the code I needed. He wrote a feature receiver that uses LINQ to parse the elements.xml of a normal file provisioning feature. Then if the IgnoreIfAlreadyExists attribute is there, his feature receiver will overwrite the current file. I took that, then added code to deploy a new file, as Johan's code only handled updating a file that already exists. Finally I added the deactivating functionality so that the files that are deployed on feature activation are removed after feature deactivation¹. The beauty of this solution is that it supports all the file properties that a normal SharePoint provisioning feature supports. Just use the normal elements.xml files that you would with any other file provisioning feature, but in your feature.xml, point to the feature receiver assembly instead. And voila, you have a beautiful, upgradable file provisioning solution!

I've attached my final .cs file as well as sample feature.xml and elements.xml files for your SharePoint developing pleasure.

FileContentDeployment.zip Download this file

The only issue I have is that when you don't specify the path attribute in the module element of the elements.xml the feature throws an error on activation. Obviously to solve this you just add Path="" into the module element, but I'd like to fix the .cs file so it checks that the path attribute exists before it tries to read from it. Unfortunately I'm a newbie when it comes to LINQ, so any help on that would be appreciated. Just let me know in the comments.

UPDATE: I just came across this post by Becky Bertram about updating page layouts. So apparently it should work, you just have to watch out for rogue SharePoint Designer tags.

1. This turned out to be a pain because there's a bug when deleting a master page from the master page gallery. I wrote a post on the issue and the fix a few weeks ago. You just have to create a folder, move the files-to-be-deleted into that folder, then delete the folder. In my case I had to do that through the object model, but if you are just testing and need a one time fix, you can do all that through SharePoint designer.

Permalink | Leave a comment »

Too Busy for Standards?

Mon, 01 Feb 2010 12:09:01 -0800

A couple weeks ago I posted some thoughts on standards for SharePoint development. I was hoping to get some feedback from other SharePoint developers on what kinds of things you standardize. However, in spite of some great retweets and lots of page views, no one left me any comments. That leads me to one of two conclusions.

SharePoint developers are so busy that they don't have time for development standards, or...
No one reads this blog!

Granted, 2 is a valid option, especially since I post here semi-regularly at best (though I'm making a concerted effort to change that). However, I am starting to think that 1 has a lot of weight to it. I was originally thrown into SharePoint development, not knowing anything about what SharePoint was or how it worked. And not only did I develop, but I was expected to administrate the farm as well. My team was under staffed for the job, and requests for updates and help were pouring in. Sound familiar?

So this is my attempt to generate a bit more conversation. Because I think standards are important, but we have to evaluate where we are first before we decide where we are going. So where are you guys at? Can you sympathize with 1? Are you too busy for standards? Do you even care about standards, or does it just sound like a waste of time?

Permalink | Leave a comment »

This item cannot be deleted because it is still referenced by other pages...

Fri, 29 Jan 2010 10:43:22 -0800

I was getting this error today while trying to delete a custom master page from the master page gallery. Turns out, it's a known bug! Anyway, the work around, thanks to Katrien, is to create a folder, move the offending master page into the folder using SharePoint Designer or explorer view, then delete the folder. Gotta love SharePoint!

I'm currently working on a feature receiver that will deploy and retract the custom master page. We'll see if this bug affects my retract code...

Permalink | Leave a comment »

SharePoint Development Standards

Fri, 22 Jan 2010 14:09:00 -0800

Recently my team got burned by a SharePoint consulting company that did some shoddy work. I don't blame them entirely, we should have been more specific about our requirements and standards. But at the same time, their work has been making me groan all week. They updated out of the box master pages through SharePoint designer, created site templates using .stp files through the GUI, and they hard coded static links into their custom web parts that broke when we deployed them to a different location.

So all this has shown me the value of good standards and communication. I'm starting with the standards part. Here's my crack at a list of standards for developing custom SharePoint functionality. Although I've been programming in SharePoint 2007 since the beta, I know I still have loads to learn, so I wanted to enlist the help of the internets on this one. What is standard operating procedure for you when you develop in SharePoint? What are the musts, and what are the nice to haves? Give me all the gory object modely details.

My Current SharePoint Development Standards List
General

All custom SharePoint work must be deployed through SharePoint solutions (.wsp files)
We will not import or restore any backups of sites developed by third parties. This shouldn't be a problem as all custom work will be deployed through solutions and features anyway. I wanted to avoid importing hidden designer hacks, but J.D. Wade brought up a good point, we might need to import actual content, so we can't completely write this off.
All functionality and customizations must be documented
Site and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable.

Code

Web parts must be deployed using our custom feature receiver (we can provide source to third parties working with us).
Custom code must be checked for memory leaks using SPDisposeCheck.
For site definitions, use a minimal site definition with feature stapling.
Use best practices when accessing data using the SharePoint object model. See Working with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services Objects

12 Hive Deployment

No out of the box SharePoint files in the 12 hive will be overwritten
Images deployed must be deployed into an RGA/ProjectName folder

SharePoint Designer

SharePoint designer updates are generally not allowed. The only exception to this rule is for creating DataForm web parts.
DataForm web parts must be exported through the SharePoint GUI and solution packaged for deployment as a feature.
Editing out of the box master pages is not allowed. Instead, duplicate an existing master page, make edits, then solution package the master page for feature deployment.
No SharePoint Designer created workflows. These are not portable and cannot be packaged for solution deployment.

InfoPath

custom ASPX forms are preferred over InfoPath forms. They are easier to support, debug, and upgrade.
InfoPath forms must be browser compatible. We run all our InfoPath forms deployed through forms services through the browser.
If the InfoPath form has code behind or needs full trust it must be solution packaged and deployed through central admin. (see my previous post for reference)
If InfoPath form does not have code behind and does not need full trust the form can be manually published to a document library, but the process and location of the document library must be documented inside the form. Just add the documentation text into a section control at the top of the form and set conditional formatting on that section to always hide the section, that way users will never see it.

Update 08-17-2020: Richard Harbridge has taken this list and combined it with other SharePoint development standards from around the internets to form a bigger list of standards.

Permalink | Leave a comment »

In a World Where Chuck Norris and SharePoint Meet

Fri, 25 Sep 2009 12:21:48 -0700

Chuck Norris can modify SharePoint’s application.master in a supportable manner.

via sharingthepoint.com

If there was any doubt as to my geek-ness, this solidifies it. This is about the funniest thing I've seen all week. Thanks for the laugh @JDWade.

Permalink | Leave a comment »

OpenOffice and StarOffice SharePoint Connector

Wed, 16 Sep 2009 09:02:00 -0700

Microsofts SharePoint Server provides a single workspace for teams to organize documents and participate in discussions. The Sun Connector for SharePoint Server makes StarOffice or OpenOffice.org the perfect SharePoint client and adds the support for the ODF (OpenDocument) file format in Microsoft SharePoint Server.

via extensions.services.openoffice.org (via @stoolpigeon)

I'd be interested to know if anyone is using this and how it works.

Permalink | Leave a comment »

SharePoint Development VM Building

Mon, 03 Aug 2009 12:07:00 -0700

For the past couple weeks I've been building (and rebuilding) a cloneable SharePoint development VM. Had to restart originally when I installed the wrong version of Windows 2003 Server, then again when I realized I installed the wrong version of SQL Server (doh!). Third time's the charm though. This time I've documented all the steps, and taken ubiquitous snapshots (I love you vmware) to make sure this will be the last time. It has taken me a while to find all the different pieces I'm using, so I thought I would compile my step by step process here in case it might be helpful to others.

Create the VM
For this I used VMWare Workstation 6.5. My host machine is a dual core Dell with 4 GB of ram, and this setup seems to run fine without lagging my host down badly. For more details on getting better performance, check out this great article by Scott Hanselman.

1 GB of ram
40 GB disk (not preallocated)
Hard disk file split up into 2 GB files on the host (for easy moving and defragmentation)

Installing Windows
For this I used Windows Server 2003 Standard R2 SP2. I didn't do anything special, just let VMWare workstation do the automatic install for me. Once the server came up I did the following:

Renamed the server to mossDevRoot (to match the name I used on the host side for the VM name)
Gave the server the Application Server Role
Turned off IE Enhanced Security (Through "Add Remove Programs" > "Add/Remove Windows Components". Internet Explorer Enhance Security Configuration is an option in this list.)
Installed .Net 2.0 and 3.5 frameworks, along with 3.5 SP1
Installed KB 946517 (to fix an IIS bug)
Installed KB 959209 (this is actually a set of 3 updates for the .Net framework. Make sure to install them in the order specified!)

Create Service Accounts
Here are the various service accounts I created and their purposes. On a side note, after the server is sysprepped and cloned, when you log into it to begin using it, you must first login with the SharePoint service account (svc4shrpnt in my case) so that SharePoint can be configured correctly. Running the SharePoint configuration wizard under a normal user account is BAD!

svc4sqlagent (SQL Server Agent service account)
svc4sqldbengine (SQL Server Database Engine service account)
svc4sqlanalysis (SQL Server Analysis Services service account)
svc4sqlreporting (SQL Server Reporting Services service account)
svc4shrpnt (SharePoint service account)
svc4shrpntfarm (SharePoint farm service account)
svc4shrpntapppool (SharePoint application pool service account)
svc4shrpntsearch (SharePoint Search account)

SQL Server
I used SQL Server 2008 Standard for this. After the main install (and entering the sql service accounts created above in the installation wizard), I installed these patches:

-SQL Server SP1
-SQL Server 2008 Cumulative Update Package 3 - KB 971491

Microsoft SharePoint 2007
Now it's time for the big mamma-jamma. First you need to get things ready for your slipstream install. First you need to create the slipstream install (for MOSS, or just for WSS). One of the tricks I learned is that when you extract the updates to the updates folder, you need to do them in order, first the WSS update, and then the matching MOSS update (if you are wanting to install MOSS that is). So for example, if you were wanting to slipstream SP2, and the June cumulative updates, you would extract the WSS SP2 file, then extract the MOSS SP2 file, then extract the June Cumulative update for WSS, then extract the June Cumulative update for MOSS. As I'm writing this, the most recent set of patches you need for your MOSS or WSS server to be fresh and up to date is listed on this post from the Microsoft SharePoint Team Blog. If you want to keep up to date on SharePoint goings on, subscribing to this is a must.

A few other tidbits I did before running the slipstream installation.

Created folder C:\SharePoint\ with subfolders Indexes, ULSLogs, UsageLogs, SMTPDrop, IISLogs
Pointed IIS Logs to the C:\SharePoint\IISLogs folder (by right clicking on the "Web Sites" folder and selecting "Properties". This will ensure all future websites' logs go to this folder as well)

Now run the installation only, but DO NOT run the configuration wizard. Since we are planning on sysprepping this server, cloning it, and renaming the machine, we can't run the configuration wizard until the server name is set to what it's going to be, as the SharePoint configuration wizard sets up a lot of things based on the machine name. Once the installation is completed (and it will take a little while, especially on the part where it installs the updates), then we can continue. If you get a message like I did the first couple times that says some of the updates were not installed, you messed up the slipstream somehow and will need to recreate that.

Visual Studio 2008
That beautiful tool beloved by developers comes next. After installing Visual Studio 2008 team edition along with the team explorer, here are a couple other patches and addons I installed.

Service Pack 1
SharePoint Server 2007 SDK
ReSharper (not free, but oh so sweet!)
SharePoint Development Environment Modifications
(external tools for Visual Studio SharePoint development which are very handy. I manually removed the ones that deal with deploying solutions to minimize confusing with stsdev build targets, as that is my solution packaging automation system of choice.)

Etc, Etc...
That concludes all the big installs, now for the little stuff that make a SharePoint development VM feel more like 127.0.0.1. I found a few helpful lists out there on the internets, I picked off my favorite things and added a few others.

InfoPath 2007
SharePoint Designer (a.k.a. SharePoint Destroyer, use with care)
Notepad++ (A notepad alternative with tabs, syntax highlighting, and other coolness)
Emacs (The true super hero of text editors, dwarfs even Notepad++. Not for the faint of heart)
PowerShell 1.0 (The Windows command line on steroids. Don't worry, it's legal. I installed this one through the optional section of Windows Update.)
WinMerge (a useful tool for difference display and merging for both files and directories)
Red Gate's Reflector (decompiling and reflecting .net assemblies)
Application Pool Manager (Quickly reset app pools, iis, and SharePoint services)
Right-click a .wsp to add solution reg hack (allows you to right click a .wsp file and click "Add Solution" which runs stsadm -o addsolution)
SharePoint Manager 2007 (SharePoint browsing and editing through the object model)
Fiddler (a web debugging proxy which logs all HTTP(S) traffic between your computer and the internet, and allows you to inspect traffic, set breakpoints, and fiddle with incoming or outgoing data)
DebugView (See how your code is run by the CLR runtime. You just add instructions like System.Diagnostics.Debug.WriteLine(“what I want to display in debug view”), and you see it in DebugView window.)
Firefox (for all that cross browser testing....or just because I love it!)
7-Zip (open source file archiver)
BgInfo (puts server info on the desktop background)
Stramit CAML Viewer (nice little tool to get into the SharePoint object model and display CAML queries)
CAML.NET IntelliSense (adds intellisense for CAML Queries in Visual Studio)

It's Sysprep Time!
This is it, the final countdown, and one of the most frustrating parts for me. There are a couple things you need to do before sysprepping your machine, so that you don't end up slamming your head against your keyboard for hours like I did.

Add the svc4shrpnt account to the local Administrators group.
In SQL 2008 Manager, add builtin\Administrators to the logins section of security and give it sysadmin rights. (this one is huge, and took me forever to figure out, but thanks to an excellent post, I was saved from doing further damage to myself and my defenseless dell lappy. Check out the post for the reasoning behind it.)

Now for the actual sysprepping. I found this helpful article with some downloadable files, but not enough explanation for my lowly developer brain. It took me a bit of digging through the Google, so I'll provide the details that I assume most admins consider common knowledge for the rest of us.

Head on over to this blog post and download the Clonable Assets at the bottom of the post. (If you are already familiar with sysprep, feel free to skip the rest of these instructions, as they are meant for us developer types)
Create the folder C:\Sysprep on your virtual server and copy in the sysprep.inf file.
Create another folder, C:\Scripts, and copy in mossconfig.bat and startsql.bat.
Update the sysprep.inf file
- Make sure the paths to the .bat files are correct
- If you indend to rename your server after you sysprep it, make sure that under the [UserData] section you remove the * after "ComputerName=". That way you will be prompted for a new computer name when you boot up the server after sysprep.
- Also if you don't have a volume license key, make sure to clear out everything after "ProductKey=" so you will be prompted to add a key when booting up the server after sysprep.
Update startsql.bat
- Under the "dropping SQL Server" section, update the server name with your current VM server name
- Update %COMPUTERNAME%\adminmoss to whatever user name you plan on using to configure SharePoint (I used %COMPUTERNAME%\svc4shrpnt)
Install the latest version of sysprep (for Windows Server 2003 SP2)
Browse to C:\Windows\System32 and open deploy.cab
Copy sysprep.exe and setupcl.exe to the C:\Sysprep folder.
Shutdown your server and create a snapshot (if you use VMWare) or backup the thing (if you're using VPC). (I've heard a rumor that you can only re-sysprep a server 3 times before it won't work anymore. I didn't take the time to verify that, but I just decided to create a snapshot that I can go back to in case I need to install any more updates in the future.
Start the server back up and run sysprep.exe. Click on the Reseal button, and let it shut your server down.
Create another snapshot or backup of the server (if you don't have troubles, this is the part you will clone or copy and give out to others on your team, or use in the future when spinning up new servers)
Start up the server, give it a new name, and watch the command prompt as it should successfully configure SQL and SharePoint.

If at this point everything works, then take that last snapshot and clone it off (or if it's a VPC copy, copy it off) and share it out or save it off someewhere else for later use. Then restore the snapshot prior to the last snapshot on the original VM. This will allow you update the root of the VM as new patches come out, then sysprep it up again and copy off the sysprepped server for yourself and others.

If things didn't work, take a deep breath, get up and walk around, get a glass of water, get a good night sleep, then hop back to the snapshot before the last snapshot, and the process we all so effectionatly call troubleshooting.

Lastly...
Here are a couple handy SharePoint solutions you might want to install...

Log Viewer (for viewing the Unified Logging Service (ULS) logs from within Central Admin)
SharePoint Warmup Job

And a huge thanks to KB Man, for pointing me to all the server updates and patches I needed! He is an admin genius, and I couldn't have figured all this out without his help.

Permalink | Leave a comment »

Solution Packaging InfoPath Forms for SharePoint Deployment...the Right Way

Tue, 30 Jun 2009 09:22:00 -0700

First things first, giving credit where credit is due...
First, I want to start by thanking Bart Gunneman for this great article on deploying InfoPath forms as features, and also thanks to Jason Apergis for his post and follow up on deploying InfoPath forms as features. I learned loads from these two posts during this whole process.

The reason I re-wrote all of this instead of just passing you off to their posts was because I was documenting the entire process anyway for my own needs and thought it would be helpful to post all the steps I took. The key piece I added is the bit about the external data connections, which in my opinion is essential to the solution deployment process. If you have to reconfigure the data connection on an InfoPath form every time you want to deploy to a new SharePoint farm, you lose the main benefit of solution packaging in the first place, the easy deployment to multiple farms. But with external data connections managed through Central Administration, SharePoint developers and admins can rejoice together, as they work to develop and easily deploy InfoPath solutions to SharePoint farms.

So without further adieu, here is the step by step process to solution packaging an InfoPath form for deployment in SharePoint 2007.

Solution Setup

Create a new “Empty Solution (no assembly)” solution using STSDEV (I have had problems with choosing the .net 3.5 framework from STSDEV. Maybe I need to upgrade STSDEV, but I’ve found that sticking with .net 3.0 works best for me)
Open the solution you just created.
Delete the “manifest.xml” and the “SolutionPackage.ddf” files from the “DeploymentFiles” folder. (They aren’t necessary because STSDEV recreates those files automatically at build time. And if you leave them and use a source control, it’s a pain to have to remember to check them out every time you build so STSDEV doesn’t puke on a locked file)
Create the “TEMPLATE”, “FEATURES” and feature folder under the RootFiles folder of the project. The Project should now look like figure 1 at the bottom of the post.

Feature.xml File

Create a new feature.xml file in the feature folder and copy this code into it:
<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
        Id="11111111-1111-1111-1111-111111111111"
        Title="Feature Title"
        Description="Feature Description."
        Version="12.0.0.0"
        Scope="Site"
        DefaultResourceFile="ipfscore"
        ReceiverClass="Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver"
        ReceiverAssembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">
    <ActivationDependencies>
        <ActivationDependency FeatureId="C88C4FF1-DBF5-4649-AD9F-C6C426EBCBF5"/>
    </ActivationDependencies>
    <ElementManifests>
        <ElementManifest Location="element.xml"/>
        <ElementFile Location="InfoPathForm.xsn"/>
    </ElementManifests>
</Feature>
Replace the Id in the <Feature> tag with a new GUID.
Replace the Feature Title and Description with appropriate text
In the <ElementManifests> section, replace the “InfoPathForm.xsn” form filename with the name of the InfoPath form you are going to package.

Elements.xml File

Create a new elements.xml file in the feature folder and copy this code into it:
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <Module Name="XSN" Url="FormServerTemplates" RootWebOnly="TRUE">
        <File Url="InfoPathForm.xsn"
              Name="InfoPathForm.xsn"
              Type="GhostableInLibrary" />
    </Module>
</Elements>
Modify the Url and Name parameters in the <File> tag to match the name of the InfoPath form you are packaging.

InfoPath Data Connections
If your form needs to use any external data connection files (.udcx files), go through these steps to make sure the deployed InfoPath form will look for the external data connection file in the Central Administration site that it is uploaded to. The point of this is so that you don’t have to reconfigure paths in the InfoPath form and re-publish every time you want to deploy to a different SharePoint farm. You will still need to create a new .udcx file and upload it to the Central Administration on the new farm, but that's a lot easier than the alternative!

Convert Any Non-External Data Connections to External Data Connections (.udcx files) and upload them to a data connections library
- In InfoPath Designer, click “Tools” > “Data Connections”
- Select the data connection and click “Convert…”
- Enter the URL of any SharePoint Data Connections library that you have contribute access to (don’t worry, this won’t be the final resting place of the .udcx file)
- Select “Centrally managed connection library (advanced)” and click “OK”
For any existing External Data Connections, check to make sure they are set to be centrally managed
- In InfoPath Designer, click “Tools” > “Data Connections”
- Select the data connection and click “Modify…”
- Click “Connection Options…”
- Select “Centrally managed connection library” and click “OK”
- Click “Next >” through the rest of the options and finally “Finish”
Download, update, and upload the External Data Connection files to Central Administration
- Browse to the Data Connections library that you uploaded the External Data Connection files to from step 1.
- Click the drop down next to the name and select “Send To” > “Download a Copy”
- Open the .udcx file in your favorite text editor (let’s hear it for Emacs!) and make modifications.
  - Set the “UseFormsServiceProxy” attribute to “true” wherever it is set to “false”
  - Change any web service URLs to the appropriate URLs (think development, staging, or production environments)
- Browse to the Central Administration of the SharePoint farm you are going to deploy this InfoPath form to.
- Click “Application Management” then under the “InfoPath Forms Services” section click “Manage data connection files”
- Click upload

InfoPath Deployment

If the form is not already there, copy the InfoPath form into the root of the solution. Your solution should now look like figure 2 at the bottom of this post.
Open the InfoPath form in InfoPath Designer
Publish the Form
- Select “File” > “Publish”
- Select “To a network location” for where you want to publish the form template and click “Next”
- For the path, navigate to the TEMPLATE\FEATURES\InfoPathFormFeatures folder in your solution.
- Enter the “Form template name” and click “Next”
- On this screen, clear out any text in the text box and click “Next”. It is possible that a prompt might appear stating: “Users will not be able to open this form because of the security level it requires and because no alternative access path has been specified. To enable users to open the form, you must enter an alternative access path. Click OK, to continue publishing the form template or Cancel to enter an alternative access path." This form can be safely ignored, since when this form is published to Central Admin, the correct permission level will be automatically assigned.
- Click “Publish”
- Click “Close”
Add the published form to the feature folder in your Visual Studio Project
- Right Click on the feature folder and click “Add” > “Existing Item…”
- Select the published InfoPath form and click “Add”

InfoPath Code Behind
If your InfoPath form has .Net code behind, run through these steps. On a side note, as far as I know, InfoPath 2007 form code behind is automatically created in Visual Studio 2005. So if you were previously using Visual Studio 2008 like I am, you might just skip step 1 and manually add the project to your source control. (You are using source control right?)

Add the Visual Studio project for the form code behind to this solution for easy reference
- Click “File” > “Add” > “Existing Project…”
- Select the .csproj file for the InfoPath form code behind and click “Open”
Add the code behind .dll to the Feature folder
According to this post, an error is thrown if you don’t deploy the code behind .dll in the feature folder (yes, even if it is already deployed in the GAC. I haven’t seen this first hand, but hey, I’m a trusting guy!)

Build and Celebrate

Now after all your hard work, you can build the solution. STSDEV will take care of packaging the whole deal up into a friendly little .wsp and SharePoint admins around the world will bless your mother for giving birth to you!

See the full gallery on Posterous

Permalink | Leave a comment »