Since the upgrade I’ve noticed inconsistencies with these shortcuts. When I double-click on them, some would open in a new tab while others would open in a completely new window. Those who know me would initially think “You have too many tabs open, so it’s opening the overflow into new windows” – but that doesn’t appear to be the case.

I’m not sure if it’s strictly the shortcuts from after the upgrade that are exhibiting this behavior, or just some of them (I haven’t done enough testing). I do know that at a minimum that it is not a random behavior – it’s always the same shortcuts that open in a new window.

My IE preferences are already configured to always open links and pop-ups in new tabs, so that wasn’t it, and viewing the properties of the shortcuts didn’t see to help either. I figured I’d try to edit the shortcuts and see if I could figure out what the difference was that caused this behavior. Bingo! I should have looked a little closer at the shortcut properties.

The shortcuts that opened in new tabs were “.url” files, while the shortcuts that opened in new windows are “.website” files. There’s about twice as much data in the shortcuts that open new windows, and all had different GUIDs. The shortcuts that opened in new tabs seemed to have all the same generic content with the exception of the URL propertly. Also, the .website shortcuts are called “Pinned Site Shortcuts” while the .url shortcuts are called “Internet Shortcuts”. I was able to copy the URL from one of the new-window shortcuts and paste it into one of the new-tab files and save it with a new name and it worked beautifully.

What a frustration. Now I have to figure out how to create the appropriate shortcut types on-demand.

Here is an example of the contents of a .website file:

[{000214A0-0000-0000-C000-000000000046}]
Prop4=31,Page Title Here
Prop3=19,11
[{A7AF692E-098D-4C08-A225-D433CA835ED0}]
Prop5=3,0
Prop9=19,0
Prop2=65,2C0000000000000001000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF840000005C000000F0040000860300007A
[InternetShortcut]
URL=http://google.com
IDList=
[{9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}]
Prop5=8,Microsoft.Website.1E0E98C3.ED613691


And here is an example of the contents of a .url file:
[{000214A0-0000-0000-C000-000000000046}]
Prop3=19,11
[InternetShortcut]
URL=http://google.com
IDList=


Attempts:
I created a calculated column that I titled “MonthName”. Here are some quick formulas that you can use in your calculated column that will convert your 1-12 number into a month name.

=TEXT([MonthNumColumn],"mmmm") will give you “December” for a value of “12″
=TEXT([MonthNumColumn],"mmm") will give you “Dec” for a value of “12″
HOWEVER, this seemed to only return values for December and January – and they were not actually accurate.

I thought that perhaps it was because the numbers were not all 2 digit, so I created a second calculated column that I titled “MonthNN” and used this formula (I know, starting to go down the rabbit hole):
=TEXT([Month],"00")
And then adjusted the above calculated MonthName field to refer to this new calculated column. No change.

Then I attempted to use the “CHOOSE” function, but the “Month” field was not required and returned “#VALUE!” for any blank fields.

So I nested the CHOOSE function inside an IF statement, and it’s not the most elegant, but it works:
=IF(Month="","NA",CHOOSE(Month,"Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"))

Enjoy!

There are tons of discussions and HowTos out there that have a lot of great info and starting points. Those did not help with my scenario.

Sure, I verified that search was configured and that I had an Index server defined. I’ve even reconfigured search several times (I think the database name is appended with “_5″ or so by now). I’ve tried the different loopbackcheck fixes to no avail. Literally, no change. The default AAM zone is NTLM. This was not a permissions issue for us. Our AAMs are configured properly and the portal works great in every other aspect. I’ve stepped through just about every search troubleshooting checklist that I’ve found, with no impact.

Here’s the scenario, and ultimately the root of the problem:

Single server farm. Pretty standard, except the web app was extended to have FBA. There’s an external HTTPS URL being redirected via ISA. The site’s internal URL is HTTP://servername:##/sites/yaddayaddaortal/

And there it is. The cause. Check this out:

The event log reports that it cannot crawl the content source at sps://servername:##/ (minus the /sites/…). Well, yeah, of course not. There’s no site there. I looked everywhere to see if I could configure the search content sources to change that. This appears to be a hard-coded assumption on behalf of WSS? I have yet to find a way to change this. The kicker is that this appears to be a road block for the search crawl. If no site is found there, then it simply stops before it even gets started.

Solution:
Make sure you have a site defined at “/” – even if it’s not THE site collection that you’re using. And make sure that it’s NTLM. I created a blank site, titled “Search” with a description to simply state that it’s required for search to work. No users actually have access to this site collection except for the admin. I ran another full crawl – fixed! No more errors in the event log, and now search returns results.

This was so simple, that I’m not sure what took me so long to try it. I was definitely overthinking it. We could just not have created these sites under the /sites/ managed path to begin with, but it was a business requirement, so I was stuck with it (for now).

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