If you'll pardon the blatant commercialization, I'd like to let you know that my latest publishing effort is now available on Amazon.com.  I'm credited as contributing editor and worked with Dr. Bradford for several months to publish Modern ERP: Select, Implement and Use Today's Advanced Business Systems.

You can get a good look at our publicity description here: http://www.ModernERP.com (A Godaddy site)

If you buy it, please let me know what you think.

-robot

Here's some great info on MOSS Search:

/jennyeverett/archive/2008/01/24/more-on-configuring-search.aspx

Nice work Jenn!

-robot

I went to TechNet forums with this error:

http://social.technet.microsoft.com/Forums/en-US/sharepointadmin/thread/cde1b74c-f19d-4b06-9754-d64f20858bfa

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (ea1f2cb4-6fe0-4838-92d7-1e1a908808fd).

Reason: Object 196c41c4-d474-42a2-8bac-f5239cefff2c not found.

It an application error that pops up every minute.

I can't find the object in the registry which might be why it can't be found by the applicaiton.

So I went to Services on Server.  I clicked on the Office Server Search Service.

I entered the password of the service account that the service uses and clicked OK.

When I did, I got a entry in the Application Log that said a new application had been found identifying the same GUID as the one not found above.

Then it also appeared in the registry under HKLM..Office Server SearchApplications.

I reset IIS and now search is working and the error has quit… for now.

What I don't know is what triggered it in the first place.  Search had been working and then it quit and that's when the errors started.

-robot

Earlier, we installed the WSS and MOSS management pack in our SCOM server.

Now, when we explore the Authoring tree, under Management Pack Objects node, we get a Rules node.  Here we get all the rules that the server can attempt to enforce.  At the top of the Rules window, on the right, there's a Change Scope link that pulls up a dialog box exposing all the potential targets that are associate with the server's management packs.

If we uncheck them all, we can select only:

• Microsoft Office SharePoint Server 2007 MOSS Server
• Microsoft Office SharePoint Server Application Installation
• Microsoft Windows SharePoint Services 3.0 WSS Server
• Microsoft Windows SharePoint Services Application Installation

When we click OK, the Rules window resets to a grid with our four Type headings.  When those headings are expanded, they reveal a number of rules SCOM will attempt to enforce on our MOSS Server.

The server nodes contain rules that include a rule name that is probably unique to SCOM.  But the properties of each rule includes a configuration tab that associates the rule with:

• An Object
• A Counter
• An Instance

These values map back to the counters in the Windows Performance application found under Administrative Tools.

The applicaiton nodes include a rule name and properties that map our to items in the application and system logs that you find in your computer management mmc.

You can override these rules or add your others.

hth

-robot

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.

-robot

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 http://technet.microsoft.com/en-us/library/bb309622.aspx. 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".)

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.

-robot

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.

HTH

-robot

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 [email protected]
• 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.

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: http://office.microsoft.com/en-us/sharepointtechnology/HA101130181033.aspx?pid=CH100649861033

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.

-robot