Here's some great info on MOSS Search:

http://www.sharepointblogs.com/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 Search\Applications.

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 Files\System 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 Files\Resource 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.

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, and\or 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, and\or 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

Maybe some of you brainiacs know why, but yesterday, I turned on the Remote Procedure Locator Service on my Server 2003 and restarted the timer service and, now, all of a sudden, my alerts have started working.

In the past, the "You have created an alert" message would go out but the alerts would not.

I think I have both immediate and scheduled alerts working for the first time.

-robot

Sure, we'd like to have inbound eMail working because it can do alot for corporate communications.  Our friend, Joel, has a great outline of these capabilities here. 

When I try to enable inbound eMail for a document library, I click on the link on the list settings.

You can set the inbound mail to sort into folders depending on subject or sender and you can tell it to overwrite files.  I presume, if the library is set for versioning, overwrites will create a new version.

I can't tell because, when I click OK on the Inbound Email Settings page, I get one of those ugly SharePoint errors that says:

The request failed with HTTP status 401: Unauthorized.

Troubleshoot issues with Windows SharePoint Services.

I always wonder if we'll ever see those people again that click on that bottom link because, once you do, you are in Hell.

So, digging around, we find this.  Seems to be perfectly on point.  It says:

To enable or configure incoming e-mail support for a list or library, you must have the Manage Lists permission on the list or library. The Manage Lists permission is granted by default to the Site name owners SharePoint group.

I don't see a Manage Lists permission on the doc library.  All I see is Full Control. And, otherwise this page doesn't help.  Even though I have the "full control" permission, I get the unauthorized error.

At this point, I tried a new blank team site and created an discussion board.  During the creation process, I checked the Enable email option and gave it an email address.  When I clicked OK, I get an Operation Completed page that says:

The list was created successfully, but could not be assigned an e-mail alias because of the following error: The request failed with HTTP status 401: Unauthorized.

So I check the Windows Event Logs and I see I have some number of these:

The Execute method of job definition Microsoft.SharePoint.Administration.SPIncomingEmailJobDefinition (ID f940c454-b2f0-4bb0-bdec-fa034f5e6ee7) threw an exception. More information is included below.

Value cannot be null.
Parameter name: path

On MSDN, I see that someone else has the exact same problem.

I've seen several references to this from our new best friend Steve in the UK.

-robot

This is peculiar:

When I'm looking at my server's console and I try Start | Programs | Microsoft Office Server | SharePoint 3.0 Central Administration a browser opens pointed to http://MyServer:12345.  I get a log in prompt that says: Log in to MyServer.MyDomain.Local.

No matter what I enter, I am not getting logged in.  I try my setup account which is a domain admin.  I try other domain admins.  I try my DB Access account and all my service account.  After three tries, I end up with "You are not authorized to view this page."

I try reworking the URL to http://MyServer.MyDomain.Local:12345 and I try http://LocalHost:12345 and neither works.

The only thing that works is the IP address with the port number.

When I try the Central Admin site from my desktop, I get the Central Admin site, no sweat.

This seems suboptimal.

-robot

We like to think that the transition from list to spreadsheet is almost seamless.  And I've delivered some great solutions that allow users to manipulate spreadsheets on their local hard-drive and then upload the data to a suitable list on the portal.

However, this time, I'm trying to get the spreadsheet import to work.

So I have this spreadsheet with field validation, hidden columns and conditional formatting and I try to point my import browse button to it and I get an error box that says:

Import to Windows SharePoint Services list
Object doesn't support this property or method

When I click OK, I get the spreadsheet and the Import to Windows SharePoint Services list dialog box where I can select a Range of Cells, a Table Range, or a Named Range.

When I select a range of cells, drag my mouse across the desired cells and click Import, after I get prompted for a login, I get this error:

Import to Windows SharePoint Services list
Method 'Post' of object 'IOWSPostData' failed

Turns out this was all my fault because I've installed the SharePoint Designer which is an Office 12 product.

This action created an Office12 Folder under C:\program files\microsoft office\.

The problem is the EXPTOOWS.XLA file and it's accompanying EXPTOOWS.DLL file that live in the \Office 12\1033 folder.  So I renamed these two files by adding a .12 extension to them and I copied the same files out of my

C:\program files\microsoft office\Office 11\1033 folder

and pasted them into my \Office 12\1033 folder

No more problem importing spreadsheets.

hth

-robot

When I run a search on *.exe in the \12 folder, I get:

1. HCINSTAL.exe - This appears to be the executable that will install the Help Collection.  It is sometimes an issue when language packs are installed as noted here.
   
   
2. MSSDMN.exe - This is a process related to populating full text indexes as noted here.
   
   
3. MSSEARCH.exe - Also related to indexing on SQL Server but can also be used for Exchange.
   
   
4. OWSTIMER.exe - This is the program that tracks SharePoint's "to do" list.  It is critical for alerts and use logs.  There's a pretty good description here.
   
   
5. PRESCAN.exe - This is a program that analyzes your site to identify issues before you upgrade a site.  Technet has a good description here.
   
   
6. PSCONFIGUI.exe - The only references to this executable I found are in hotfix description on Microsoft.com.  I think it's the configuration wizard.
   
   
7. SPWRITER.exe - This is the volume shadow copy service (VSS) reference writer and most of the references we find are discussion about hotfixes from Microsoft.
   
   
8. STSADM.exe - This is the admin command line console.
   
   
9. WSSADMIN.exe - This is the service that runs the various administrative functions.
   
   
10. WSSTRACING.exe - Not sure what this one does.  Jose says it logs records out to the diagnostic log file.

Jose's post is actually a very good description of baseline MOSS performance indicators.  If you've got better links or explanations, I'd love for you to share them.

-robot

In a brand new three server farm, I'm opening up the User Profiles and Properties page from the SSP Admin site.

I get the red "X" with this error:

An error has occurred while accessing the SQL Server database or the Office SharePoint Server Search service. If this is the first time you have seen this message, try again later. If this problem persists, contact your administrator.

The only log entry I can attribute to this action is in the WFE's Application log and I've copied the error below.

Source: Office SharePoint Server
Category: Office Server General
Event ID: 7888
Description:
A runtime exception was detected. Details follow.
Message: The request failed with HTTP status 503: Service Unavailable.

Techinal Details:
System.Net.WebException: The request failed with HTTP status 503: Service Unavailable.
   at Microsoft.Office.Server.Search.Administration.SearchApi.RunOnServer[T](CodeToRun`1 remoteCode, CodeToRun`1 localCode, Boolean useCurrentSecurityContext, Int32 versionIn)
   at Microsoft.Office.Server.Search.Administration.SearchApi..ctor(WellKnownSearchCatalogs catalog, SearchSharedApplication application)
   at Microsoft.Office.Server.Search.Administration.SearchSharedApplication.get_SearchApi()
   at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager.<>c__DisplayClass3.<GetImportStatus>b__0()
   at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

So, in digging around, I got this one hint from an acquaintance at MindSharp.com:

IIRC, this is a permissions error in that the particular SharePoint Server 2007 service cannot access the SQL database.

Which leads me to the following questions:

1. What's IIRC
2. Which MOSS 2007 service would we be talking about, the SSP Admin service?
3. Which SQL Database?

So to work past all of these questions, I added every service account to a group on the SQL Server and then created a SQL Server Login for that group with the sysadmin server role and made it dbowner of every database.

Alas, to no avail.  Apparently, there's something between the server that's running the SSP Admin service and the SQL Server that acting gnarly.

I'll fix it.  It'll rue the day...

JK

So the system log fills up whenever I try to look at the user user profiles.  The system log error is this:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{3D42CCB1-4665-4620-92A3-478F47389230}

to the user MyDomain\mosssspsvc SID (S-1-5-21-1875211509-1510927935-777304043-47821). This security permission can be modified using the Component Services administrative tool.

The User Profile page says this:

An error has occurred while accessing the SQL Server database or the Office SharePoint Server Search service. If this is the first time you have seen this message, try again later. If this problem persists, contact your administrator.

I found a couple of reports like this one that say to search for the CLSID in the registry and then get the associated App ID and look for the App ID in Component Services under the DOM Config heading where you have to convert the view to a list view to see the App IDs.

When I do that, I get the OSearch Application and I set the Local Activiation permissions so allow Local Activate for my MossSSPSvc user but the errors wouldn't quit untill I rebooted the machine.  Apparently, something in that process got everything reset except the User Profiles and Properties page issues.

I'll ge to it next.

-robot

You may recall we discussed Kerberos authentication here.

And we linkd to two great posts, one, here, from Martin.

And as we worked through the process, it started to make some sense.  We quit when we got to configuring component services, I guess out of sheer laziness.

Well, now, I'm digging through the Windows Security log and I'm seeing these 10016 errors that say:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{61738644-F196-11D0-9953-12345ABCDEC1}

to the user MyDomain\mossapppool_01 SID (S-1-5-21-1234567899-1510927935-777304043-47828). This security permission can be modified using the Component Services administrative tool.

To me, this is obviously a "two-hop" issue.  So I go back and look at the component issues from Martin's post.

Now, this is the first time I've ventured into Component Services which is a Server 2003 Administrative Tool mmc.  Martin says to drill into the properties of My Computer and change the Default Impersonation Level on the Default Properties tab to Impersonate.  This makes sense if I'm telling My Computer to assume that it's impersonating someone else when it runs a component that needs to "Hop" to connect to another computer.

The the only other issue is in the DCOM Config folder under My Computer where we have to look at the IIS WAMREG admin Service.  Here we select the Security tab and edit the Launch and Activation Permissions adding our app pool identities and giving them Local Activation permissions.  Then, I presume I'll need to do the same to my SSP server that's also a WFE server.

And the hope is that this will eliminate the 10016 Errors from the security log.  We'll see.

-robot

So, now that I have the farm operational, they want SP1 installed.

The first thing I found was this:

Planning and Deploying Service Pack 1 for Microsoft Office SharePoint Server 2007 in a Multi-server Environment

And then, I downloaded the WSS SP1 language pack install instead of the WSS SP1 install so be sure the WSS file you're using is:

wssv3sp1-kb936988-x64-fullfile-en-us.exe

I guess you might have the x86 version or non-us-english versions as well but, the important point would be that is does not have an "lp" in the name.

Then, our new friend, Shane, covers it pretty good here.

I can add that, on the multi-farm install, I had trouble when I tried to run the Configuration Wizard on both WFE servers at once.  It seemed to like running one and then the other better.

-robot

I love writing about technology for reasons just like this.

We've got a launcher service that won't launch.  Owen Wilson would be proud.

Just when I was getting ready to finish up my Multi-Farm Deployment Guide before the weekend, I look at Services on Server and I see that my Document Conversion Launcher Server is still Starting.  And since it's been about 24 hours since I started it, I'm guessing that means I have a problem.

The good news is tha our new best friend Karthik ran into this before we did and he told us how to fix it here.

First, the question arises how do you make it quit saying "Starting"?  I opened the DCLS page and changed my load balancer server from my server to "none" and clicked OK.  So now, on the Services on Server page, it says "Stopped."

Now Karthik's instructions are not perfectly clear to me so here's what I'm going to try:

I'm looking up the port number on the DC Load Balancer Service Settings page and it's port 8093.  This is different from DC Launcher Service port number.

I'm looking up this key in the regisry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\LauncherSettings

Sure enough, there's a LoadBalancerURL key and a Port key.

My Load Balancer is running on server named MySSPServer so I'm setting the keys as follows:

• LoadBalancerURL: http://MySSPServer:8093/HtmlTrLoadBalancer
• Port: 8093

Karthik follows by saying that the Launcher Service should be stopped and restarted in the Control Panel | Services MMC.  In my case that service had not been enabled.  I changed it to enabled and automatic like Karthik, said and then I started it.

Now, I have to admit that, first time through, I was using the wrong port number. Then I realized I should be using the Load Balancer Service port number, not the DC Launcher Service port number.  So I stopped everything again and started over and still had no luck.

Karthik continues to suggest a restart using stsadm.  His instructions include a routine to run the enumservices out to a text file and then use the values form the text file to fill in a provisionserivce command, first stopping, resetting IIS, starting and resetting IIS again.

His instuction are kind of complicated but my provisionservice calls looked like this:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o provisionservice -action stop -servicetype Microsoft.Office.Server.Conversions.LauncherService -servicename dclauncher

And:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o provisionservice -action start -servicetype Microsoft.Office.Server.Conversions.LauncherService -servicename dclauncher

He says you'd have to do this again when you add servers but I'm not so sure that's in the cards.  I'm also not sure a simple IIS reset would have sufficed after I stopped the service and then again after I started it.  But, in any event, the DCLS is now "Started" and, if it's ever needed, it might work.

Thanks for reading along!

-robot

ps. Oh, my friend that's a spokesrobot for Server 2008 is currently appearing on LinkedIn.com.  I could have had that gig if I had spent more time in server school.

He's offering a MOSS deployment class in New York and San Francisco.

Alas, I can't go (short notice) but I did look at the syllabus here.

And it occurred to me that what he's done is given us a pretty good index of what you need to know when you try to pursuade people that you're a qualified SharePoint architect.

Better get busy..

-robot

We've struggled through alternate access mappings (AAM) once before on a single server farm but we should take a look at the multi-server farm approach.  I'm not sure I have a complete grip on the topic but I've gotten some sense that I'm getting it correct.

You'll recall we have a total of four web apps:

Central Admin runs on MyWFEServer:63999
Portal runs on MyWFEServer and MySSPServer using a host header Portal.
SSP runs on MyWFEServer and MySSPServer using a host header SSP.
MySite runs on MyWFEServer and MySSPServer using a host header MySite.

The two servers and the DB server run in a domain called MyDomain.Local.  The MyDomain.Local DNS server includes A records that point all three, Portal, SSP and MySite, to the IP address of my WFE server.  MyDomain.Local is piped to the internet using the MyDomain.MyCompany.net URL.

So, there's a fourth computer in the domain that I can log onto and open a browser and point to http://Portal and, since I built the portal using the Enterprise Collaboration template, I see the dorks.  I can also point to http://MySite and I'll get my site except that my administrator has not yet allowed self-service site creation. 

http://SSP still has me a bit confused because I get a 404 unless I browse to http://SSP/SSP/Admin.

Still, all three work. 

So I go to Central Admin and click on Alternate Access Mappings and then Edit Public URLs.  Here, I select my MySite mapping collection and I enter the following:

Default: http://MySite
Intranet: http://MySite.MyDomain.Local
Internet: http://MySite.MyDomain.MyCompany.net

This is where it's cool to have not stolen your IIS default web site for your portal app.  When I created my web apps for my SSP, MySite and Portal, I did not use the Default Web site.  That site still runs and still displays the Under Construction page when you browse to the server.  I have to have either hosts file or DNS support for my host headers and those host headers have to included on the dialog box you get when you click on the Advanced button on the Web Site tab of the web site's Properies in IIS. 

So, in DNS, MySite is the same as MySite.MyDomain.Local and it points to my WFE server's IP address.  The Host Header on my MySite web site in IIS tells my WFE server: "When you get a requrest on Port 80 and the host header is MySite send it to the MySite web site."

Now, when I browse to http://MySite, I get MySite but when I browse to http://MySite.MyDomain.Local, I get Under Construction.  Perfect.  What's happening is the DNS is sending me to the correct IP address but IIS fumbles the host header.  So I add the MySite.MyDomain.Local as a host header using the advanced button on the web site tab of the MySite web site properties.  I reset IIS and try again and...

I get the error that says "Your administrator has not allowed for self-sevice site creation"  Which is both perfect and perfectly unacceptable.

All I have left is the internet settings and this is a DNS issue for the DNS server that supports MyDomain.MyCompany.net.  Those are other cats and they need a help ticket so I'll have to wait for that.  But I"ll also have to add the new host header to the web sites.

This will leave me with just four issues:

1. The http://ssp/ssp/admin thing is silly.  I should just be able to browse to http://ssp and land on http://ssp/admin.
2. When I add the host headers, I have to do it individually to each of my WFE servers.
3. I'll have to get on that Admin guy about the self service site creation.
4. The dorks, I really need to figure out how to get them off my portal BEFORE I install it.

Thanks for reading along.

-robot

ps. you know Microsoft has a friend of mine pimping for Server 2008.  I'll have to get that ad and show you.

I've always been one that thought if I followed the directions, I should end up with an expected result.

My bank doesn't agree.  Not only is their web site misleading, but it also doesn't work.  And then, when you call their "Customer Service" number, the automated voice lies to you and you end up stuck where you can't get out and you have to call back.

I can change banks but, alas, I can't change Microsofts and I can't change SharePoints; there's only one of each.

So, if your following along, you're aware that I'm trying to get a three server farm running.  And I'm trying to do it exactly like the instructions say.

At this point, I can see Central Admin and I'm running the the Read First... task that says Read the Quick Start Guide.  So I'm reading the Quick Start Guide and it's got a section for server farms.  Here, the first heading is configure services.

The first service is the MOSS Search Service.  Not a problem.  I have a dedicated index server and a dediated service account.  I did make a note that the insctuctions do not specifically tell you to select your index server from the change server option in the pull down list before you tell it to Use this server for indexing content or Use this server for serving search queries.

The second service under this heading is the Web App Service. I found that this paragraph incorrectly suggests that the Web App Serivce would NOT be running on my servers since I installed them as Compete servers.  Both my server were, in fact already running the Web App Service.  Not correct, but not a problem.  I figured I was rolling.

The next heading is Configure the Shared Services Provider.  This involves creating web apps for the SSP admin site as well as for MySites.  Now I like my MySites to have their own host header because I want my users to be able to just type http://mysite in their browser and get their MySite.  So they need their own web app.  In addition, No matter what I do, my SSP admin site ends up with a URL of http://ssp/ssp/admin which seems silly.  But I got Shared Services running and I got my SSP Admin site.

Am I rolling or what.

Well, the correct answer would be "what" cuz here the wheels fall off.

The next item on the Quick Start Guide is Configure Indexing which should be no problem.  The first step is Configure default content access account. No problem, I got one of those.

Then we get to Content sources and crawl schedules.  Of course, I want to crawl my local MOSS sites so I edit that item in the list.  All I need to do is create the crawl schedule and, sure enough, there's the Create Schedule link.  I click it and fill it out and stick your fingers in your ears:

Access is Denied (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

So we go looking and meet our new best friend Andy who points us to: http://support.microsoft.com/kb/926959

Apparently we have to add the wss_wpg user to the tasks folder but the taks folder is a system folder that does not have a security tab so we have to make it not a system folder, add the user and then make it a system folder again.  Sounds kind of like my bank.

So at the command line, revert the tasks folder to a common folder by running this:

attrib -s c:\winnnt\tasks. 

You have to restart Windows Explorer to see the changes but, now, when you right click on the tasks folder and select Properties you see it has a Sharing and Security tab like all the other folders.  On the Security tab, you add the wss_wpg user.  It matters that this is a local user and not a domain user because you have to change the source location by clicking on the location button.  The kb article says to give the user read and write permissions.  That's simple enough and then you click Apply.

Don't forget to go back to your command line and run

attrib +s c:\winnnt\tasks. 

This will reset the system folder attribute on the tasks folder.  Now when you right-click on it and select Properties all you'll see is a General tab.

Then it says to restart IIS so I restart IIS on both servers and try my schedule again.

Thank you for banking with us.  I think I will change banks, the new branch up at the corner has a hot ATM.

-robot

So I guess I'm not the only one a lttile confused by the installation of multiple server.

What I've found is this.

Central Admin will be installed on our first WFE server and it will run on only one server.  When you're  adding additional servers, you get an advanced setting that will allow the new server to steal Central Admin from a previously configured server.  You avoid any nastiness by installing your designated CA server first.

Second, all your IIS web apps will be deployed on all your WFE servers.  I think, if you turn off the Web App Service on a particular server, those web apps will dissappear from IIS.

You can run the indexing service on only one server.  If that server is also running the Web App service, it will have a  local copy of the web apps that it can crawl and you can configure the indexing service to only  use that server for crawling.

Right now, I'm running through the CA Admin tasks and I'm getting an error trying to schedule the index crawls.  I'm going to write a post about it and then I'm going to come back to this topic of services on servers in a three server farm.

-robot 

As a deminstration, I'm attempting to deploy a three server farm in a virtual domain.  I'd like to include as many technical complexities as possible so I don't simply want two WFEs and a DB.  What I want is a dedicated WFE and a dedicated Index\App server that will handle everything EXCEPT the content web application.

So, I'm seeing some of this stuff for the first time.  And the way I looked at it, there's a couple of discreet steps to the whole process:

1. Do a ton of pre-installation steps like creating your service accounts, installing IIS, .Net and getting your DB server running. 
2. Run the SharePoint setup.exe on all your farm servers; the db server does not actually need SharePoint.
3. Run the configuration wizard on each of the SharePoint servers.
4. Perform the adminsitrative tasks that configure the MOSS applications.

Now, we've covered the install pretty good as far as the pre-install steps are concerned.

But the setup.exe program provides us with our first chance to screw something up.  During the setup routine, we can decide on a WFE or a Complete install.  You can also select Stand Alone but that's the SQLExpress solution that's not really relevant to our purpose.

I seems like I want one WFE server and one Complete server.

So, we want to deploy the classic three-server farm and found this nice link here from SharePointForum and another from TechNet here.

So I've got MyDBServer that's running SQL Server 2005. 

My other two servers are called MyWFEServer and MySSPServer.   I want MyWFEServer to run the CA website and my user site collection(s) while I want MySSPServer to run everything else.

I installed SharePoint on both and, before I ran the Configuration Wizard, I took virtual snapshots so I can roll back at any time.

Then I ran the Configuration Wizard on MyWFEServer.  I pointed to MyDBServer and selected Kerebos Authentication.  That ran and eventually opened up the CA web site.

Then I ran the Configuration Wizard on MySSPServer.  I pointed it to the SharePoint_Config database on MyDBServer, selected Kerebos Authentication and it ran and ended up pointing to the CA website on MyWFEServer.

Great, I've got three servers in my farm.

If you're like me, when you get CA running, you'd just like to stare at it for a while before you do something that screws it up.  Well, no time for fun, we must move on.

The question I have is where do I tell SSP to live on the other server?

Well, CA has a list of Adminsitrative Tasks and I started at the top.

1. Read the Quickstart Guide - This has a link to a web page that includes a section called Learn how to deploy Office SharePoint Server 2007 in a server farm environment.  It says to do what I've already done, install SharePoint on all the Front End Web Server.  Now at this point, I don't know if my SSP server will be a front-end web server or not but it's got SharePoint installed all the same.  The instructions tell me to configure farm services and to start with MOSS Search.  It has a link to a page called Configure the Office SharePoint Server Search service. 

That page will direct you to the Services on Server page and it tells you to click on the Office SharePoint Server Search link in the list of services on the page.  It did not tell me to select MySSPServer from the pull down list at the top of the page but I did.  So it takes me to a page titled Configure Office SharePoint Server Search Service Settings on server MySSPServer.  Great.

I tell it to use MySSPServer, an eMail address, MOSSAdmin@MyDomain.com and I give it my MyDomain\MOSSSearchSvc account and password.  Then I told it not to use all WFE servers for crawling but just MySSPServer.  I click OK and it takes me back to the list.  I click on Start and it takes me back to the configuration page where I have to enter the password again and click OK again.  Then it takes me back to the list but the Status has changed from the red Stopped to the green Starting.  When I refresh the page, it says Started.

I go back to the instruction page and I see, at the bottom, this:

Tip: If your index server is dedicated and is not running any other shared services, activate the Web front-end role on the index server and specify the index server as the dedicated Web front-end computer for crawling.

And then, since I'm done with the Search Index set up page and I go back to the Learn How page and the next step on it says this:

The Windows SharePoint Services Web Application service must be running on any server that acts as a Web server and renders Web content. This service is started by default on servers that you set up by using the Web Front End option during Setup. If you set up a server using the Complete option during Setup, and you want that server to act as a Web server and render Web content, you must start the Windows SharePoint Services Web Application service on that server.

This does not appear to be a "Service" like you see in Computer Management | Serivces but it does appear in the list of services in the Services on Server page and it says it's running.

There doesn't seem to be any instructions that have anything to do with the other services.  Instead, the "Learn How..." page rolls onto Configure the Shared Services Provider.  This provides a blurb that says:

Before you create the SSP, you must create a Web application for the SSP administration site.

So, while the SSP might be running on another server, the SSP Admin Web site might be on another.  There's a link that says Manage a farm's Shared Services Providers. 

Now, I've got two identical WFEs except that one of them is also my index server.  I wonder if I can get more services to run on that server and eliminate that burden from the WFE.  In fact, I'd like for one server to only be a user content site collection server and have everything else run on a different server. 

-robot