The direct approach is to open the settings of your list or library, and add a new column of type “Choice”. Populate the choice options in the settings, and choose your choice “type” (dropdown, radio, checkbox). The down side to that is in order to edit or add new choices, more than contributor access is required. In many cases, the power users want to be able to add new choices without having to ask for assistance, but we don’t necessarily want to grant additional access in most cases.

Enter the Lookup field.

I create a new custom list and give it an appropriate name like “Types”, “Choices”, “Business Unit Names” – you get the idea. If the site will have multiple choice options that I’ll want to “delegate” user control on (to a specific few users, of course) I’ll name it something more generic. The column names don’t matter – you can keep the “Title” field as-is, or you can rename it (e.g. to something like “Business Unit Names”). If you’re going to want to use this single list for all of your choice fields in a site, add more columns (of type “single line of text”) with names that will be intuitive for your users. Also, make sure to make NONE of the columns a required field! This is important if you’re using multiple columns.

So, for example you’ll have a list titled “My Choice Field Options”, with columns “Choices A”, “Choices B”, “Choices C”, etc. Again, none of which are required. Now, each column can have any number of “options” entered – all independent of each other. It looks counter-intuitive at first glance, but works like a charm.

My example list with some options populated

Now that that’s all setup, navigate to your list or library where you want to use these options. Create a new field – of type “lookup”. Set the field requirement, title, and description as you like. For the “get information from” field, select your new custom list that you’ve prepped.

NOTE: This will only work if the list or library using these choices is located in the SAME site as the custom list containing the choice options. See below for more on this.

For the “in this column” field, select the appropriate column from your prepped list (“Column A”, “Column B”, etc.). Allow multiple items if you prefer, and click OK.

Now, as soon as options are added to your new custom list, there will be options available to choose from (as seen in my screenshot above). You can reuse these columns on lists and libraries throughout your site without duplicating the data! As soon as a new option is added to your custom list, it’ll be available for all of these places.

The most access that you will need to grant is Contributor. Heck, you could be a real stickler and create a custom permission level to allow read + add, but not edit or delete. The users will be able to see the options available, and add to them, but nothing more. (Admittedly, this is not the best option if you’re using a single list to host multiple choice field lookups.)

Going a step further…

The plain old “lookup” will only work within the same site. But what if you want to use and reuse these lookups in your subsites too? Site columns!

Choosing the location of a lookup field is a no-brainer since it has to be located within the same site that it’s content will be consumed. However, the location of your custom list when using site columns needs a little forethought. Consider the highest level where you’re planning on using it, and who will need to have access to update the choices.

Let’s just say that we setup our custom list at the root of our portal. We create it, setup the columns, and grant the necessary access. Initial prep work done.

Now go to Site Actions > Site Settings > Galleries > Site columns > Create

Set your column name as appropriate. Set it as type “lookup” the same way mentioned earlier. I like to put my site columns in a custom group – usually the name of the client or department to help me find them later. And that’s it for the prep work. To put it to use, you’ll need to take a slightly different approach.

Open your list or library that will need to use this site column. This can now be within the same site, or any sub-site. Open the list settings, scroll down to the “Columns” section and “Add from existing site columns”. If you put it in a custom group, you can filter the available site columns by group to find it easier. Select the site column, click the “Add >” button and click OK. If you don’t like the site column’s name or description, once it’s added to your list or library you can go back to the list settings and click on the column’s name to edit those properties, set it to a required field, allow multiple options, etc.

One weird thing to note.

In either case (plain lookup, or lookup by way of site column), since these “options” are actually referring back to list items, these options will have links back to the original item… It’s confusing to the users that may stumble onto it, and click the link to see what it does, but makes complete sense from an admin/configuration perspective. It’s harmless, but a potential cause of questions or confusion. I haven’t had the time to figure out a way to strip that link. If you know of one that doesn’t require coding your own custom web part from scratch, let me know!

Screenshot of underline example

Keep it clean.

I can be a bit of a perfectionist at times. I like to keep things clean and orderly, and remove or disable anything unnecessary. While you’re configuring the custom list, remove it from the QuickNav – the normal portal users don’t need to be aware of it. Disable attachments and folders. That should be it!

A long while ago I learned the hard way never to create a folder titled “Forms” within a document library. SharePoint will let you “create” this folder (even though it already exists as hidden for internal purposes), but then will not let you delete it, rename it, and will exhibit other weird behavior.

This week I’ve found another interesting combination. If you create a site and set the URL to “con” the site will be useless. You can set the title to “con” – you just can’t set the URL to that value. I still haven’t figured out why – I haven’t found any mention of this anywhere online.

It’s not related to the template, site permissions, which parent site you’re creating it in, or title. There were no other sites or lists with that name or URL anywhere I’ve tested to cause a conflict. I can use other 3-letter titles, just not that specific one. I’ve tried creating a site with this URL in various locations on the portal as well as another portal entirely. Both portals are running MOSS 2007, one is using AD authentication while the other is using FBA.

On one portal I receive an error that the resource cannot be found when trying to complete the site creation, or attempting to view anything inside the site (including the site settings). When trying to open the mostly-created site in SharePoint Designer I receive an error that “the version of windows sharepoint services running on the server is more recent than the version of sharepoint designer you are using” – only on this one site. I receive just a blank page on the other portal when trying to open the site.

I’m assuming that this is similar to the “Forms” folder issue that I’ve run into before, though I don’t have any hard evidence.

Has anyone else experienced this behavior? Have you found any other “problem” names or URLs?

Update!
Thanks to my awesome friend Jim, this does appear to be a known issue… of sorts. I’ve tested this with some of the other “reserved words” (e.g. “AUX”) and confirmed that it’s consistent. See here for more details:
http://www.windowsitpro.com/article/dns/windows-xp-and-2000-tips-tricks-update-august-26-2002.aspx

This is a very long, and involved process – so far (it’s still in process) using nothing more than out of the box commands, and SharePoint Designer.

The original data is in a single WSS site collection. Their end goal is to break things up and better organize their content using multiple site collections. Initially we were hoping to be able to use stsadm’s export/import to migrate the original sites over individually, and directly into their end destination in MOSS. After much research and testing, that does not appear to be possible.

• The “backup” and “restore” options for stsadm are available in both 2003 and 2007, but they will only work for an entire site collection. This was not an option for us.
• The stsadm “export” and “import” options that will save permissions, versions, and modified meta – is only available in 2007.
• 2003 has “smigrate”, but 2007 does not.
• “smigrate” saves in a file format that’s incompatible with 2007′s stsadm “import” – so we can’t combine the two to go directly from one to the other.
• SharePoint Designer has backup & restore capabilities, but you can’t use it as a method of upgrading a site. The SPD backup on 2003 creates the same file type as the “smigrate” method, while creating the same file type as the stsadm “export” method for a 2007 backup. You can only use SPD’s backup/restore to migrate within the same type of portal, and of the same version (e.g., WSS 3.0 to WSS 3.0, MOSS 3.0 to MOSS 3.0, WSS 2.0 to WSS 2.0 – you get the idea). We need to go from WSS 2.0 to MOSS 3.0, so this is definitely out.

Migration options then become:

1. Backup & restore the entire portal to the new environment. Then perform the cleanup.
• This will do an in-place upgrade of the portal’s content.
• We would either need to take one long “outage”, or do this in batches and backup/restore the database multiple times to make sure we have the most current data.
2. Or the slower, more tedious manual methods:
• Save each site as a template, copy over, and recreate site using new template.
• Save each List and Library as a template individually, and copy them over…
• Or manually recreate each site, and each library, and copy/paste the content across.
• Down sides to all are that the templates have file size limitations (but you may be able to get around this by changing settings in Central Admin).
• It’s SLOW.
• You lose all of the creation/modified meta.
• Web parts will most likely need to be recreated – at least on each site’s landing pages unless you can copy the default.aspx file over without too much fuss.
• Beware of custom columns using these methods if not saving as templates.
• Custom column meta may be lost with file types like PDFs when copying/pasting across.
• Also – you will need to recreate your views if not saving as templates.

The client has already been through a SharePoint upgrade to 2003 – and lost all of their created/modified meta. Retaining as much meta as possible was our priority, so we opted to go the first route. We performed a test migration and had hashed out a plan for the real migration. The steps have since evolved quite a bit through a lot of trial & error. Also, as things progressed we found that some of our previous steps had stopped working properly so we had to get creative and alter our migration steps accordingly.

** Don’t forget to run the pre-upgrade scan tool before starting! **

This process becomes significantly faster and easier if you perform a thorough review of your content, make note of the permission structure (where it’s inherited, where it’s not), plan out the starting location vs. final destination, remove any DVWPs (data view web parts) from web part pages, etc.

Now, let’s get started.

First – Backing Up:
Scheduled an “outage” with the users (in quotes because the data would still be available to view). We attempted to set the site collection as read-only via SharePoint’s commandline tools, but GetSiteLock didn’t appear to be a valid command for 2003? We ended up locating the content database in SQL (2000) and setting the database read-only very similar to these instructions. When we were satisfied that the old portal was no longer being written to, we used SQL to backup the database, copied it over to the new location, and restored it to a new database in SQL 2008.

Second – Upgrading:
The upgrade was actually the easiest part (though I’m sure there’s an easier, more direct method than the following steps).

1. Login to Central Admin and create a new temporary site collection.
2. Remove the database that was created for this site collection.

stsadm -o deletecontentdb -url http://MyPortal/MyTempSiteCollectionURL/ -databasename SPAutoDBName -databaseserver MySQLServerName

3. Set the old portal’s database that was restored to the new environment to be used as the temporary site collection’s database.

stsadm -o addcontentdb -url http://MyPortal/MyTempSiteCollectionURL/ -databasename MyOldPortalsDBName -databaseserver MySQLServerName\MyCustomInstance

• This will take quite a while depending on how much content you have. This is where it upgrades your content.
• We actually had to “deletecontentdb” and then “addcontentdb” a second time during our initial test. Not during the real migration though. If your site collection doesn’t seem to have content, give that a quick try.

Third – Preparations:
We found that we had to perform the following steps to each site to clean things up and “2007-ify” everything.

• In Site Actions > Site Settings
• Reset all pages to the site definition.
• Reset the theme to the default.
• In some cases this is already done.
• In some cases it appears to be done, but isn’t.
• In most cases, it’s very obvious that it needs to be done.
• Inherit the global navigation.
• Grant full control to any accounts that will be used to perform any exports/imports, etc.! This will save headaches.
• It’s a good idea to look through the web parts on your pages for web parts with errors and delete them. Don’t forget to check for this in your “closed” web parts or you may run into warnings/failures in your export/import.

In our case, to help down the road we had to also:

• Add the accounts that we were using to the Site Collection Admins.
• The upgraded portal was not Publishing. We enabled the Enterprise features to have access to the “Manage Content & Structure” functionality.
• Site Actions > Site Settings > All Site Settings
• Site Collection Features > end enable the Office SharePoint Server Enterprise Site Collection features.

Fourth – The Migration!
Initially we exported and imported via stsadm, but it was giving us errors on the first few sites that we tried. I don’t recall the exact details at this point, but we eventually tried SharePoint Designer which seemed to do the trick.

• Open SharePoint Designer.
• If the account that you’re logged into your computer with does not have appropriate access, right-click on the SPD shortcut and “run as…” an account that does.
• File > Open Site > type in the URL of the site to be migrated > click “Open”
• In the SPD menus open Site > Administration > Backup…
• File > New… > Web site
• Specify “Empty Web Site” and enter the full URL to the destination site on the appropriate site collection.
• Site > Administration > Restore…

Voila! If you don’t run into issues with file sizes, or a number of other misc. errors, you have just upgraded & migrated your first site.

Fifth – Oops, Missing Documents:
The above steps seemed to work just fine for a while. Then when reviewing our migrated sites in more detail, we started noticing that Document & Picture Libraries were randomly missing files. Lists appeared fine.

None of the libraries in the original portal had versioning or content approval enabled or required. However it seems as though during the upgrade process SharePoint believed some of the files to be drafts? This is the only explanation that I have been able to think of that makes sense.

The solution was to use stsadm to export the sites. SPD is essentially using stsadm already, but with some default settings. In order to set other options (like setting the version levels to export) you will need to use stsadm:

stsadm -o export -url http://MyPortal/MyTempSiteCollectionURL/MySite/ -filename MyFileName -versions 4 -includeusersecurity

I won’t spell out the details of importing via stsadm because…

Sixth – Oops, Now What Happened to the Meta?
That worked great. For a few sites. Then for some reason (still to be determined?) all of the created/modified meta was reset to the import user account and timestamp.

After further testing, the best combination appeared to be:

1. Export via commandline as above.
2. Using SPD, create an empty site at the destination.
3. Restore using SPD.

Seventh – Where’s the Love for Workspaces?
Workspace migration was a different story. They seem to be tied to their parent site and could not be exported & restored like the other sites. Given that I could not find an option in stsadm to “include children” – I assumed that this was not available. When in fact, stsadm appears to include child sites and workspaces automatically.

Before we figured this out, we started using SPD and checked the option to include subsites. This lost us a few of our files, but in those cases we weren’t overly concerned about the meta and manually copied those over.

Another option (especially if you’re relocating the workspace within your site structure) is to:

• Use stsadm to export the parent site
• Use SPD to create an empty site.
• Use SPD to restore the parent & subsites.
• Use “Content & Structure” to move the workspace from its imported location to its final destination.

Another few notes:
Some sites would duplicate their list items (and in one case, triplicate) on import. When possible, using SPD to perform the import seemed to do the trick. If you prefer the stsadm method, try using the updateversions option.

There are a few other “quirks” that we’ve run into while migrating content, but I’ll save that for the next post.

Update:
For some reason, reverting back to the stsadm import method worked just fine after returning from the weekend. Not sure why this stopped working in the first place – but very happy that it’s behaving now.

Lesson? SharePoint Designer and stsadm are finicky and fragile. When one starts acting up, try using the other to see if it does the trick.

Server Error in ‘/’ Application.
Runtime Error
Description: An application error occurred on the server.[...]

We hadn’t recently patched, or performed any updates except for increasing the max allowed upload file size and timeouts (a client needed to upload LARGE files). The server application logs revealed something slightly more useful:

Event Type: Warning
Event Source: ASP.NET 2.0.50727.0
Event Category: Web Event
Event ID: 1310
Date: 5/6/2010
Time: 4:50:11 PM
User: N/A
Computer: ServerName
Description:
Event code: 3006
Event message: A parser error has occurred.
Event time: 5/6/2010 4:50:11 PM
Event time (UTC): 5/6/2010 8:50:11 PM
Event ID: 57cbaa6a1f804cb2aefe80de4ceec102
Event sequence: 5
Event occurrence: 1
Event detail code: 0

Application information:
Application domain: /LM/W3SVC/1965610693/Root-1-129176526056583668
Trust level: WSS_Minimal
Application Virtual Path: /
Application Path: C:\Inetpub\wwwroot\wss\VirtualDirectories\foldername443\
Machine name: ServerName

Process information:
Process ID: 1944
Process name: w3wp.exe
Account name: NT AUTHORITY\NETWORK SERVICE

Exception information:
Exception type: HttpParseException
Exception message: Could not load file or assembly ‘System?Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ or one of its dependencies. The system cannot find the file specified. (C:\Inetpub\wwwroot\wss\VirtualDirectories\foldername443\web.config line 106)

Now, the web.config wasn’t manually edited by anyone, but the modified date matched the date & time when this problem started as well as the beginning of these ASP.NET errors. All the evidence seemed to point to what I can only assume was caused by a hiccup when the settings were being saved from IIS – that corrupted the web.config.

I found 4 or 5 randomly placed “?” in the web.config. I couldn’t just remove the question marks because they appeared to have replaced characters in the file instead of being inserted. I didn’t have a backup, but we did have multiple AAMs for this portal and I was able to look at another web.config. This gave me a better idea of what characters should have been in the file wherever I wasn’t able to make a good educated guess.

While walking through the portal to verify that all the access was fixed where it needed, they reported that one of their users could no longer start or edit a workflow. This started on the same day as the permissions issue, so I had initially assumed the workflow was trying to write somewhere that the user no longer had access to. The “Access denied” message is usually a giveaway.

I spent almost an hour troubleshooting trial by error and walking the user through testing with no result. I tried giving “Full Control” to the Doc Library, the Task List, and the Workflow History list – no effect. I even tried to remove & re-grant access. Same results.

Symptoms:

• Upon starting a workflow, the user receives “Access denied.”
• The workflow actually starts (as evident by viewing the workflows on the document).
• The user can view the task created by the workflow.
• The user cannot edit the task created by the workflow (“Access denied”).
• The user can create & edit a new task in the same task list manually.

After trying everything that I could think of – which included opening the workflow in SharePoint Designer and verifying that there were no other locations that the workflow was attempting to write to – I reached out to Google.

For some people, this is simply a permissions problem. For my situation, apparently this is a bug that crops up from time to time in SharePoint Designer created workflows. I found this post with a proposed solution that ultimately resolved my problem.

Solution:

1. Open SharePoint Designer and navigate to the workflow.
2. Right-click on the offending workflow’s folder and check it out.
3. Right-click on the offending workflow’s folder and check it back in.

Simple as that.