Archive for August 2008


Kerberos SPN Command Calculator

I know you guys are tired of hearing me go on and on about Kerberos but I think you’ll like this.

  1. Don’t forget to set SPNs for your each of your hosts and for each of the various host headers used in your alternative access mappings.  This means if you set an SPN for http://portal, you’ll also need one for http://portal.MyFirm for your intranet host and you’ll need http://portal.MyFirm.Com for internet.
  2. Since all those SetSPN.exe commands are so complicated, I built the SPN Command Calculator, an excel spreadsheet where you enter your host names and your service accounts and it calculates the command strings you need to set the SPNs.  You can thank the guys at SharePoint blogs for hosting it and letting you download it.

Let me know what you think.


MOSS and SCOM 2007

We built our server farm and we have this other computer that runs SCOM 2007.  The challenge is to get one to work with the other.

I found the SharePoint Monitoring Toolkit here.

This page has four download buttons:

  1. MOSS Management Pack installer (.msi)
  2. A zip file with "Guides" (.zip)
  3. A Readme (.rtf)
  4. WSS Management Pack installer (.msi)

The Readme is three pages and has some good inrfo on files locations and known issues.  These all have work-arounds and do not seem to be gate issues.

The "Guides" zip file includes .doc and .docx versions of the MOSS and the WSS management packs.  The MOSS doc is 101 pages.

The guide opens with perfunctory boilerplate and then begins with a Getting Started section. These instruct you to import the .mp file into your SCOM console.  This is a problem because we don't get a .mp file, we get a .msi and while some of you may know how to reconcile this distinction but I can only guess that I run the .msi and I get the .mp.

Sure enough, I run both .msi files and I end up with a C:Program FilesSystem Center Management Packs folder and it's got a MOSS and a WSS folder, each with a Management Pack folder with my .mp files inside.

The guide continues to instruct us to open the Operations Console and import the .mp files.  As far as I can be sure, this is my first venture into SCOM and it's Ops Console.  It looks alot like SQLServer 2005.  You find the Administration tree and right-click on management packs and select Import where you can navigate out to the .mps and import them.

That should give us a set of default monoitoring activities these can be modified and other can be created.

Next, we have to add the managment agent and we're pointed to Here we see we have a number of options:

  1. Deploy the agent from the SCOM console.
  2. Deploy the agent directly on the target compuer (a "manual agent install")
  3. Deploy the agent from a command line.
  4. Deploy the agent by including the target in a group.
  5. Deploy the agent to a member of Multiple Management Groups (called "multihoming".)

Selecting the first option, takes me to the instructions on TechNet that introduces me to the Discovery Wizard that describes a three step process: Discover, Select, Configure.
Of course, my lab guys have this in one domain and I need to monitor a server in another.  I try a number of computer name options and user options ending up at the IP address and the local administrator account but, alas, the Wizard cannot discover the server.




The Standard View of your list is being displayed because your site configuration does not support the Datasheet.

I have a site where anonymous access is allowed and, if I haven't logged in, when I browse to a datasheet view, I get a standard view with this note at the bottom:

The Standard View of your list is being displayed because your site configuration does not support the Datasheet.

Which is fine, I guess, except for two things.

First, I don't believe a configuration option is available for a view that will make it appear as a datasheet for anonymous users.

Second, if your default view is a datasheet and it's available anonymously, Google will crawl the page and index the error message as part of the page content.  Consequently, if you do a search for the error text, you find eight bazillion pages that allow anonymous access to views that use the datasheet as the default view.

And that's okay too, except it makes looking for a possible configuration option that doesn't exist alot more difficult.

On the good side, you can get an idea of what people are doing with their SharePoint lists like the guys at idvsoutions, here.



IE Crashes When Opening Library Documents

MS IE has encountered an error and needs to close

Everytime you try to open a document in a document library.

Apparently this arises when you have a mismatch in Office program versions such as SharePoint Designer, which is Office 12, and Excel 2003.

Our new pal, Brian, who writes a blog here, tells us MS has a hotfix here.



Kerberos (Again)

This is obviously one of the trickiest tools in the MOSS box.

Previously, I referenced this industry standard post from Martin Kearn.

And now we have this from TechNet.

And this from TechNet Blogs.

Installing it is one thing; proving that it's working is another.  For example, what happens when it doesn't work?

So we've got this Kerbtray.exe tool from the Win2K Resource Kit.

When you install it, it doesn't make a menu item to open it so you have to go to your C:Program FilesResource Kit folder to run it from the .exe. 

When you run it, you get a system tray icon and when you click on the icon, you get a cool little windows app that shows you:

  • Client Principal – This looks like me because it says Robot@MyFirm.MyDomain.Net
  • A tree of what looks like IDs spilling out of MyFirm.MyDomain.Net – these are kind of cryptic; one is cifs/SomeComputer.MyFirm.MyDomain.Net.  Another is host/MyComputerName.MyFirm.MyDomain.Net.  There's others including this one that kind of makes sense: LDAP/SomComputer.MyFirm.MyDomain.Net.  I think the "SomeComputer" is actually our local domain controller.  Some of the others are duplicates.
  • A box headed Service Principal (spelled -P-A-L meaning "lead person", not "idea.")
  • A tabbed table with heading for Names, Times, Flags, Encryptions Types.

The Names tab includes three fields, Client Name, Service Name, and Target Name.  When I select a different node in the tree, the lead value in the Service Principal box changes to match and the names then change accordingly.

I'm going to log out, reboot, log in with a local account and then see what it says.

Much as I suspected, when you log in locally, the little application is blank and it says No Network Authentication.  I tried logging into my SharePoint site that is supposed to be running Kerberos and still nothing.  I also tried executing a RunAs command and using my network ID and still, nothing.

So, apparently, they've updated our MOSS "Infrastructure" and you have to have this update: Description of the Microsoft Office Servers Infrastructure Update: July 15, 2008  This update says to update be sure to run the WSS Infrastructure Update first.  This upate lives here: Description of the Infrastructure Update for Windows SharePoint Services 3.0: July 15, 2008

So the question arises, have these already been installed using the automated update programs?  No sweat, it says it will tell you how to tell if these updates have already been installed.  To do this, it gives you a set of files names with size and date info and I guess you're supposed to see if those files are already on your server.  My problem is that it doesn't tell me where to look for them.

Anonymous Access to Document Libraries

This one is pretty peculiar.

If you allow anonymous access in IIS and you allow anonymous access in your web app's authentication provider (in CA Application Managment) you can set Anonymous Access on the site's Advanced Permissions page by selecting Anonymous Access from the settings menu.

If you select Nothing, when you select the Anonymous Access option from your doc library permissions' Settings menu, the Change Anonymous Access Settings page displays but all the options are greyed out.

So, let's say you go to your site's Advanced Permissions and select Anonymous Access from the Settings menu and select Entire Web Site.

Now, when you look at the permissions for a list you can select Anonymouse Access from the Settings menu and you'll get a Change Anonymous Access Settings page with four options: Add, Edit, Delete, andor View.

But if you look at the permissions for a document library, when you select Anonymouse Access from the Settings menu, you'll get a Change Anonymous Access Settings page with four options: Add, Edit, Delete, andor View but the first three are greyed out.

Does this mean that anonymous contributions to document libraries are not possible with WSS?

I guess it does.  If you look here:

You notice the Note at the bottom: Note   Only the View Item permission is available for libraries. This is to help protect your site from potential script injection attacks.

Great, another elegant solution squashed by overbearing security.