Showing posts with label troubleshooting. Show all posts
Showing posts with label troubleshooting. Show all posts

Friday, September 10, 2010

It started with not being able to activate wiki page home page feature (or issue with features if you load balance your site...)

I am currently super, super busy finishing up chapters in the SPF book, but I needed to write this down somewhere...

So I finished writing the first draft of chapter 16. It involved, among other things, installing a second server on the farm and enabling load balancing so the readers could see it in action.

That meant that, at this point, my virtual machine of my SharePoint Foundation installation has two SPF servers load balancing content.

I was reading over some edits of one of my chapters and needed to see the home page without it being a wiki page for a moment. Now, there are a couple of ways to do that, the easiest being deactivating the wiki page home page feature (yeah, funny name) , the next easiest being deleting the Home.aspx page from the Site Pages library real quick (restoring it from the recycle bin takes seconds).

I am really, really behind on my edits, so in my rush, I just deactivated the feature.

I checked the stuff I needed to check, then went back in to re-activate the feature-- and it failed. I went to the other server in the set, and it failed there. I did an IISRESET on both, still failed.

I dropped to the powershell console and tried a get-spfeature command (it brings up a long list of features available for the farm at the moment). Wiki page home page was listed.

So I marked the ID of the feature (okay, so I am an old skool admin, not a developer, and it's just easier for me to grab the ID than write a bunch of pipe stuff. I keep it easy)

I then tried to enable the feature for the site manually, using the enable-spfeature command:

(EDITED TO ADD: blogspot deleted the tag I wrote originally about the identity value.. sorry for those of you who thought you could just leave -identity could be empty. Darned blogger...)

enable-spfeature -identity (paste marked ID here) -url http://theurlofmyrootsite

And it failed, saying " Enable-SPFeature : The Web application at http://spf2 could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application."


What?! I know that site exists, and that I typed it's URL correctly, I was just on it.


I tried an IISRESET, no luck, on both servers, still no luck...


So I tried the same command on the other server, thinking maybe it had something to do with it. Nope.


Then I realized something. I had changed the default zone of the site to be the load balanced address.


::head smack:: Doh!!


I then reran the command but with the load balanced address. (in my case that would be http://sharepoint)


enable-spfeature -identity (paste ID here) -url http://sharepoint


And it worked perfectly!

So what does that say?

It says that in the GUI, ie in the Manage Features for the Site page, when you hit the Activate feature button, it points to the site's original URL when the site was created-- so if you change the default zone for the web application of the site you are activating features on, and you don't include the old URL in AAM to point to the web application, the Activate button might not work.


Bottom line: Either plan to activate or deactivate features via PowerShell if you remove the original URL from AAM for the site, or always include the original URL in AAM for a site (even if you don't want users to use it).

Monday, May 19, 2008

Holy moly this problem used to plague me-- or "Update conflict has occured..."

During the final chapters of the book, I occasionally would run into an error when making changes to AAM or adding a subsite; "An update conflict has occurred, and you must re-try this action." Nothing I did seemed to fix it. Because I was really, really desperate to meet my deadlines and didn't have time to deeply troubleshoot anything at that point, I just gave up on that action on that VM, shut it down, opened a different set, and continue work from there.

After the book I immediately started revising courseware for Microsoft, so I didn't get a chance to catch my breath and try to troubleshoot anything. Following that, I immediately needed to prep for a conference, at which I came down with pneumonia, and well, now here I am.

Meanwhile, MS has just come out with a revised version of KB article 939308, which finally mentions the problem and its solution.

Bottom line? "This issue occurs if the contents of the file system cache on the front-end servers are newer than the contents of the configuration database."

Mind you, MS is assuming this problem is occuring only when a configuration database has been recovered and that's why it's out of date. But, it has happened to me on slow networks as well.

So what is the fix? Clear the file system cache on all servers, of course. Yeah, it's a pain, but it at least gets everyone back on the same page.

For more details visit KB article 939308 http://support.microsoft.com/kb/939308/.

So now I know (and you do too).