SharePoint Skater

Practical Tweaks: creating a Social Security Number column

2009-10-19T17:49:00Z

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:

Create a new Site Column. Add it to whatever group makes sense (I picked Core Contact and Calendar Columns).
Give it a name and a datatype of Number.
Specify a maximum of 999999999 to take care of the ten-digit formatting issue.
Explicitly set Number of decimal places to zero.
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

2009-10-06T05:58:00Z

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)

2009-08-28T02:12:00Z

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

Note We recommend that you use this method.

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
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.
Quit Registry Editor, and then restart the IISAdmin service.

Method 2: Disable the loopback check

Follow these steps:

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

The Great Divorce: Separating site hierarchy from navigation

2009-07-31T17:02:00Z

(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

2009-07-28T17:19:00Z

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

2009-07-10T18:16:00Z

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

2009-07-09T19:14:00Z

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

2009-07-02T14:46:00Z

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

2009-06-04T12:59:00Z

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.

2009-05-29T21:09:00Z

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.

PSConfig revisited: character analysis

2009-05-28T14:50:00Z

After yesterday's brush with covert crazy hyphens, a related tip seems in order.

This isn't the first time I've been burned by non-standard characters. Several years back I created a small classic ASP utility (yes, it's THAT old) that analyzes a string and spits out the unicode values; you can use it in the iframe below.

As a sample, here are two identical sections of the PSConfig script -- one with proper dashes, and one with the offending content. You can copy/paste each into the tool below to see how obvious the problem is.

Normal:
Psconfig -cmd configdb -create -server <SQL_servername> -database <precreated_configDB>

Disturbed:
Psconfig –cmd configdb –create –server <SQL_servername> -database <precreated_configDB>

Alpha characters are shown in blue, with numerics in green. Normal "extra" characters are yellow/beige, and out-of-range weirdness is highlighted in red.

PSConfig: helpful tool, unhelpful error messages

2009-05-27T21:01:00Z

Earlier this week, I needed to set up a MOSS development box. Piece of cake, right? Well, I must have been really tired from the long weekend, because when I used PSConfig to pre-create the configuration database, the following error stopped me dead in my tracks:

“The -cmd command is invalid.”

For those of you not familiar with PSConfig.exe, it's a nice little built-in utility that allows you to create your configuration database and admin content database with a pre-determined name instead of the unholy string of nonsense that MOSS autogenerates. You can run from in the /bin folder under the 12 hive, with the following syntax (all on one line):

Psconfig.exe -cmd configdb -create -server <SQL_Server_Name> -database <New_Config_Database_Name> -user <domain\Database_Access_Account> -password <Database_Access_Password> -admincontentdatabase <New_Admin_Content_Database_Name>

Be sure to replace the angle-bracketed parameters with the correct values.

Normally this works like a charm, and if not, the resulting error message will tell you what needs changing. In my haste, however, I had copy/pasted the string from a web page and filled in my own values. The result was that I had some non-standard hyphens, and that made the whole thing choke. The solution? Delete all the hyphen (dash) characters and re-type them. Problem solved.

Anonymous users and SharePoint workflows: The Problem

2009-05-21T15:10:00Z

Simply put, you can't trigger a workflow from an anonymous user. The workflow must run in the context of the current user account, and of course there isn't one when you're anonymous. If you do try it, you'll probably see the following error:

The data source control failed to execute the insert command.

This is misleading because the item does get added to the list. It's the subsequent event (start workflow) that gets confused and curls up in a fetal position while humming manic strains of obscure nursery rhymes.

Since most people seem to think it's impossible to do this, I'm going to give it a try. Hopefully I'll have some meaningful results to share soon.

SharePoint Designer Gotcha: Where's the "action" in my Form Action button?

2009-05-15T17:04:00Z

It seemed simple enough.

I built a custom New Item form. Naturally, it needed to redirect to another page after completion. Normally for a "return page" function, a "Source" parameter in the querystring will suffice, but that didn't seem to work here. I found the Form Action Button (under Insert->SharePoint Controls->More SharePoint Controls), added Commit and Redirect actions, told it what page to use, and presto!

Nothing happened.

In fact, it didn't even try to submit the form.

A look at the markup revealed that the "Form Action Button" was just a regular old input type="button". SharePoint Designer was supposed to add an event handler with a JavaScript call, but there appears to be a bug in Designer. Apparently if there is another HTML button nearby, the event handler can end up there instead! I've included the code so you know what to look for if this ever happens to you:

onclick="javascript: {ddwrt:GenFireServerEvent('__commit;__redirect={Thanks.aspx}')}"

Your actions may be slightly different, but that's the basic idea. All you need to do is to cut/paste this bit into your *actual* button -- or any other control, really -- and you'll have the behavior you expected in the first place.

Whew.

Fun with MOSS Search, Part I: Service Packs and Registry Hacks

2009-05-13T17:52:00Z

SharePoint farms can take several forms. Probably the most common one is the single-server farm (not to be confused with the "Simple Install", which is almost always a very bad idea). If you're low on hardware -- or you just don't want to shell out for an extra server OS -- you can start out with all of your services on a single box and expand later as needed.

However, there are some roadblocks that will slow you down. One of the most unexpected is the problem of crawling a SharePoint server from that same server. If you've tried this recently, you may have gotten this ugly message in your crawl logs:

Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)

"Why is this happening?" you may ask, after checking to make sure that your default content access account does indeed have access. If everything else is in order, your problem is most likely something called "loopback checking". Apparently this is a not-so-new security feature, which prevents anyone from accessing an Integrated Authentication website while logged on to the server itself.

"No problem", you say; "How do I turn it off?"

This is where it gets weird.

The only documented way to disable -- or work around -- this feature is to hack the registry. The official KB article can be found at http://support.microsoft.com/kb/896861; however, since MS tech info has a way of disappearing over time, I've included a brief overview below.

Open Regedit and add a new Multi-String Value key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Name it BackConnectionHostNames; this will be "white list" for domain names that can be explored by the local server.

Once your new key is created, simply add in all of the URLs that your crawler will need to hit on this machine. Don't add protocols (http, etc); just feed it machine names and domain names as necessary.

That's all the configuration you need. The KB article tells you to restart the IISAdmin service, but I had to do a full iisreset (remember to run as Administrator) before the changes took effect.

Obviously there should be a better way to deal with this than changing registry values, but you dance with whoever brought you. Don't forget to add this to your disaster recovery plan; even the farm-level "everything" backup doesn't cover registry entries, so you'll need to keep track of it somewhere else.