Error attempting to configure 'Office SharePoint Server Search' service.
Working on a new farm install: 4 Servers (2 WFE, 1 Index/App, 1 DB).
On the Index/App server, everything works fine.
On the 2 WFEs, whenever I go to Central Admin -> Operations -> Services on Server and click on 'Office SharePoint Server Search', it errors out. It looks like it's trying to access the Search Admin web service here: http://server:56737/SearchAdmin.asmx and it's failing because the AppPool for that web service is not spinning up.
The event log contains the generic error: Failed to execute request because the App-Domain could not be created. Error: 0x80004005 Unspecified Error.
As a test, I changed the AppPool account on the OfficeServerApplicationPool to a domain account (instead of NetworkService) and it fixes everything. However, within a few seconds, the AppPool account gets changed back to NetworkService (presumably by SharePoint). OfficeServerApplicationPool is not available to configure within the "Service Account" screen in Central Admin, so this doesn't appear to be a usable workaround.
Any ideas?
Jason Barron
Blog: http://rdacollab.blogspot.com/
CodePlex: http://rdacollaboration.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28073- VerschobenMike Walsh MVPMVP, ModeratorMittwoch, 25. November 2009 06:08search related (From:SharePoint - Setup, Upgrade, Administration and Operation)
- BearbeitetJason Barron Mittwoch, 25. November 2009 15:20
Alle Antworten
- Jason... Is the search service changing anything in the host.sam file? %system drive%\windows\System32\drivers\etc -> open host.sam in notepad.... Do you see any reference to the search server by way of an IP address? Check all the machines, I know this sounds nuts but I remember this at a client a while back.
Cheers - Kris
Kris Wagner, MCITP, MCTS Twitter @sharepointkris Blog: http://sharepointkris.com Kris,
It doesn't appear to be changing anything in host.sam. Actually, I don't have a host.sam, but I checked lmhosts.sam and hosts. Both just have the standard stuff in it: lmhosts.sam just has commented lines and hosts just has a 127.0.0.1 -> localhost mapping.
Thanks
Jason Barron
Blog: http://rdacollab.blogspot.com/
CodePlex: http://rdacollaboration.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28073I just had one potential breakthrough. Using Process Monitor, I can see ACCESS DENIED messages for the w3wp.exe service trying to read “C:\WINDOWS”. If I grant “NETWORK SERVICE” explicit read/execute/list rights to C:\WINDOWS, the service works (I get many more ACCESS DENIED messages on creating registry keys, but it works).
So, now I’m wondering:
· As a test, I put NETWORK SERVICE in the local Administrators group. The local admins group already had write access to C:\WINDOWS. How come it didn’t work until I explicitly added NETWORK SERVICE?
· What’s the permanent solutution? I don’t think assigning read access to all of C:\WINDOWS for NETWORK SERVICE is the best idea.
Jason Barron
Blog: http://rdacollab.blogspot.com/
CodePlex: http://rdacollaboration.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28073- Hi Jason,
Since SharePoint mostly controls the IIS Metabase as you have found you cannot change the app pool account manually. However, there are very good articles on how to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0 http://support.microsoft.com/kb/934838...
However, the default account for the OfficeServerApplicationPool is NetworkService. Each SSP in the farm will be represented by a virtual directory configured beneath this web application; the virtual directory is named with the name of the SSP, so if your farm runs an SSP named SharedServices1, looking underneath the Office Server Web Services web application would reveal a virtual directory named SharedServices1, associated to an application pool with the same name. That application pool runs under the identity of the SSP service account it executes for.
I hope this helps... However, if you will be a little more explicit and include the details of the errors we can probably resolve your errors....
Cheers,
-Ivan
Ivan Sanders - Ivan,
Thanks for the reply. However, the application pool in question is not the SSP appPool - it's the "OfficeServerApplicationPool". It's failing on an attempt to open: http://server:56737/SearchAdmin.asmx. I haven't found any commands for updating its AppPool's identity. Additionally, I have access to several other existing Farms where it runs fine under Network Service.
For some reason though, these new servers require that I give "Network Service" read access to C:\WINDOWS or "OfficeServerApplicationPool" fails.
Jason Barron
Blog: http://rdacollab.blogspot.com/
CodePlex: http://rdacollaboration.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28073 - Hi jason,
I had a couple of questions though its sounds like a permissions releated error...
Is Office Search Configured? and your clicking on the link to make modifications, is the OfficeServerApplicationPool Stopped has the black dot on it of using IIS 7.5. I know you said "Failed to execute request because the App-Domain could not be created. Error: 0x80004005 Unspecified Error" but what is the error #, is this from the applicatiojn event log or part of the ULS logs? what version of .NET, what server versiion and What version of SharePoint etc?
You can use the ICACLs (Its included inSP2 for Windows Server 2003) dependent on what version windows your running to reset your default permissions on the C:\windows dir
OnExisting farm where the OfficeServerApplicationPool is working and priuor to making any changes on the problem server
ICACLS c:\windows\* /save aclfile [/T] [/C]
store the acls for all matching names into aclfile for
later use with /restore.
ICACLS c:\windows\* /verify [/T] [/C]
finds all files whose ACL is not in canonical form or whose
lengths are inconsistent with ACE counts.
ICACLS c:\windows\* /restore AclFile
- Will restore the Acls for every file within
AclFile that exists in c:\windows and its subdirectories
-Ivan
Ivan Sanders My LinkedIn Profile, My Blog, @iasanders. Thanks Ivan. To make sure I understand, should I:
- Save the ACL list on a working server.
- Find non-canonical ACLs on the broken server.
- Restore the ACL list on the broken server.
How dangerous is this operation to the rest of the server's functionality? If I backup the ACLs on the broken server, can I restore them later to the exact state as they are in currently?
To answer your questions:
- Yes - Search is configured. The stsadm commands seem to work to configure and turn on the service. Just the admin screen fails (and the underlying SearchAdmin.asmx service)
- The OfficeServerApplicationPool is on (black dot - not red X). This is IIS 6 / Windows 2003.
- The only error in the application event log is the one I mentioned. The error # is 1088.
- The ULS also logs the error, but doesn't include any additional info. It simply spits out the error being returned by the SearchAdmin.asmx service.
- .NET Framework 1.1, 2.0, 3.0, and 3.5 are installed. IIS is configured for .NET v2.0.50727 64-bit
The only thing odd I noticed when I was first setting things up was that IIS was configured for 32-bit ASP.NET. I switched it to use 64-bit by executing:
- aspnet_regiis -u (on the 32-bit Framework)
- cscript adsutil.vbs set W3SVC/AppPools/Enable32bitAppOnWin64 0
- aspnet_regiis -i (on the 64-bit Framework)
- Enabled ASP.NET v2.0.50727 extension in IIS.
(Not sure if that sets off any warnings.)
Jason Barron
Blog: http://rdacollab.blogspot.com/
CodePlex: http://rdacollaboration.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28073- Dear Jason Barron,
can you check permissions of for .NET v2.0.50727 64-bit make sure that network service have a permisson on it.
