Skip to content
Linked: How Everything is Connected to Everything Else and What It Means for Business, Science, and Everyday Life

Book Review-Linked

Some things come easy to me.  I see patterns.  I make connections that not everyone makes.  However, there are many more things that are more difficult.  I struggle to understand the idea of social networking, blogging, wikis, and forums.  They mystify me.  That doesn’t mean that I don’t try my hand at it to learn, it just means it doesn’t make that much sense.  I keep trying new things, new approaches, and start new conversations all seeking to figure out how it all works together.

So while I’m still reading software development titles because the journey that I’m on to be a better software developer – despite a decreasing amount of my time being spent that way – is a never ending journey.  However, I’m also beginning to inject social networking, long-tail marketing, and similar topics in an attempt, no matter how feeble to GROK it.

Linked is one of those books that I picked up upon the recommendation of a trusted colleague.  The book’s primary focus is networked thinking.  In other words, there is not one answer that drives everything.  It’s a series of complex interactions between all of the players that creates the play.  As someone who does a lot of IT work I’ve gotten quite familiar with a binary view of the world.  The code is either right or wrong.  The answer is either yes or no.  The hypothesis is either true or false.

However, the binary world of ones and zeros isn’t enough to explain the group dynamics of a user group.  Nor can it illuminate the reasons why a community thrives when another doesn’t.  It doesn’t well expose the single cause for success – probably because there isn’t one.

One of the great things about Linked was that it provides a great deal of information about a wide variety of subjects and pulls it all back to a central theme that many things are networks where one change impacts every other.  From eco-systems where animals are returned to a state of balance, to cancer, and to other far flung ideas a model emerges that things are connected to one another.

As an author and editor, I’ve read and written more than my fair share of material.  However, to be honest I’ve never liked reading academic papers.  I felt like the objective was to make the information harder to understand – to prove that the author is smarter than the reader.  The sacrifice I’ve made in this is that sometimes information that is quite good and relevant never makes it to me because I can’t coerce myself into reading the academic papers that the information is buried in.

This too was an interesting thing about Linked.  There were lots of very critical and strangely useful details buried in its pages and in very few occasions did I feel like it got to be too academic. (This is high praise if anyone’s trying to sort out what I mean.)  I felt like the author repeated his points from different angles without being overly repetitive.  He exposed some fairly advanced mathematical topics without wandering off into places that the reader couldn’t follow.

The short is that Linked helps you to understand how things are connected in every discipline, in every country, and in our every day.  If you’re struggling to understand how marketing works, how large systems function, or how coincidences happen, it’s definitely worth a read.

Workflow Struggles and Success

Talking to folks about SharePoint and Workflow is getting to be a regular habit.  My buddy Howard recently launched upon a conquest of creating a SharePoint Workflow.  Armed with my article on DevX, he set about creating the sample workflow.  Of course he had problems — I’m not saying that because of Howard, he started having problems because getting workflows working sometimes feels like getting the right combination on a combination lock.  He wrote down some of his experiences in a blog post.

To be fair not all of the issues are WSS’s fault — or even WF’s fault for that matter.  The real point — the reminder that Howard provided — was that there are a lot of things that you need to know to get workflows running in SharePoint and there are a lot of ways to fall off the path.

The good news is that I’ve got two sessions addressing workflow at Advisor Summit on SharePoint in Anaheim May 6th-10th  It will be good to get some more time and space to cover this topic and help others with it.  (A sidebar, DevX generously accepted my article even though it was 4x larger than most articles on the web — and it’s still not enough.)

Article: Wranging SharePoint Workflows with Visual Studio

SharePoint and Workflow may be the most powerful combination since chocolate and peanut butter, but the trick is harnessing their combined power. That isn’t as easy as it first seems, but in this article you’ll learn how create a SharePoint workflow in Visual Studio from start to finish.

This article is one small sliver from one chapter of the upcoming SharePoint MVP Book.  17 of the SharePoint technologies MVPs have combined forces to provide one authoritative source for information on SharePoint.  I’m proud to have written the chapter on workflows and WSS.  The above article is one sliver of that chapter.

http://www.devx.com/webdev/Article/34032/

Missing Content Types and Workflows

If you’ve been working with workflows for a while you’ve seen the “Failed on Start” and “Error Occurred” statuses that happen if you mismatch the assembly information or leak an exception back to the workflow foundation, respectively.  However, I found a new behavior.  If you create a workflow that requires a content type through a feature and that feature doesn’t deploy the content type correctly then you won’t see anything when you start the workflow.

When I say anything, I mean it.  You won’t see a status column for the workflow added.  You won’t see a workflow history.  You won’t be able to tell that SharePoint took the command.  However, if you explore the ULS logs you’ll see an error indicating that the content type for the workflow is missing.

When you’re developing it might be helpful to keep the ULS logs handy.

runner

On STSADM and Operation Completed Successfully

STSADM has a comforting message that is presented whenever a command is executed successfully.  That comforting message is simply “Operation Completed Successfully.”  It’s a welcome site particularly if you’ve been struggling to get an XML file just right or if it’s the end of a long day.  However, just because you received an “Operation Completed Successfully” message back from STSADM doesn’t mean the command really completed successfully.

Occasionally, you may run into a situation like I did where I received STSADM’s reassurance that everything was fine but it wasn’t.  I was creating a content type and I had accidentally inserted a space at the end of the content type name.  It was a silly little editing error, but it cost me a whole lot of time.  I didn’t realize that the space was there until a workflow that needed it blew up. That, of course, lead to a debugging session, which lead to isolating the missing content type, which lead to reinstalling the feature, and then several minutes of confusion as I compared the web browser demonstrating that the content type was missing with the response from STSADM indicating “Operation Completed Successfully”

A quick trip into the ULS log or a detailed look at the XML either one will solve the problem – however, for that moment I was confused.

So the moral of this story is … check the ULS log if you want to know what really happened.

Fixing SharePoint 401.1 HTTP errors locally with Kerberos, Integrated Windows Authentication, and Service Principal Names

I’ve had this nagging problem for a while.  Occasionally when I setup SharePoint I do it on a server where host headers are really necessary because I’m sharing IP addresses.  However, it seemed like when I’d do this I could get to the server just fine remotely but locally I’d get a 401.1 HTTP error even if I entered the correct password.  This was frustrating but something I lived with because I could always work around it.  However, tonight, while in the middle of working on a workflow article, I took another run at the problem and actually connected the dots that had eluded me.

When I’m working on the same server as the web site there’s an expectation that I can send a Kerberos-based, login request (Negotiate).  (Kerberos is underneath the covers of AD in Windows 2003 if you didn’t know.)  The same assumption isn’t true from the remote computers.  They’ll try NTLM first.  Both of these fall under the checkmark in the IIS Manager as “Integrated Windows Authentication.”  In fact, there is no user interface to control whether to allow Kerberos, NTLM or both.

I know, that’s all fine and good but how does that equate to a 401.1?  Well, remember I mentioned that this happens when I try to add a host header?  In other words, I’m calling the system something other than what it is defined as in the Kerberos database.  Kerberos being the three-headed dog it is, fails the validation not because the user isn’t authenticated but rather the service principal that IIS is trying to validate with doesn’t match.  Kerberos returns a failure and IIS assumes that it’s the user that made the mistake – not that the administrator doesn’t have things setup correctly for Kerberos.

Rather than addressing a way to setup the server in Kerberos (which I’m sure is possible), I simply turned off the Kerberos authentication in the IIS metabase.  The result is that I can now login from the same server.

In order to do this for your site follow these steps:

1)      Launch Internet Information Services (IIS) Manager.

2)      Expand the local computer and then click on Web Sites.

3)      In the right hand pane locate the site you need to change and its Identifier.  If the identifier column isn’t visible you can select View-Add/Remove Columns… from the menu and select it.

4)      With a note of this number, open up a command prompt and navigate to C:\inetpub\adminscripts.  (Or wherever you’ve moved the IIS administrative scripts to.)

5)      Run the command ‘adsutil GET W3SVC/*YOURIDHERE*/Root/NTAuthenticationProviders’ and press Enter.  Replace the *YOURIDHERE* string with the ID you recorded from IIS Manager.

6)      If the response is “Negotiate,NTLM” Kerberos is turned on, continue on to turn it off.  If you see just NTLM then just NTLM is turned on and just Negotiate means only Kerberos.  The next step we’ll change the value to only NT authentication. (Stop here and you won’t have changed anything.)

7)      Run ‘Adsutil SET W3SVC/*YOURIDHERE*/Root/NTAuthenticationProvider NTLM’.  You should see the “NTLM” string reflected back.

That’s all it takes to turn off Kerberos for a web site and allow you to access it from the local system.

Reminder: CAML requires internal names

I was reminded today that when constructing CAML queries you must use internal names by this wonderful exception:

Exception caught Microsoft.SharePoint.SPException: One or more field types are not installed properly. Go to the list settings page to delete these fields. —>
System.Runtime.InteropServices.COMException (0x81020014): One or more field types are not installed properly. Go to the list settings page to delete these fields.

It’s a pretty ominous message for such a simple issue.

Article:Leverage the Business Benefit of Wikis and Blogs

The old cliché that you shouldn’t judge a book by its cover isn’t the easiest thing to live. Malcolm Gladwell exposes in detail how the first impression can be very powerful in his book Blink: We are conditioned to make snap judgments about the world around us. It’s our primary coping mechanism for the overwhelming amount of information that we’re taking in every day.

It wouldn’t be surprising to anyone that there are features in the SharePoint technology family that scream out that they are for consumer use and not for business. Looking quickly at wikis and blogs, as an example, it might be easy to conclude that they have no place in business. But that initial conclusion may be wrong. Think about the potential amount of business information your company loses each year due to turnover alone. It’s practically a crime not to seek out ways to help capture and retain information that’s being lost today. That’s precisely what wikis and blogs can do for your organization.

View the full text on our Gifts page: Leverage the Business Benefit of SharePoint Wikis and Blogs

Article: SharePoint Localization Tips and Tricks

Living in the United States I sometimes forget that most of the world doesn’t speak English. Sure I occasionally run into someone who speaks Spanish, Japanese, or Mandarin Chinese as a primary language but that’s more of a rarity than an every day occurrence. As a result if you ask me the number of times that I’ve needed to build localized versions of my software the answer would be — not very often. However, just because it’s not something I run into every day doesn’t mean that I shouldn’t be more cognizant and aware of the right practices to support localized software.

In this article, I’ll round up the scattered pieces of information about localization in SharePoint, provide some tips and tricks and leave you with a working approach to localization.

http://www.intranetjournal.com/articles/200702/ij_02_16_07a.html [Website removed]

Debugging with Visual Studio, SharePoint, and Workflow

Debugging is an art form.  Much like regular art it’s influenced by the tools at our disposal.  Photography wasn’t something that Da Vinci was into probably because photography didn’t exist.  He used stone and chisel – canvas and brush – like I use a mouse and keyboard.  (Ok, so he’s a bit more of an artisan.)

Debugging with SharePoint and workflow is like this.  You have to use the tools you have at hand.  As developers we’ve become spoiled by the tools we have.  I start my debugging most of the time by turning on first chance exceptions and F5 (run with debugging.)  If I make it through the application without generating exceptions I’ll generally do step-by-step debugging of critical areas.  I depend upon first chance exceptions to speed my development time.

Unfortunately, trying this with SharePoint Workflow development doesn’t work.  The first chance exceptions are simply not raised to the debugger.  That’s disappointing but not the end of the world.  I wrote code for a VAX system 15 years ago and our most powerful debugging tool besides detailed code walkthroughs was the print statement.  (A detailed code walkthrough is where you try to run the program yourself as if you were the computer.  Not a lot of fun but it’s effective.)

To make things just a tad more challenging the step over (F10) and step into (F11) don’t work all the time nor as you might expect in Visual Studio.  First, you can’t step over an activity that causes the workflow to serialize.  It makes sense since the thread you’re working with goes away but it’s also annoying.  Fortunately you can just set a breakpoint on the next activity to get nearly the same effect.  Also, F10 is a step over but it doesn’t step over containers in the activity it steps into the container and its activities.  It won’t step into the code behind the activity itself so there is some help there.

Of course, the breakpoint idea works well when breakpoints fire but I’ve seen more than one occasion where the breakpoint doesn’t get fired either.  That might cause one to ask how do I debug then? The answer … LogToWorkflowHistoryList … the 21st century version of PRINT.  You can insert them into your workflow – and into your fault handlers and use that to see what is happening in the workflow.  It is not sexy but it works.

One limitation of LogToWorkflowHistoryList is that the HistoryDescription is limited to 256 characters.  If you run into this you can use the OtherData property.  Although it’s not displayed by default, you can see the values.  You can use it for larger strings.  How do you see it?  Point your browser directly to the hidden Workflow History List.  If your server is http://localhost and if your Workflow History List is named Workflow History List you should be able to get to the list by entering http://localhost/lists/Workflow+History+List  This will display the OtherData field on the page – it’s great for use with a fault handler because you can dump the entire exception.ToString() to the .OtherData property to see the exception and stack trace.

So while the tools you’re used to don’t work … that doesn’t mean you can’t find a way to debug SharePoint Workflows.

Recent Posts

Public Speaking