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 filesmicrosoft office.

The problem is the EXPTOOWS.XLA file and it's accompanying EXPTOOWS.DLL file that live in the Office 121033 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 filesmicrosoft officeOffice 111033 folder

and pasted them into my Office 121033 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 MyDomainmosssspsvc 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 MyDomainmossapppool_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_MACHINESOFTWAREMicrosoftOffice Server12.0LauncherSettings

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 FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>stsadm -o provisionservice -action stop -servicetype Microsoft.Office.Server.Conversions.LauncherService -servicename dclauncher

And:

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12BIN>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.