Random Musings: List does not exist & alternate access mappings

From time to time, sites are migrated, moved or renamed.  In that scenario, there is a whole host of things are changed both in SharePoint and in the external network.

To localhost or not?

I come across this error a number of times.  Junior consultants access SharePoint via http://localhost and then cannot understand why the site doesn’t work as expected.  The reason for this is pretty simple.  The default IIS website (running on port 80) will be available, but when navigating to list pages and site settings, you will either see the roots lists OR you will get an error.

Other functionality will give funny errors or will simply stop working (InfoPath Form Services being one.

Alternate Access Mappings

SharePoint uses alternate access mappings to “translate” the URL received.  This capability allows us to use multiple URLs to access the same content.  For example, we can have http://intranet.sps.co.za (for internal users) and http://extranet.sps.co.za (for external users).  Both URLs, from a DNS perspective, will point to the same logical IP / server, but once it hits the SharePoint server, it will be translated and pointed to the correct IIS web application based on SharePoint’s rules.

Alternate access mappings is often overlooked as a critical part of the configuration as many “basic” sites either do not use it, or have it pre-configured for their default web application.

I hope me sharing this small post, will give the consultant experiencing some funnies another tool in his arsenal when troubleshooting SharePoint.

Solved: Code blocks are not allowed in this file.

SharePoint, I heart you, but sometimes I wonder about your intentions.  I treat you with respect, I ask all my friends to work with you, but then all of a sudden you hit me with a correlation ID, out of nowhere.  What happened?  Are you unhappy with our relationship?  Should we go to therapy? 

Talk to me!!!

Okay, I’m not really in a relationship with SharePoint, but I might as well be.  From time to time a couple of funny errors creep in and although I’m 100% aware that it is the user that did something wrong, what is worrying is that the user was able to complete the “misstep”, if you will.

This morning I was working on a tender document, I made some changes (out of an attachment) and then wanted to save it back to SharePoint (like a good information worker should).  I clicked on “Save & Send” –> “Save to SharePoint” and then “Save As”.

A dialogue popped up and I pasted the link to the folder in SharePoint I wanted to save to (mistake).  After “saving” the document, the document library was no longer available and the error I received when trying to view the content read – “Code blocks are not allowed in this file.”

Thankfully, I knew that the content couldn’t possibly be lost.  I logged into SharePoint Designer and tried to get directly to the document library.  The library was available, but none of the files.  **heart stopping moment**

This got me thinking and I realized that something funky must have happened to the view.  I created a new view, and badaboom, all sorted.

In Summary

All content in SharePoint is saved in a database.  Files that render this content can get corrupted, but the underlying content will be fine (for the most part).  In some cases, a broken web part will also cause a page to go wonky, but after removing the web part, everything is fine.

Is SharePoint Taboo?

Offensive, Unmentionable, Off-Limits, Forbidden and Banned.  These are some of the synonyms that come up for “taboo” in Microsoft Word.  Do you think of any of these words when putting together your sales pitch for an intranet, website or extranet?

Didn’t think so…

So what is all the fuss about?  I’ve been in the SharePoint game for as long as I can remember and for the better part of the last 5 years I’ve been involved in sales and pre-sales of SharePoint based solutions.  The beginning of my sales “career” was predictable; “This is SharePoint, look at all the cool features”.  From there it went into the “This is an information management system, look at all the benefits” and now I find myself in a fantastic medium between both of the extremes.

What about the customer?

In a sales cycle of a solution based on Microsoft Dynamics CRM 2011 the customer paused the engagement to review products that compete with MSDYNCRM2011 in order to ensure they are making the right decision.  This got me thinking.  If we aren’t using the word “SharePoint” in our pitches, how does the customer know what they are buying or what the enormous ancillary benefits are to owning the platform?

The answer is pretty simple, they don’t.

What about the community?

In some ways I firmly believe that the SharePoint community gets wrapped up in its own hype quite a bit.  “Oh, SharePoint this and SharePoint that.”  “Oh, you can’t use the word Intranet, it’s so done”.  Well, why not? 

No matter how far our (the community at large) understanding of knowledge management, and so forth, has come, customers still contact us almost weekly for a “Intranet to enhance internal communication and share documents.”  In that particular scenario I think it is paramount that the customer understands (at a high level) the base platform, it’s underlying benefits, features and functions and high level roadmap capabilities.

I find it a chore to discuss basic SharePoint elements in some sales pitches, but more often than not I get reminded how important it is.  As I’m so close to the tool and what it does, I’ve almost forgotten how cool and beneficial some of the basics are to customers.  Check in / check out, versioning and self service permission management can literally change a company, but yet in some solution selling engagements we don’t harp on it.

So where to from here?

To each their own, but I do believe we need to get back to basics, and learn to love the brand.  We mustn’t be afraid to stand proud and say we are selling SharePoint and that our Intranet’s are based on SharePoint.  Customers need to know that and I think in some cases the community needs to remind themselves that the basics can make a remarkable difference in companies if implemented correctly.

Is the word SharePoint taboo, I think not.

Navigation GOTCHA: SharePoint 2010

More often than not vendors are developing their own navigation controls for SharePoint 2010.  These include megamenu, custom .NET controls and so forth.  I’ve been involved in a couple of great ones myself.  One that stands out was a “Windows 7” type of navigation that my colleague (Oliver Smit, Oli4) built for the University of Johannesburg (MOSS 2007 WWW).  The site has been updated since, but that was a great piece of code.

Now what happens when you are putting together a pretty straight forward website and simply want to utilise the built in controls?  Well, it all works find and dandy until you need to order the sub pages.  Here is the scenario:

A heading (sub site) has pages and you want to manually sort those pages in the order that makes the most sense for you.  SharePoint’s navigation can do it, but a combination of settings need to be correct.

Top Navigation

Global Navigation Settings in SharePoint

So where do I arrange my pages?  The sub sites are set to inherit from the main site for ease of maintenance.

The answer is in the navigation settings themselves.  Although the sub sites inherit navigation from the main site, the ordering of the pages must still be done on a site level.  Now if you have not selected the “show pages” option in the site level (as it inherits from the top) you won’t see the pages to sort them.

In other words, to get past this gotcha, enable the “show pages” setting for the current navigation, sort the pages, click OK and then revert the “show pages” setting back to what it was:

On the sub site, enable “Show pages”

Sort the pages

Click OK and then revert the “Show pages” setting for the current navigation.

 

In summary, I find that many things are possible in SharePoint if you dig around long enough and play with different combinations of settings.  More often that not, I find that an implementation method is the root cause of the problem, not the product itself.

Happy SharePointing, keep it classy.