SharePoint Skater

Practical Tweaks: creating a Social Security Number column

Many people find SharePoint to be somewhat limiting in its out-of-the-box functionality, but really, a creative approach can take you pretty far.  Say, for example, you need to create a column to hold Social Security numbers (assuming you've worked out all the relevant security issues).  You have a field that requires numeric validation, but it has a specific length requirement, which sounds more like string validation.  Here's what I came up with off the cuff:

1. Create a new Site Column.  Add it to whatever group makes sense (I picked Core Contact and Calendar Columns).
2. Give it a name and a datatype of Number.
3. Specify a maximum of 999999999 to take care of the ten-digit formatting issue.
4. Explicitly set Number of decimal places to zero.
5. Click OK.
   

 That's it.  Next time we'll look at masking/validating your user's input for this field.

Backup horror stories: Rendering error in the global navigation tab

Chances are that if you're restoring a site collection from backup, something has gone seriously wrong.  Naturally, at this point, you've had just about enough of unexpected glitches, and you REALLY don't want anything to look weird once you restore and load up the site again.  Oh, but Mr. Murphy is there laying down the law, and all you see on the global nav is a big "Error" tab.  Terrified, you mouse over it with a morbid curiosity, only to discover the following error in a tooltip:

An error occured while rendering navigation for requested URL: /. Exception message: Object reference not set to an instance of an object. Stack trace:    at Microsoft.SharePoint.Publishing.PublishingWeb.<>c__DisplayClass2d.<CleanupInternalIDs>b__2c()
   at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper(Object state)
   at Microsoft.SharePoint.SPSecurity.<>c__DisplayClass4.<RunWithElevatedPrivileges>b__2()
   at Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)
   at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(WaitCallback secureCode, Object param)
   at Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges(CodeToRunElevated secureCode)
   at Microsoft.SharePoint.Publishing.PublishingWeb.CleanupInternalIDs(PublishingWeb pubwebToCleanUp)
   at Microsoft.SharePoint.Publishing.PublishingWeb.get_PagesList()
   at Microsoft.SharePoint.Publishing.CachedArea.GetChildPageIds()
   at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider.UserHasRightsToCachedObject(CachedObject cachedObject, SPWeb currentContext)
   at Microsoft.SharePoint.Publishing.Navigation.CachedObjectSiteMapNode.IsAccessibleToUser(SPWeb contextWeb)
   at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode.GetNavigationChildren(NodeTypes includedTypes, NodeTypes includedHiddenTypes, OrderingMethod ordering, AutomaticSortingMethod method, Boolean ascending, Int32 lcid)
   at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapNode.GetNavigationChildren(NodeTypes includedHiddenTypes)
   at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider.GetChildNodes(PortalSiteMapNode node, NodeTypes

Of course I can't speak for everyone in every situation, but this kind of thing late at night when everything else has hit the fan...  it's enough to make you want to swap careers with Old MacDonald (seriously, what kind of farm grows moss?).

But enough about my midnight work hallucinations.  At this point, the most helpful thing to do -- assuming you still have that backup -- is to delete the site collection entirely.  Go into Central Admin, click Application Management, and blow that site collection away.  THEN go back and restore from backup again.

If that doesn't work, then run the Config Wizard again; that'll usually shake something loose.

Why my MOSS search doesn't work today (Reason #316)

Earlier this week a client called.  Our beautiful MOSS installation had been running beautifully, and then several days after a reboot... their Search completely stopped working.

Naturally, I hopped on the VPN, logged on to the server via RDP, and checked all the usual things.  Windows SharePoint Search Service was running, and the MOSS Crawl Schedule looked right, so I decided to see for myself... except the portal wouldn't authenticate me.

Aha.  Just after a reboot, you say?  If only I'd had the good sense to look at the crawl logs (they were full of 401.1-type "Access Denied" errors).

This is nothing less than the dreaded loopback check.  Apparently, Microsoft feels that it is a security risk for one to access a website from that same server (but only on port 80; all other ports appear to be wide open).  To get around this, they actually recommend a registry hack -- er, tweak -- that is detailed in MS KB article 896861.  I'm including the procedure below on the off chance that the article goes dead someday; my preferred choice is method 2, but you may have other needs.

Method 1: Specify host names

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
3. Right-click MSV1_0, point to New, and then click Multi-String Value.
4. Type BackConnectionHostNames, and then press ENTER.
5. Right-click BackConnectionHostNames, and then click Modify.
6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
7. Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check

1. Click Start, click Run, type regedit, and then click OK.
2. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3. Right-click Lsa, point to New, and then click DWORD Value.
4. Type DisableLoopbackCheck, and then press ENTER.
5. Right-click DisableLoopbackCheck, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Quit Registry Editor, and then restart your computer.

The Great Divorce: Separating site hierarchy from navigation

(apologies to Clive Lewis)

It's a simple concept, really.  Create your SharePoint site structure to accommodate permission inheritance, not navigation.  You can always alter the content and appearance of Global Nav or Quick Launch, so why constrain your hierarchy to something that will probably change?

Hyper-V fun fact

Have you ever needed to back up a VHD with a script?  If you have, then you've probably wanted to make sure it copied successfully.

One simple test is to check the size of both the source file and the destination file; this sounds great until you bang your head against the wall in frustration when, two hours later, you can't figure out why the file sizes still don't match.

Allow me to explain.

When you back up a Hyper-V machine, the first thing you do is to stop the VM for the duration.  Essentially, this just tells the virtual machine manager to stop writing to the VHD, giving you a static target... but in the process, it marks the file which changes the size.  Ergo, you have a 4KB difference in your VHD size between "started" and "stopped" states.

The solution?  Make sure your VM is off for another second while you get that all-important file size.  Then start it up again, and off you go.

My favorite new quick fix: MS Office Diagnostics

Rebooting cures a multitude of ills.

Over the past two years I've come to realize that the SharePoint server equivalent is to run the SharePoint Products and Technologies Configuration Wizard (what a mouthful that is).  However, my latest discovery is that there is a client equivalent as well.

If a user complains of JavaScript errors (e.g. "Library not registered"), of Excel 2007 documents opening in Excel 2003, or a handful of other SharePoint-related client-side issues, I now point them directly to the MS Office Diagnostic Tool.  Here's the basic procedure:

1.      Open Word 2007 (or Excel 2007).
2.      Click the Office button.
3.      Click the Word Options (or Excel Options) button on the resulting menu.
4.      Select the Resources tab on the left.
5.      Click the Diagnose button.
6.      Start the diagnostic tests and follow the prompts.

The tests will take a few minutes to run, after which the results will be displayed (e.g. 1 defect fixed).  At this point you can go back and try the offending procedure again... and most likely, the error will be gone.

Additional info:  the relevant executable is located at C:\Program Files\Common Files\microsoft shared\OFFDIAG.EXE.  Administrators may find this useful for remote execution at login, etc. for curative or preventative purposes.  There's no official way to launch it without user intervention, but you could easily run the file with VBScript or .NET code and then use SendKeys to kick it off.

Feel free to contact me with additional problems that this solves; I'd like to keep an updated list here.

Hiding the Recycle Bin

The SharePoint Recycle Bin is a very useful feature, but due to the lack of a separate permission structure, sometimes product owners want to hide it from their users.  This can be done in a variety of ways, but I've found that the simplest is to create a new master page (usually from a downloaded copy of the one you currently use on your site) and find the following tag:

<SharePoint:SPLinkButton runat="server" NavigateUrl="~site/layouts/recyclebin.aspx" id=idNavLinkRecycleBin" ...
(there's a lot more)

Simply add the Visible="False" attribute to the tag.  This will hide the Recycle Bin link on the Quick Launch and allow you to retrieve it at any time.  You won't need SharePoint Designer or Visual Studio -- you can do this with Notepad once you've downloaded the file -- and the whole thing, from when you download a copy to when you Publish/Approve the new master page, takes less than a minute.

SPTraceView: One step closer to unscrewing the inscrutable

We still don't have good SharePoint debugging, but today I came across a tool that gets us closer.  Essentially it works off of the SP logging mechanism, and alerts you when messages come up that meet your predefined filters.  This has the advantage of (a) keeping you from having to go through the log files line by line, and (b) filtering at a higher level, allowing you to keep all that log information rather than excluding some events from being logged.

Give it a shot at http://sptraceview.codeplex.com/ .

PSConfig Part III: Confessions and assumptions

It's happened to everyone.  You're supposed to be an expert in your field, and then you go and get tripped up by something insignificant.  If you're like me, you think you've already eliminated the offending possibility, and it's only after the client (ack!) checks out your assumptions that you realize your foolish mistake (in this case, it was the assumption that the server's software firewall had nothing to do with the problem... but it did).

So there I was, running PSConfig on a two-server farm (one MOSS box, one SQL 2008 box), and I got the following error:

The server parameter specified with the configdb command is invalid.

Failed to connect to the database server or the database name does not exist. Ensure the database server exists, is a Sql server, and that you have the appropriate permissions to access the database server. To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics...

Since these were all new accounts for the MOSS farm, I thought they didn't have proper access (this had been a problem the previous day)... but no, I could log on to the DB server just fine.  I noticed, however, that I couldn't get into SQL Management Studio via Windows authentication; this led me to all the usual checks for Windows auth, TCP/IP, remote connections, etc.

At some point after contacting the DBA, that local login problem went away, but I had already let it steer me down a rabbit trail.  At that point my mind should have shifted back into "obvious mode", but I'm a hardcore geek, for crying out loud; this doesn't come easy for me.  Suffice it to say that you should always, ALWAYS go through your "duh" checklist again, even if you think you've covered it all.

One final note:  while searching for clues on this crazy chase, I came across someone who claimed that their problem was an incorrect collation mode on an already-created database.  The latest version of MOSS (as of this writing) gives a more specific error if that is indeed the problem (but don't let me keep you from checking it just in case!)

SharePoint Migration from 2003 to 2007: Leave the clutter behind.

This has come up several times recently, and I think it's another case of the "Microsoft offers it so we should use it" mentality.  There are indeed tools and utilities for migrating your existing farm -- or content database(s), or site collection(s) from 2003 to 2007; there are even procedures for upgrading your SharePoint farm to the new version.

Having been all over that mess, I can't recommend it.

In fact, we almost always advise not migrating everything in bulk, in favor of having the users themselves bring over their relevant content.

Here's an analogy:  when you build a new house, you don't build it around the old one and hope everything fits.  You build in a new location (or perhaps the old if you're demolishing first), and then take what you want and place it where it should go in the new house.  Along the way, you discover a lot of things that you don't need; as a result, they get thrown away or given to someone else, and you have less clutter.

Of course there are exceptions, but -- generally speaking -- this approach (a) puts responsibility in the hands of the business users who actually *care* about their content, and (b) doesn't bind you to the old way of doing things.  It's a chance to go forward without the baggage of the past, to cash in on hindsight, to invent new cliches... and it shows you what content people are actually using.