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).

Stupid shortcut tricks, or how to get an elevated shortcut to open a command prompt window in the SharePoint root folder on 2008 R2...

So I'm writing the SPF book, and I always create a shortcut to the SharePoint hive (now called SharePoint root) BIN folder on my SharePoint VM so I can quickly get to STSADM if I need it.

I tried to do so this time (in a hurry and not expecting problems), and I ran across a "known feature" of 2008 R2, where if you create a shortcut for the command prompt, and have it start in the long path to the BIN folder, it will work-- as long as you don't set it to run with elevated privileges (and STSADM won't run in a command prompt, regardless of your login, unless you run it as administrator). If you set the cmd.exe shortcut to run with elevated privileges-- it always only starts in the system32 folder. That's supposed to be safer.

Safer?  To specifically open to the system32 folder if you are running an elevated command prompt? Wouldn't it be safer to have an elevated prompt open many other folders than system32?

Am I missing something?

But, regardless of that shortcoming, I still need a quick way to get to the BIN folder from the desktop.

So here's what I did...

...I created a batch file that opens the command prompt to the correct path, then a made a shortcut to that, and set the shortcut to run as administrator.

To do the batch file, I just used notepad, saved the file with the BAT extension (make sure you don't have hide extensions on, or the file will have a hidden TXT extension) - then I typed in notepad:
@echo off
cmd /k cd "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN"

Then I saved the file and closed it.

Then I made a shortcut of it (right clicked it and selected create shortcut). Then, to set the shortcut to run with elevated privileges, I right clicked it, went to properties on the popup menu. In the dialog box, on the shortcut tab, I clicked the Advanced button, then selected "Run as administrator". then I clicked OK to save the change, and OK again to close.

Now all I've got to do to get a command prompt that is running as administrator and starting in the BIN folder, is double click the shortcut.

Just thought you should know in case it happens to you.

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).

Interesting URL trick-- How to Get a SharePoint Server on the Farm to Use Its own Local Central Admin Site

So I am in the end run for editing the book and I, of course, ran into something that has absolutely nothing to do with what I am doing...

...Bill Baer has a great little blog article about changing the URL address of a Sharepoint server's default Central Administration site.

I've always hated how, by default, even if you enable Central Administration on a second (or third, or fourth) sharepoint server in the farm, that server never actually points to its own Central Admin site's address.

Now I've always thought that I needed to add it in the Alternate Access Mapping, but according to Bill Baer, it's a registry thing. That each server has a hardcoded URL that it uses for its access Central Administration site. According to the blog entry, you need to change the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS. Locate CentralAdministrationURL and edit the value to reflect the desired location.

Check out the blog entry at: http://blogs.technet.com/wbaer/archive/2007/08/30/sharepoint-3-0-central-administration-url-on-multiple-web-front-end-servers.aspx