Thursday, October 23, 2008

Customizing SharePoint Top Navigation Menu and Quick Launch Bar

Customizing SharePoint Top Navigation Menu and Quick Launch Bar has been a request from a couple of different sources. So I've decided to finally post on the logic, step and simply value changes to accomplish this. You will need a text editor for editing the master page and/or pages. For this I'll be using SharePoint Designer.


Essentially you want to keep your main portal page clean and you want the "fly-away menu" look and feel. This is a major advantage with SharePoint 2007 and the Security Trimming. Depending on how many levels you want to show will determine your overall look and feel. Remember that you can look under your Manage Content and Structure under Site Actions to look at this tree and understand your levels. 0 (zero) is Home, and everything incrementing from 0 (zero) will allow for additional sub sites to be displayed.

Prep Work:

Under Site Action > Site Settings > Modify All Site Settings you'll see "Look and Feel". From here you're looking for Navigation. Under Navigation make sure that "Show Subsites" is checked.

NOTE: It is VERY important to make a copy of this original file > Default.Master . Changing the master pages can cause a lot of headaches for you and your portal, if not done correctly. I'd recommend even downloading a copy to another location for safe keeping. You can use version control, but I'm still recommending.

Use the breadcrumb to get back to Site Settings and under "Galleries" you are looking for Master Pages and Page Layouts > default.master.


Find default.master and select "edit in Microsoft Office SharePoint Designer" or which ever editor you have installed.

First you're going to be looking for : "TopNav"

And more specifically 2 separate lines for editing:



This is where the values determine the depth and width of your menus. The StaticDisplayLevels will determine how many levels in your site collection you wish display on the top ribbon and how wide you want it to be. For example, if you have "Home > Sites > Team Sites > Sub Team Sites > Sub Sub Team Sites" and your StaticDisplayLevels was set to 3 you would show everything up to "Team Sites" across the top. If you set your StaticDisplayLevels to 1, you would only show "Home". You can play with your changes and test. Just make your value change, save and then refresh your browser.

Second you're looking for: "QuickLaunch"

Same rules apply here but you're working on the horizontal expansion rather than vertical. You still have your same fields but your default values are a little different.


Things to be aware of:

Security trimming does still apply here. If you can't navigate through a site you don't have access to. This translates to if you have access to sites #1, #2 and #4, your navigation will only show #1 and #2. You can't traverse through #3 to get to #4 so the menus will not show #4.

Friday, September 26, 2008

MOSS - This List not returning Search Results


You can't search lists or libraries in MOSS 2007. Or some older lists return results but nothing new. Essentially "This List:" doesn't return results while searching, but "This Site:" does return results.

There are a couple of possibilities here for the cause and I've read some ridiculous theories on this. Most of them point as your SSP being corrupt and you need to create it. Or you've corrupted your databases and need to restore them.

Really the first place I thought to check was Authentication. I found that there 2 different types of content in Sharepoint / MOSS 2007. Long story short, you can search the .aspx pages, separately from List and Library items. I've found this to be reflected in your indexes also.

What actually triggered this for me was resetting SPN's for Sharepoint. I found that some of the SPN's were throwing errors on the Domain controllers so I deleted and recreated them. In another case I changed from Kerberos to NTLM authentication to resolve some immediate issues but didn't update my search service account.

Fixing "This List" search issues:

1) Login to your SSP
2) Under Search, select Search Settings.

You will see the following:

Indexing status: "if you're in error it will probably say something other than IDLE"
Items in index: "# of items"
Errors in log: "# of errors"
Content sources: "Local Office SharePoint Server sites"
Crawl rules: "will be different depending on what you've defined"
Default content access account: "Should be a Domain account
Managed properties: Default is 130 defined properties
Search alerts status: "Alert status"
Propagation status: Idle

3) Click on on "Manage Crawl Rules"
Note: You should have the URL of your Site configured here.
4) Click on the URL of the site with the issue(s).
5) Select "Include all items in this path" and check Crawl complex URLs (URLs that contain a question mark (?)).
6) Then select "Specify a different content access account"
7) Enter in the Search User account and password.
8) Use the Breadcrumb and select "Search Settings".
9) Click on "Content Sources and Crawl Schedules".
10) Select your content source ("Local Office SharePoint Server Sites" is the default).
11) Make sure that the URL for your SharePoint site is listed in the "Type Start Address Below" box.
12) Under Crawl Settings, select "Crawl everything under the hostname for each start address".
13) Then set your crawl schedules. Usually you do a Full Crawl outside of your business day and hourly for your incremental crawls.
14) Check the box for "Start Full Crawl"

You can monitory the status of the crawl at the "Search Settings" page. Depending on how much content you have, will determine how long it will take to index. Also it will go through and delete old indexes for deleted content at the sametime. This will add time for the full crawl to complete.

Wednesday, September 24, 2008

Checking in Files / Removing Locks in TFS

I've found this to be an issue on multiple occasions. Essentially you're using Team Foundation Server with Visual Studio and a member of your team leaves with code checked out or locked.

There are a couple of ways to fix this but the easiest I've found is with TF.exe. If you have Visual Studio installed and priviledges you can use this tool to fix you problem.

Note: You can find the TF.exe tool in:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TF.exe (VS2005)


C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe (VS2008)

Get a list of workspaces for a user:

tf workspaces /owner:UserName /server:ServerName

eg. if my user name was JDoe and my TFS web server name MyTFS then the command would be:

tf workspaces /owner:JDoe /server:MyTFS

Note: Use the Host Name of the server you're attaching to. If you have a multiple server configuration, you need to use the Server Name of the web server where your TFS client connects to. Don't use the host header (if applicable) or the http address and you don't need to use the Fully Qualified Domain Name (FQDN).

To remove a workspace for a user, you need to know the workspace and the username. The default workspace name is their development machine name. Occassionally developers have multiple machines, maybe a laptop and a desktop for development. It's not uncommon to have multiple workspaces associated to the same usere.

Delete a workspace for user:

tf workspace /delete /server:ServerName "workspace";"workspaceusername"

eg. if my username was JDoe and my workspace was JDoe2003, and my TFS web server was MyTFS, the command would be:

tf workspace /delete server:MyTFS JDoe2003;JDoe

Get a list of directories in a workspace for a user and display the GUI (Graphical User Interface):

tf workspace "workspacename";"workspaceusername" /server:ServerName

eg. if my user name was JDoe and my TFS web server name MyTFS then the command would be:

tf workspace JDoe2003;JDoe /server:MyTFS

Wednesday, September 10, 2008

Publishing InfoPath Forms - Updating Content Type Failed

Scenario: You've published and InfoPath form to a Sharepoint Form Library. You edit the template, save and attempt to publish again and receive the following message - "Updating Content Type Failed"

I've done some researching on this and found a couple of issues. The most common response is that if you remove some columns for your InfoPath List, it will magically work. What I've discovered for this ready why this actually works is because you're falling within the Timeout window. What you're actually doing by removing columns is shrinking the Infopath form from being too large and the web service that is uploading the template is completing inside of 30 seconds.

I don't have a solution for this issue yet, but I am actively working on it. InfoPath is used to capture information and my work around is to reduce the information displayed. That's not accept for me or my business.

I'll post more when I something more concrete. I'm actively exploring optimizing the Infopath form, column types and even increasing the web service timeout to larger than 30 seconds.


I've found some other work arounds to help with this situation. If you create a new form library, you should not have any issue publishing the form for the first time. You will be able to add all of your columns and publish the complete form. I suspect there is something corrupt with the form library which is causing Infopath to have issues. I'm not sure if it's SharePoint Designer related but I haven't ruled it out.

Separately I've found that most form libraries with issues on publishing form templates, all seem to have multiple files in the library and many different files that are unlinked from the current template. I haven't tested if linking all the files back to the current form template will resolve the issue or not, but it was something I noticed when recreating the form library.


I've done some more investigating and found something interesting. There's not a "hard limit" to the number of columns in a List, but more a limit to the number column types you can have in a list. The interesting part is that there is technically a hard limit on the number of columns and once that limit is reached, MOSS on the back end will create a new row with the same cap. The end user will still continue to see a single giant list.

Here's the breakdown of what you can have in a list can have:
64 Single line of text and Choice (drop-down menu or radio buttons)
31 Multiple lines of text and/or Choice (check boxes (allow multiple sections))
32 Number and currency
32 Hyperlink
16 Date and time
16 Lookup 16 Yes/No
8 Calculated

Note: The number of shared data types are not 64 Single Line of Text and 64 Choice. It's actually 64 total of a combination of either data type.

So we now have a new question:

Does your InfoPath form has more than 199 columns, or has your InfoPath form surpassed the column type limit?

Tuesday, July 8, 2008

Method 'Publish' of object "ListObject failed.

I've been trying to import CSV's into a SharePoint Lists. All but one seems to be import successfully. A single CSV is giving me a lot of problems and I only get the very generic error -

Method 'Publish' of object "ListObject" failed.

My work around for this error was to attempt to Create a Custom List by selecting Import Spreadsheet. I gave the list a name, and browsed to my problematic CSV location. I selected my problematic CSV and picked the Range of Cells, and then hit Import.

The looks like it is starting and then failed with the wonderful error message "Method 'Publish' of object "ListObject failed". But it didn't truly fail. It actually will create a list with columns but no records. I navigate to my new empty list and change to Datasheet View. Do a comparision to make sure all of the column headers are correct. Also check to see if your data types are correct for each columns (single line of text, date and time, etc.). Make any adjustments as necessary.

After you're finished jump back to the CSV and select all of the data, minus the column headers (which already exist in the list), copy and paste the data into the First Cell in the First New Column that was created by the failed import. Trying to paste directly into the "Title" Column will cause completely separate issues.

Depending on the number of records you're trying to paste, this may take a few minutes. I've found pasting more than 2000 records with a list over 200 columns is pretty slow. It's also against best practice to even have a list over 2000 items, so make sure you plan accordingly.

Separately, if you have to have all of your items in a single list, which is usually dictated by your customer or your business team, keep an eye on your memory usage on your desktop/laptop you're doing your work from. The more items you copy to your clipboard and then attempt to paste into a list will drive your Internet Explorer Memory through the roof. I've had iexplorer.exe over 1.5GB on multiple occassions. Not something I'd recommend if you're working from a Laptop with 2GB of memory. Less records copied means less memory consumed by IE, but will increase your time spent copying and pasting.

This process only directly impacts your machine. I've confirmed that my desktop is practically unusable while pasting 20,000 records and no one else in SharePoint is impacted. Who says client side processing is bad?

If you don't like the status bar at the bottom of your browser when you're pasting, attempt to navigate away from the list. You'll be prompted to nagivate away and lose your changes or wait. Wait for the changes to complete and you'll get a status bar box in the middle of your window that gives a better indication of your progress.

Rinse, lather and repeat as necessary.

My impression is that Excel was using the SharePoint Web Services to upload the CSV and create a list. Something is breaking after the list is created, and the columns have been created. I don't the exact reason yet, but I'm working on that. When I have an explanation for the error, I'll update the post.

Monday, June 30, 2008

To help protect your security, Internet Explorer has blocked this Website from displaying....

Unfortunately if you're seeing this message you either have 1 of 2 problems. Either you're visiting a site with an incorrect SSL Cert or your visiting a site with an expired SSL Cert.

If it's an expired SSL Cert, then the obvious fix is to renew the cert and install it. If the Cert is still valid but not cofigured correctly, IE7 now will do you a favor and block the content.

The main issues with incorrectly configured SSL certificates seems to be the "Issued to" field. It should be read the URL of the site, rather than the contact information. IE6 didn't care about this field but IE7 takes it very seriously.